From owner-multi6@ops.ietf.org Tue Apr 1 05:26:57 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03166 for ; Tue, 1 Apr 2003 05:26:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 190Ixz-000FhW-00 for multi6-data@psg.com; Tue, 01 Apr 2003 02:26:07 -0800 Received: from [194.116.127.89] (helo=dhcp1.se.kurtis.pp.se) by psg.com with esmtp (Exim 3.36 #1) id 190Ixx-000FhF-00 for multi6@ops.ietf.org; Tue, 01 Apr 2003 02:26:05 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp1.se.kurtis.pp.se (8.12.7/8.10.2) with ESMTP id h31ARZWv003318; Tue, 1 Apr 2003 12:27:37 +0200 (CEST) Date: Tue, 1 Apr 2003 12:27:35 +0200 Subject: Re: provider-int geo aggr [Re: plug: thesis on site multihoming] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: multi6@ops.ietf.org To: Iljitsch van Beijnum From: Kurt Erik Lindqvist In-Reply-To: Message-Id: <8E01A4A6-642C-11D7-8DEC-000393AB1404@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-16.1 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,USER_AGENT_APPLEMAIL autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> It just doesn't seem to be enough fleshed out to say much other than >> "ouch! I don't really understand the idea, but it still gives me >> creeps!". > > What's so hard to understand??? In the US you create an aggregate > route for the US address block and you accept /48s for US > destinations. In Europe, you create an aggregate for the European > address block and accept /48s for European destinations. So when you > have a packet in the US that needs to go to a European destination, > you don't have a /48 route so the packet is routed to Europe by means > of the aggregate. In Europe, the packet is routed further as per the > /48 that is in the routing tables of European routers. Rinse, repeat. I would still like to second Pekkas request on an example with AS:es instead of routers. What I am not sure I understand is who would have to provide the transit between the AS:es for these /48s? Also, what do you do with Tier-1 providers and customers that are multihomed to different continents? Could you write a bit more detailed example? - kurtis - From owner-multi6@ops.ietf.org Tue Apr 1 06:09:50 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03870 for ; Tue, 1 Apr 2003 06:09:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 190Jeu-000HVj-00 for multi6-data@psg.com; Tue, 01 Apr 2003 03:10:28 -0800 Received: from [3ffe:a00:f:3:290:27ff:fed0:e95b] (helo=petal.blackrose.org) by psg.com with esmtp (Exim 3.36 #1) id 190Jes-000HVN-00 for multi6@ops.ietf.org; Tue, 01 Apr 2003 03:10:26 -0800 Received: from petal.blackrose.org (petal.blackrose.org [127.0.0.1]) by petal.blackrose.org (8.12.8/8.12.4) with ESMTP id h31B7W9F030994; Tue, 1 Apr 2003 06:07:32 -0500 Received: (from dorian@localhost) by petal.blackrose.org (8.12.8/8.12.4/Submit) id h31B7W8d030993; Tue, 1 Apr 2003 06:07:32 -0500 Date: Tue, 1 Apr 2003 06:07:32 -0500 From: Dorian Kim To: Iljitsch van Beijnum Cc: multi6@ops.ietf.org Subject: Re: provider-int geo aggr [Re: plug: thesis on site multihoming] Message-ID: <20030401110732.GA30705@blackrose.org> References: <9D539028-62E3-11D7-A2C0-00039388672E@muada.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9D539028-62E3-11D7-A2C0-00039388672E@muada.com> User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-38.8 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MUTT autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk On Sun, Mar 30, 2003 at 09:12:56PM +0200, Iljitsch van Beijnum wrote: > Cooperation from other ISPs is not needed: everyone can implement or > not implement this as desired, just as long as the RIRs give out the > addresses based on geography. I guess if one stays around long enough, one gets to see all old arguments rehashed, regardless of how definitive the result of the last round was. Geographical address assignment and aggregation was discussed extensively and rejected in big-internet mailing list circa 1994-5 during the discussions leading up to the publication of RFC 2008. The list archive is available at ftp://munnari.oz.au/big-internet/list-archive I believe there were also discussions on cidrd wg mailing list on the same topic around the same time. -dorian From owner-multi6@ops.ietf.org Tue Apr 1 08:18:17 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09242 for ; Tue, 1 Apr 2003 08:18:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 190Ldl-000P76-00 for multi6-data@psg.com; Tue, 01 Apr 2003 05:17:25 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 190Ldi-000P6i-00 for multi6@ops.ietf.org; Tue, 01 Apr 2003 05:17:22 -0800 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h31DGI624213; Tue, 1 Apr 2003 15:16:18 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Tue, 1 Apr 2003 15:16:06 +0200 Subject: Re: provider-int geo aggr [Re: plug: thesis on site multihoming] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: multi6@ops.ietf.org To: Dorian Kim From: Iljitsch van Beijnum In-Reply-To: <20030401110732.GA30705@blackrose.org> Message-Id: <186898CA-6444-11D7-9BA5-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On dinsdag, apr 1, 2003, at 13:07 Europe/Amsterdam, Dorian Kim wrote: > I guess if one stays around long enough, one gets to see all old > arguments > rehashed, regardless of how definitive the result of the last round > was. > Geographical address assignment and aggregation was discussed > extensively > and rejected in big-internet mailing list circa 1994-5 during the > discussions leading up to the publication of RFC 2008. > The list archive is available at > ftp://munnari.oz.au/big-internet/list-archive Cool. I've searched 1994 and 1995 for "geo" and I found a lot of debate. However, I did not find any definitive results. From owner-multi6@ops.ietf.org Tue Apr 1 08:51:47 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11038 for ; Tue, 1 Apr 2003 08:51:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 190MBO-0001RZ-00 for multi6-data@psg.com; Tue, 01 Apr 2003 05:52:10 -0800 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 190MBL-0001RF-00 for multi6@ops.ietf.org; Tue, 01 Apr 2003 05:52:07 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h31Dq3h15252; Tue, 1 Apr 2003 16:52:03 +0300 Date: Tue, 1 Apr 2003 16:52:03 +0300 (EEST) From: Pekka Savola To: Iljitsch van Beijnum cc: multi6@ops.ietf.org Subject: Re: provider-int geo aggr [Re: plug: thesis on site multihoming] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-32.3 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Sorry for the delay, was occupied. On Mon, 31 Mar 2003, Iljitsch van Beijnum wrote: > On zondag, maa 30, 2003, at 21:40 Europe/Amsterdam, Pekka Savola wrote: > > > But really, the problem is that I'm having hard time (and based on the > > lack of enthuasiasm from the others, the rest as well) figuring out > > whether the model could be useful and whether it could actually work. > > It allows around ten million multihomed networks, so that answers the > useful part. Nobody has ever pointed out any aspect that presumably > wouldn't work (just stuff they aren't real comfortable with) so either > I am as smart as I think or nobody wants to take the time to carefully > read the draft. You know, when the document quality is not as high as one could hope, and a new concept is introduced, it's also a matter of writing the idea clearly. Especially, starting with clear introduction, easy-to-understand picture, etc. -- answer the question "how is this different from other geo proposals". People, under these circumstances give up after N pages when you don't get into business quickly enough. It's easier to find the gold if the map is easy to understand. Sometimes you don't have a map or it's very difficut to read... > > It just doesn't seem to be enough fleshed out to say much other than > > "ouch! I don't really understand the idea, but it still gives me > > creeps!". > > What's so hard to understand??? In the US you create an aggregate route > for the US address block and you accept /48s for US destinations. In > Europe, you create an aggregate for the European address block and > accept /48s for European destinations. So when you have a packet in the > US that needs to go to a European destination, you don't have a /48 > route so the packet is routed to Europe by means of the aggregate. In > Europe, the packet is routed further as per the /48 that is in the > routing tables of European routers. Rinse, repeat. Flesh it out, in simple terms (the pic in the draft is too complex). Try to use AS's if that's possible. A particular point I'm not sure would work out is how you deal with backup connectivity. An example: upstream upstream (US?) | | [router2]-[router3] | \ / | \ / .---- other | [router1] ---- exchange --/----- routers | / \----- from the [ISP backbone] \---- region Now, if you install the aggregate for the region in router1 and block more specifics at router2 and router3 (from upstreams and internally), now what if router1 or the link to the exchange fails? How do you get the routes through your upstreams? > > If you want to avoid that feeling, you must warm up the folks properly > > :-) > > So how do I do that? Buy everyone drinks at the IETF meetings? Try a good introduction in the draft, answering the critical questions (how is this different, how does it work in principle) plus a clear, simple pic or two. > > "if you can't have the same routing table in all of your routers in a > > single AS while being part of the DFZ, your architecture or the > > definition > > of AS is broken" > > Ok, then OSPF and IS-IS explicitly support broken networks... IGP's are entirely different beasts with different functionality. > > In the proposal, where are the more specific advertisements hidden? > > Being advertised between different AS's at peering points but hidden in > > your that particular peering router by an internally advertised > > aggregate? > > Not sure what you're getting at. _someone_ must have the more specific routes. you can't just toss the routes around. Sure, you could build the internet routing architecture with manual aggregates or default routes, even, but that would be horrible, especially if a router or link goes down. > >> I'd say it's the other way around: if your architecture requires > >> you to keep information about the entire world in all routers, you've > >> painted yourself into a corner. > > > I can agree with that (which is the addressing model Tony is proposing > > with his geo proposal, btw.) -- if it's required, but I'd like to avoid > > it. > > But just now you said you wanted to be able to have the same routing > info in all routers! You can't have it both ways. In all routers in _my AS_. > >> I'm considering an update to the draft, but as far as I can tell > >> everything is in there. > > > Doesn't seem to be particularly unenlightened-friendly.. :-/ > > Tell me what's missing and I'll put it in. I hope I made a few pointers above. Clear introduction, summary of the operation etc. would be nice starting points. > >> Actually Tony's draft is just an addressing scheme which doesn't > >> automatically solve routing. > > > I'd be very very careful of any mechanism which claimed would solve > > routing automatically. > > I don't mean solving all routing problems forever, just that Tony's > scheme needs additional routing stuff to do something useful. Sure, it needs a bit of work .. but the concept of someone advertising an aggregate seems clear -- not necessarily acceptable or a good idea considering all the different implications (many of them non-technical), but still understandable, to an extent. > >> Cooperation from other ISPs is not needed: everyone can implement or > >> not implement this as desired, just as long as the RIRs give out the > >> addresses based on geography. > > > Forgive me for sounding skeptic, but I'm not as sure without further > > analysis that no cooperation would be required. > > What exactly would another ISP have to do so I can aggregate within my > own network??? If I want to accept all routes within 195.0.0.0/8 in > Amsterdam, all routes within 196.0.0.0/8 in London and so on, I can do > that without cooperation. (I have to deaggregate if I don't peer in > London with someone who announces 196.12.34.0/24, though, but that's > still something I can do on my own.) What about when your router or a link in london or amsterdam goes down? where do you go to networks in 195/8 or 196/8 then? This was one of the points in message "Sun, 30 Mar 2003 20:37:07 +0300 (EEST)". -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Tue Apr 1 09:17:17 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12519 for ; Tue, 1 Apr 2003 09:17:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 190Ma1-0002zR-00 for multi6-data@psg.com; Tue, 01 Apr 2003 06:17:37 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 190MZy-0002zF-00 for multi6@ops.ietf.org; Tue, 01 Apr 2003 06:17:34 -0800 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h31EGV624307; Tue, 1 Apr 2003 16:16:31 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Tue, 1 Apr 2003 16:16:19 +0200 Subject: Re: provider-int geo aggr [Re: plug: thesis on site multihoming] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: multi6@ops.ietf.org To: Kurt Erik Lindqvist From: Iljitsch van Beijnum In-Reply-To: <8E01A4A6-642C-11D7-8DEC-000393AB1404@kurtis.pp.se> Message-Id: <81FD3C48-644C-11D7-9BA5-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On dinsdag, apr 1, 2003, at 12:27 Europe/Amsterdam, Kurt Erik Lindqvist wrote: > I would still like to second Pekkas request on an example with AS:es > instead of routers. The AS view is exactly the same as today: each AS announces its customers (and customer's customers) to peers and upstreams. > What I am not sure I understand is who would have to provide the > transit between the AS:es for these /48s? It seems the word "geography" carries a lot of baggage in this context. Forget all of that. The only thing I want to do is remove routing information from the places where it doesn't actually help routing. To answer your question: the transit relationships would be identical to what happens with PI today. So if A is a customer of B which is a peer of C which has a customer D, the traffic would still flow A -> B -> C -> D and D -> C -> B -> A. However, if A is in Seattle and D is in The Hague, today the A -> D traffic would be flow from B to C close to the origin, so probably somewhere in the bay area. The D -> A traffic would also flow from C to B close to the origin, probably in Amsterdam. With provider-internal geo aggregation B would no longer have the route for D in routing tables on the US west coast. (C would still announce this route there, as C doesn't know how B aggregates internally.) So the traffic for D will be routed according to an aggregate. This could be a route for all of Europe, or the Netherlands or The Hague. Then at some point the packet arrives on the US east coast, in Europe, NL or The Hague, and there the /48 is in the routing table and the packet is transferred to C. > Also, what do you do with Tier-1 providers and customers that are > multihomed to different continents? There are three cases: 1. Geographically diverse organization that doesn't want to use its private network for "internal transit" (having ISPs transport the traffic to the right location is cheaper): simply use GAPI addresses in each location. This means that each location must multihome independently. 2. Geographically diverse organization that wants to use its private network for "internal transit": they are assuming an ISP role here so they should get their own PA block. Note that this means the entire PA block is announced in each location so lots of internet traffic traverses the private network. 3. Organizations that use long distance links to connect to the net. A good example would be satellite links. There is no good solution for this situation: either the organization breaks aggregation or it uses addresses from the "landing site" geo address block rather than the user site geo address block. Note that not solving 100% of all cases isn't a problem: we don't need a 4k routing table, we just need to avoid a 4M routing table. A 400k routing table in the year 2008 or so would be just fine. So we can still allow a reasonable number of all multihomers to break aggregation. > Could you write a bit more detailed example? Is the above what you need? From owner-multi6@ops.ietf.org Tue Apr 1 09:29:55 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13797 for ; Tue, 1 Apr 2003 09:29:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 190Mm8-0003q0-00 for multi6-data@psg.com; Tue, 01 Apr 2003 06:30:08 -0800 Received: from zmamail03.zma.compaq.com ([161.114.64.103]) by psg.com with esmtp (Exim 3.36 #1) id 190Mm5-0003pk-00 for multi6@ops.ietf.org; Tue, 01 Apr 2003 06:30:05 -0800 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id C1390896; Tue, 1 Apr 2003 09:30:02 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 1 Apr 2003 09:30:02 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: provider-int geo aggr [Re: plug: thesis on site multihoming] Date: Tue, 1 Apr 2003 09:30:02 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B032410B7@tayexc13.americas.cpqcorp.net> Thread-Topic: provider-int geo aggr [Re: plug: thesis on site multihoming] Thread-Index: AcL4QNCHgSxNL/xaTB2R+4At8X12GQAGas9Q From: "Bound, Jim" To: "Dorian Kim" , "Iljitsch van Beijnum" Cc: X-OriginalArrivalTime: 01 Apr 2003 14:30:02.0414 (UTC) FILETIME=[2E68FCE0:01C2F85B] X-Spam-Status: No, hits=-9.8 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA13797 I have been thinking about this but that is ok. Here is my logic. When we designed IPv6 we left many open for discussion parts in the architecture. For example scoping of interfaces, multiple format-prefixes for address architecture, flowlabel. Solving anyone of these is a complex undertaking, but could be done later. I believe it is fair because of this effort to look at geo addressing again for Multi6. It does not break existing implementations or deployment test beds or those emerging further, but a policy discussion that can have an affect to implementation but in a backwards compatible manner, and same with scoping and the flowlabel. In this case revisitation of the principles of geo address architecture is in fact valid IMO. Regards, /jim > -----Original Message----- > From: Dorian Kim [mailto:dorian@blackrose.org] > Sent: Tuesday, April 01, 2003 6:08 AM > To: Iljitsch van Beijnum > Cc: multi6@ops.ietf.org > Subject: Re: provider-int geo aggr [Re: plug: thesis on site > multihoming] > > > On Sun, Mar 30, 2003 at 09:12:56PM +0200, Iljitsch van Beijnum wrote: > > Cooperation from other ISPs is not needed: everyone can implement or > > not implement this as desired, just as long as the RIRs > give out the > > addresses based on geography. > > I guess if one stays around long enough, one gets to see all > old arguments > rehashed, regardless of how definitive the result of the last > round was. > > Geographical address assignment and aggregation was discussed > extensively > and rejected in big-internet mailing list circa 1994-5 during > the discussions leading up to the publication of RFC 2008. > > The list archive is available at > ftp://munnari.oz.au/big-internet/list-archive > > I believe > there were also discussions on cidrd wg mailing list on the > same topic around the same time. > > -dorian > > From owner-multi6@ops.ietf.org Tue Apr 1 17:42:11 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18897 for ; Tue, 1 Apr 2003 17:42:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 190UR0-0003cR-00 for multi6-data@psg.com; Tue, 01 Apr 2003 14:40:50 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 190UQT-0003Xa-00 for multi6@ops.ietf.org; Tue, 01 Apr 2003 14:40:18 -0800 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h31MdE624928 for ; Wed, 2 Apr 2003 00:39:15 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Wed, 2 Apr 2003 00:39:04 +0200 Mime-Version: 1.0 (Apple Message framework v551) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: Geo pros and cons From: Iljitsch van Beijnum To: multi6@ops.ietf.org Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-9.7 required=5.0 tests=BAYES_01,USER_AGENT_APPLEMAIL autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit In the discussion about geographical aggregation the past days (and on earlier occasions) we tend to get into a lot of detail: which routes go where, how many interconnects and so on. These are important details, and they need to be discussed. But first we need to consider the viability of geographical aggregation. Geographical aggregation has some problems. For instance, it won't scale in the long term if we indeed reach multihoming levels of 1 : 10. Another problem is that it changes the way traffic flows between ISPs (no more hot potato routing). But the biggest objection against it is that network topologies don't match geography, so geography isn't a reasonable basis for making routing decisions. I think this is the one we need to tackle. Now obviously it is possible to lease a circuit to a remote location and connect to "the internet" in that location rather than close to home. But should we consider this a feature we must support, or is it an exceptional situation that we can safely ignore? Suppose the long distance connection would have been IP rather than ATM, SONET or fiber. In that case, a data from customer A of the long distance service provider to customer B of the long distance provider, wouldn't travel all the way to the remote location and back, but the data would be immediately forwarded to the right destination by a local router. So essentially we're expecting IP to compensate for the stupidity of non-IP networks... Then there is the argument that interconnection is limited. Yes, this is true. Only a small percentage of all internet users live very close to a major exchange location (a single exchange location usually has one or more public exchanges and several private interconnects). On the other hand, the percentage of internet users that live extremely far from an exchange location is also fairly low. Experience has shown that there is little incentive to implement additional interconnects if there is already good interconnection within 500 - 1000 km. If there isn't a good interconnect within 1000 km, the need for one is roughly proportional to the number of internet users multiplied by the distance to the nearest exchange location. Since the scalability of geographical aggregation depends on the number of internet users and the size of the aggregation areas, where each aggregation area needs at least two interconnects, it would seem that the scalability of geographical multihoming isn't a problem: more multihomers means more routes in an area, but since more end-users means more interconnects, the areas shrink. So the number of routes per area should remain fairly constant. I'm interested to hear other views. Iljitsch van Beijnum From owner-multi6@ops.ietf.org Tue Apr 1 18:37:44 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21887 for ; Tue, 1 Apr 2003 18:37:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 190VKY-000C6m-00 for multi6-data@psg.com; Tue, 01 Apr 2003 15:38:14 -0800 Received: from dmz2.procket.com ([65.174.124.37]) by psg.com with esmtp (Exim 3.36 #1) id 190VKU-000C6Y-00 for multi6@ops.ietf.org; Tue, 01 Apr 2003 15:38:10 -0800 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id 9B37E3443F; Tue, 1 Apr 2003 14:51:33 -0800 (PST) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h31Nc9YB014860; Tue, 1 Apr 2003 15:38:09 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Geo pros and cons Date: Tue, 1 Apr 2003 15:38:09 -0800 Message-ID: Thread-Topic: Geo pros and cons Thread-Index: AcL4oqVPP4pEsSNXSASCAqBYqGbZHQABAS0A From: "Tony Li" To: "Iljitsch van Beijnum" , X-Spam-Status: No, hits=-6.6 required=5.0 tests=BAYES_01 version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA21887 Iljitsch, | Now obviously it is possible to lease a circuit to a | remote location | and connect to "the internet" in that location rather than | close to | home. But should we consider this a feature we must | support, or is it | an exceptional situation that we can safely ignore? Since this happens all too frequently, we must deal with it. The Internet is not a centrally run function. Instead it grows organically by the needs of the users. In other words, the links only show up where they make economic sense. And those are the links that users will use, ignoring the consequences. | Since the scalability of geographical aggregation depends | on the number | of internet users and the size of the aggregation areas, | where each | aggregation area needs at least two interconnects, it | would seem that | the scalability of geographical multihoming isn't a problem: more | multihomers means more routes in an area, but since more end-users | means more interconnects, the areas shrink. So the number | of routes per | area should remain fairly constant. If the routes are proportional to the number of areas and the areas are growing, then you again have a rapidly growing routing table. As we concluded many years ago: for addressing to scale, it has to match the topology. If addressing does not match the topology, then additional information in the form of longer prefixes must be advertised into the routing subsystem. Ergo, if one chooses geographic address, one must force only geographically based links. Anything else destroys the aggregatability of the address assignment. Since we, as IETF members, cannot decree where folks will connect, geo addressing is a nice theorectical goal which is unimplementable. Regards, Tony From owner-multi6@ops.ietf.org Wed Apr 2 02:24:35 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23239 for ; Wed, 2 Apr 2003 02:24:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 190caw-000F5u-00 for multi6-data@psg.com; Tue, 01 Apr 2003 23:23:38 -0800 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 190cat-000F5D-00 for multi6@ops.ietf.org; Tue, 01 Apr 2003 23:23:35 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h327NVH23571; Wed, 2 Apr 2003 10:23:31 +0300 Date: Wed, 2 Apr 2003 10:23:31 +0300 (EEST) From: Pekka Savola To: Iljitsch van Beijnum cc: multi6@ops.ietf.org Subject: voluntary filtering of more specifics [Re: Geo pros and cons] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-31.7 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk One particular point.. On Wed, 2 Apr 2003, Iljitsch van Beijnum wrote: > Since the scalability of geographical aggregation depends on the number > of internet users and the size of the aggregation areas, where each > aggregation area needs at least two interconnects, it would seem that > the scalability of geographical multihoming isn't a problem: more > multihomers means more routes in an area, but since more end-users > means more interconnects, the areas shrink. So the number of routes per > area should remain fairly constant. .. depending on who is in charge of the aggregate and the routes, I've gotten a personal belief that if we build a system that allows more specific routes, we must have a system which can be used to block them too. That is, e.g. longer prefixes from under current 2001 RIR allocations are a non-starter; they create a system where advertising more specifics is required for multihomers while giving away the control of more restrictions of more specifics. "meant for longer prefixes of a certain length" allocations from a separate block would be completely different in this regard. Similar seems to apply to geo-like approaches depending on geo-aggregates. Who (at the originating region) is creating the aggregate? And more importantly, *why* should the sites or ISP's in the region be encouraged to *not* advertise their more specific geo prefix *anyway* (assuming the geo routing infrastructure might require that under some conditions)? There would seem to be a need for some control there, or all the traffic going through such big ISP's we could trust to do the right thing and not propagating the more specifics. Otherwise we would end up with a routing table with *both* more specific geo routes *and* the aggregates :-( -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Wed Apr 2 10:16:51 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13291 for ; Wed, 2 Apr 2003 10:16:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 190jxH-000OKi-00 for multi6-data@psg.com; Wed, 02 Apr 2003 07:15:11 -0800 Received: from smtp02.uc3m.es ([163.117.136.122] helo=smtp.uc3m.es) by psg.com with esmtp (Exim 3.36 #1) id 190jwm-000OCt-00 for multi6@ops.ietf.org; Wed, 02 Apr 2003 07:14:40 -0800 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id F18484322A; Wed, 2 Apr 2003 17:14:38 +0200 (CEST) Received: from presto.it.uc3m.es (presto.it.uc3m.es [163.117.139.134]) by smtp02.uc3m.es (Postfix) with ESMTP id 6037299F49; Wed, 2 Apr 2003 17:14:38 +0200 (CEST) Subject: RE: Geo pros and cons From: marcelo bagnulo To: Tony Li Cc: Iljitsch van Beijnum , multi6@ops.ietf.org In-Reply-To: References: Content-Type: text/plain Organization: uc3m Message-Id: <1049296457.1068.168.camel@presto.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 02 Apr 2003 17:14:17 +0200 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-32.3 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_XIMIAN autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Tony, [...] > As we concluded many years ago: for addressing to scale, it has > to match the topology. Fully agree. I would say that the question is if topology matches geography or not. I have heard many claims that the Internet is becoming a dense interconnection mesh. If this is true, it should be easy to determine geographical areas that are interconnected, so geo aggregation works without the need of more specific routes. I think that this is certainly not the case for all geo locations, but i would say that it is probably the case for some locations as big cities where a lot of users reside. Wouldn't geo addressing be suitable for this situations? I am not aware of any analysis of how dense is the interconnection in geo areas, but i would say that this input is important when considering geo addressing. Does anyone have information about this? Thanks, marcelo > If addressing does not match the topology, > then additional information in the form of longer prefixes must be > advertised into the routing subsystem. Ergo, if one chooses geographic > address, one must force only geographically based links. Anything > else destroys the aggregatability of the address assignment. Since > we, as IETF members, cannot decree where folks will connect, geo > addressing is a nice theorectical goal which is unimplementable. > > Regards, > Tony -- marcelo bagnulo uc3m From owner-multi6@ops.ietf.org Wed Apr 2 13:44:09 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22577 for ; Wed, 2 Apr 2003 13:44:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 190n9T-0001KB-00 for multi6-data@psg.com; Wed, 02 Apr 2003 10:39:59 -0800 Received: from dmz2.procket.com ([65.174.124.37]) by psg.com with esmtp (Exim 3.36 #1) id 190n9Q-0001Jx-00 for multi6@ops.ietf.org; Wed, 02 Apr 2003 10:39:56 -0800 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id 690C834441; Wed, 2 Apr 2003 09:53:20 -0800 (PST) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h32IdsYB015435; Wed, 2 Apr 2003 10:39:55 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Geo pros and cons Date: Wed, 2 Apr 2003 10:39:54 -0800 Message-ID: Thread-Topic: Geo pros and cons Thread-Index: AcL5KqCgxtYW3vTUSISJFE0hNSIIngAG/y4w From: "Tony Li" To: "marcelo bagnulo" Cc: "Iljitsch van Beijnum" , X-Spam-Status: No, hits=-6.6 required=5.0 tests=BAYES_01 version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA22577 Marcelo, Yes, there are regions where geo addressing makes sense. Here in the SF bay area, where it's hard not to trip over all of the fiber that we have lying around, it would play out beautifully. Theoretically. However, even in this location, where we have multiple interconnect points, we can observe that the local ISPs do not choose to connect at all of the interconnects. Some are at Fix-W, some at Equinix, some at PAIX, etc.... Even in this environment we are not yet at the point where geo addressing would not require us to force particular links to be installed. I dunno about you, but I don't like pushing string. Tony | -----Original Message----- | From: marcelo bagnulo [mailto:marcelo@it.uc3m.es] | Sent: Wednesday, April 02, 2003 7:14 AM | To: Tony Li | Cc: Iljitsch van Beijnum; multi6@ops.ietf.org | Subject: RE: Geo pros and cons | | | Hi Tony, | | [...] | > As we concluded many years ago: for addressing to scale, it has | > to match the topology. | | Fully agree. | I would say that the question is if topology matches | geography or not. | | I have heard many claims that the Internet is becoming a dense | interconnection mesh. If this is true, it should be easy | to determine | geographical areas that are interconnected, so geo | aggregation works | without the need of more specific routes. | | I think that this is certainly not the case for all geo | locations, but i | would say that it is probably the case for some locations | as big cities | where a lot of users reside. Wouldn't geo addressing be | suitable for | this situations? | | I am not aware of any analysis of how dense is the | interconnection in | geo areas, but i would say that this input is important | when considering | geo addressing. Does anyone have information about this? | | Thanks, marcelo | | | > If addressing does not match the topology, | > then additional information in the form of longer | prefixes must be | > advertised into the routing subsystem. Ergo, if one | chooses geographic | > address, one must force only geographically based links. | Anything | > else destroys the aggregatability of the address | assignment. Since | > we, as IETF members, cannot decree where folks will connect, geo | > addressing is a nice theorectical goal which is unimplementable. | > | > Regards, | > Tony | -- | marcelo bagnulo | uc3m | | From owner-multi6@ops.ietf.org Wed Apr 2 14:25:24 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24196 for ; Wed, 2 Apr 2003 14:25:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 190nrm-0008fA-00 for multi6-data@psg.com; Wed, 02 Apr 2003 11:25:46 -0800 Received: from evrtwa1-ar8-4-65-019-240.evrtwa1.dsl-verizon.net ([4.65.19.240] helo=tndh.net) by psg.com with esmtp (Exim 3.36 #1) id 190nri-0008ex-00 for multi6@ops.ietf.org; Wed, 02 Apr 2003 11:25:42 -0800 Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Wed, 02 Apr 2003 11:25:40 -0800 Reply-To: From: "Tony Hain" To: "'Tony Li'" , "'Iljitsch van Beijnum'" , Subject: RE: Geo pros and cons Date: Wed, 2 Apr 2003 11:25:37 -0800 Message-ID: <09ae01c2f94d$a48bf970$ee1a4104@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: X-Spam-Status: No, hits=-25.2 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA24196 Tony Li wrote: > Iljitsch, > > | Now obviously it is possible to lease a circuit to a > | remote location > | and connect to "the internet" in that location rather than > | close to > | home. But should we consider this a feature we must > | support, or is it > | an exceptional situation that we can safely ignore? > > > Since this happens all too frequently, we must deal with it. > The Internet is not a centrally run function. Instead it > grows organically by the needs of the users. In other words, > the links only show up where they make economic sense. And > those are the links that users will use, ignoring the consequences. > > > | Since the scalability of geographical aggregation depends > | on the number > | of internet users and the size of the aggregation areas, > | where each > | aggregation area needs at least two interconnects, it > | would seem that > | the scalability of geographical multihoming isn't a > problem: more > | multihomers means more routes in an area, but since more > end-users > | means more interconnects, the areas shrink. So the number > | of routes per > | area should remain fairly constant. > > > If the routes are proportional to the number of areas and the > areas are growing, then you again have a rapidly growing > routing table. > > As we concluded many years ago: for addressing to scale, it > has to match the topology. If addressing does not match the > topology, then additional information in the form of longer > prefixes must be advertised into the routing subsystem. > Ergo, if one chooses geographic address, one must force only > geographically based links. Anything else destroys the > aggregatability of the address assignment. Since we, as IETF > members, cannot decree where folks will connect, geo > addressing is a nice theorectical goal which is unimplementable. > Only if you insist on the absolute minimum size routing table. As you said above, economics drive the decisions of network managers. There is a balance somewhere here between circuit costs for random interconnects, and the cost of the routing table to support that. All we need to do is provide a mechanism that allows for rational decisions about system cost to be made. A mechanism that results in lower costs for those that choose to multihome in a small geographic region will win out. Tony From owner-multi6@ops.ietf.org Wed Apr 2 14:28:54 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24308 for ; Wed, 2 Apr 2003 14:28:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 190nvX-0009QM-00 for multi6-data@psg.com; Wed, 02 Apr 2003 11:29:39 -0800 Received: from evrtwa1-ar8-4-65-019-240.evrtwa1.dsl-verizon.net ([4.65.19.240] helo=tndh.net) by psg.com with esmtp (Exim 3.36 #1) id 190nvV-0009Q9-00 for multi6@ops.ietf.org; Wed, 02 Apr 2003 11:29:37 -0800 Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Wed, 02 Apr 2003 11:29:35 -0800 Reply-To: From: "Tony Hain" To: "'Tony Li'" , "'marcelo bagnulo'" Cc: "'Iljitsch van Beijnum'" , Subject: RE: Geo pros and cons Date: Wed, 2 Apr 2003 11:29:32 -0800 Message-ID: <09af01c2f94e$3083e230$ee1a4104@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: X-Spam-Status: No, hits=-26.0 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Tony Li wrote: > Marcelo, > > Yes, there are regions where geo addressing makes sense. > Here in the SF bay area, where it's hard not to trip over all of > the fiber that we have lying around, it would play out > beautifully. Theoretically. > > However, even in this location, where we have multiple > interconnect points, we can observe that the local ISPs do > not choose to connect at all of the interconnects. Some > are at Fix-W, some at Equinix, some at PAIX, etc.... Even > in this environment we are not yet at the point where geo > addressing would not require us to force particular links to > be installed. > You miss the point that the ISPs with the customers demanding PI space would be the ones that would need to connect to the designated geo interconnects. This aligns the economics with those creating the need. Tony From owner-multi6@ops.ietf.org Wed Apr 2 14:48:28 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25399 for ; Wed, 2 Apr 2003 14:48:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 190oDf-000Cm7-00 for multi6-data@psg.com; Wed, 02 Apr 2003 11:48:23 -0800 Received: from dmz1.procket.com ([65.174.124.36]) by psg.com with esmtp (Exim 3.36 #1) id 190oDV-000Cks-00 for multi6@ops.ietf.org; Wed, 02 Apr 2003 11:48:13 -0800 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id 110AE23C39; Wed, 2 Apr 2003 11:38:00 -0800 (PST) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h32JmCYD017970; Wed, 2 Apr 2003 11:48:12 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Geo pros and cons Date: Wed, 2 Apr 2003 11:48:12 -0800 Message-ID: Thread-Topic: Geo pros and cons Thread-Index: AcL5TavUkTVPOJnWRZ68jWyyP702BgAAjpyg From: "Tony Li" To: , "Iljitsch van Beijnum" , X-Spam-Status: No, hits=-6.6 required=5.0 tests=BAYES_01 version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA25399 | From: Tony Hain [mailto:alh-ietf@tndh.net] | > As we concluded many years ago: for addressing to scale, it | > has to match the topology. If addressing does not match the | > topology, then additional information in the form of longer | > prefixes must be advertised into the routing subsystem. | > Ergo, if one chooses geographic address, one must force only | > geographically based links. Anything else destroys the | > aggregatability of the address assignment. Since we, as IETF | > members, cannot decree where folks will connect, geo | > addressing is a nice theorectical goal which is unimplementable. | > | Only if you insist on the absolute minimum size routing | table. If we were to insist on the minimum size routing table, we would have to decree that the entire Internet was a single binary tree. No thanks. | As you | said above, economics drive the decisions of network | managers. There is | a balance somewhere here between circuit costs for random | interconnects, | and the cost of the routing table to support that. All we | need to do is | provide a mechanism that allows for rational decisions | about system cost | to be made. A mechanism that results in lower costs for those that | choose to multihome in a small geographic region will win out. If we could provide a mechanism that allows for globally rational decisions about system cost to be made, we could and would deploy it today. You may recall from the CIDR wars that we briefly discussed and tried to encourage a mechanism that caused economic pushback for individual routes in the DFZ. It never went anywhere. If you want to charge to accept routes and your competition doesn't, you lose. This boils down to simple game theory: we can expect that almost everyone will act in their own best interest, at the expense of the common good. We are not empowered to edict the economics of the situation, so we'd best come up with a solution that organizes the chaos that others will foist upon us. Tony From owner-multi6@ops.ietf.org Wed Apr 2 14:49:03 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25422 for ; Wed, 2 Apr 2003 14:49:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 190oFH-000D3Q-00 for multi6-data@psg.com; Wed, 02 Apr 2003 11:50:03 -0800 Received: from dmz1.procket.com ([65.174.124.36]) by psg.com with esmtp (Exim 3.36 #1) id 190oFC-000D2b-00 for multi6@ops.ietf.org; Wed, 02 Apr 2003 11:49:58 -0800 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id DA4AC23C39; Wed, 2 Apr 2003 11:39:44 -0800 (PST) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h32JnrYB018038; Wed, 2 Apr 2003 11:49:53 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Geo pros and cons Date: Wed, 2 Apr 2003 11:49:53 -0800 Message-ID: Thread-Topic: Geo pros and cons Thread-Index: AcL5TjYgzRn5A2y+S2iUuvo/HUmj2AAAqd2Q From: "Tony Li" To: , "marcelo bagnulo" Cc: "Iljitsch van Beijnum" , X-Spam-Status: No, hits=-6.6 required=5.0 tests=BAYES_01 version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA25422 | You miss the point that the ISPs with the customers | demanding PI space | would be the ones that would need to connect to the designated geo | interconnects. This aligns the economics with those | creating the need. You miss the point that those same customers will simply browbeat the ISPs to advertise longer prefixes. Tony From owner-multi6@ops.ietf.org Wed Apr 2 16:29:48 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10245 for ; Wed, 2 Apr 2003 16:29:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 190pmh-0002ZK-00 for multi6-data@psg.com; Wed, 02 Apr 2003 13:28:39 -0800 Received: from ip166.usw12.rb1.bel.nwlink.com ([209.20.253.166] helo=ran.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 190pmf-0002Z8-00 for multi6@ops.ietf.org; Wed, 02 Apr 2003 13:28:37 -0800 Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.12) id 190pmX-0004Ma-00; Wed, 02 Apr 2003 13:28:29 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 2 Apr 2003 13:28:28 -0800 To: "Tony Li" Cc: , "marcelo bagnulo" , "Iljitsch van Beijnum" , Subject: RE: Geo pros and cons References: Message-Id: X-Spam-Status: No, hits=-15.5 required=5.0 tests=BAYES_10,QUOTED_EMAIL_TEXT,REFERENCES autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> You miss the point that the ISPs with the customers demanding PI space >> would be the ones that would need to connect to the designated geo >> interconnects. This aligns the economics with those creating the need. > You miss the point that those same customers will simply browbeat the ISPs > to advertise longer prefixes. s/browbeat/pay/ in all cases i know of isps who length filter, they accept just about anything shorter than a /25 from customers and advertise. they just don't expect their peers to always listen. randy From owner-multi6@ops.ietf.org Wed Apr 2 21:43:04 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21881 for ; Wed, 2 Apr 2003 21:43:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 190uf1-000DgE-00 for multi6-data@psg.com; Wed, 02 Apr 2003 18:41:03 -0800 Received: from mailout.zma.compaq.com ([161.114.64.104] helo=zmamail04.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 190ueW-000DUk-00 for multi6@ops.ietf.org; Wed, 02 Apr 2003 18:40:32 -0800 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id E1CDE6954; Wed, 2 Apr 2003 21:34:44 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 2 Apr 2003 21:34:44 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Geo pros and cons Date: Wed, 2 Apr 2003 21:34:44 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03ABD005@tayexc13.americas.cpqcorp.net> Thread-Topic: Geo pros and cons Thread-Index: AcL5TjYgzRn5A2y+S2iUuvo/HUmj2AAAqd2QAA4ow4A= From: "Bound, Jim" To: "Tony Li" , , "marcelo bagnulo" Cc: "Iljitsch van Beijnum" , X-OriginalArrivalTime: 03 Apr 2003 02:34:44.0812 (UTC) FILETIME=[965A20C0:01C2F989] X-Spam-Status: No, hits=-6.6 required=5.0 tests=BAYES_01 version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id VAA21881 Just as note one ISP that is large just told us NO WAY. They stuck to their guns. I agreed with them. /jim >-----Original Message----- >From: Tony Li [mailto:Tony.Li@procket.com] >Sent: Wednesday, April 02, 2003 2:50 PM >To: alh-ietf@tndh.net; marcelo bagnulo >Cc: Iljitsch van Beijnum; multi6@ops.ietf.org >Subject: RE: Geo pros and cons > > > > >| You miss the point that the ISPs with the customers >| demanding PI space >| would be the ones that would need to connect to the designated geo >| interconnects. This aligns the economics with those >| creating the need. > > >You miss the point that those same customers will simply >browbeat the ISPs to advertise longer prefixes. > >Tony > > From owner-multi6@ops.ietf.org Thu Apr 3 04:32:40 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11353 for ; Thu, 3 Apr 2003 04:32:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19114M-000HXv-00 for multi6-data@psg.com; Thu, 03 Apr 2003 01:31:38 -0800 Received: from smtp01.uc3m.es ([163.117.136.121] helo=smtp.uc3m.es) by psg.com with esmtp (Exim 3.36 #1) id 19114F-000HXa-00 for multi6@ops.ietf.org; Thu, 03 Apr 2003 01:31:31 -0800 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id 07A30432B3; Thu, 3 Apr 2003 11:31:30 +0200 (CEST) Received: from presto.it.uc3m.es (presto.it.uc3m.es [163.117.139.134]) by smtp01.uc3m.es (Postfix) with ESMTP id 9E62099E77; Thu, 3 Apr 2003 11:31:29 +0200 (CEST) Subject: RE: Geo pros and cons From: marcelo bagnulo To: Tony Li Cc: Iljitsch van Beijnum , multi6@ops.ietf.org In-Reply-To: References: Content-Type: text/plain Organization: uc3m Message-Id: <1049362270.760.8.camel@presto.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 03 Apr 2003 11:31:10 +0200 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-38.8 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_XIMIAN autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Tony On Wed, 2003-04-02 at 20:39, Tony Li wrote: > Marcelo, > > Yes, there are regions where geo addressing makes sense. Here > in the SF bay area, where it's hard not to trip over all of > the fiber that we have lying around, it would play out > beautifully. Theoretically. > > However, even in this location, where we have multiple > interconnect points, we can observe that the local ISPs do > not choose to connect at all of the interconnects. Some > are at Fix-W, some at Equinix, some at PAIX, etc.... Even > in this environment we are not yet at the point where geo > addressing would not require us to force particular links to > be installed. This is my question. do you have some data about the real topology that indicates that even in areas where the interconnection is dense there are still unconnected peers? I agree with you in this point and I am certainly not suggesting forcing the existence of links, just some sort of opportunistic usage of geo aggregation. In areas where the interconnection exists, evaluate the possibility of using geo addressing. If within the geo area the interconnection is partitioned, just don't use it Regards, marcelo > > I dunno about you, but I don't like pushing string. > > Tony > > > | -----Original Message----- > | From: marcelo bagnulo [mailto:marcelo@it.uc3m.es] > | Sent: Wednesday, April 02, 2003 7:14 AM > | To: Tony Li > | Cc: Iljitsch van Beijnum; multi6@ops.ietf.org > | Subject: RE: Geo pros and cons > | > | > | Hi Tony, > | > | [...] > | > As we concluded many years ago: for addressing to scale, it has > | > to match the topology. > | > | Fully agree. > | I would say that the question is if topology matches > | geography or not. > | > | I have heard many claims that the Internet is becoming a dense > | interconnection mesh. If this is true, it should be easy > | to determine > | geographical areas that are interconnected, so geo > | aggregation works > | without the need of more specific routes. > | > | I think that this is certainly not the case for all geo > | locations, but i > | would say that it is probably the case for some locations > | as big cities > | where a lot of users reside. Wouldn't geo addressing be > | suitable for > | this situations? > | > | I am not aware of any analysis of how dense is the > | interconnection in > | geo areas, but i would say that this input is important > | when considering > | geo addressing. Does anyone have information about this? > | > | Thanks, marcelo > | > | > | > If addressing does not match the topology, > | > then additional information in the form of longer > | prefixes must be > | > advertised into the routing subsystem. Ergo, if one > | chooses geographic > | > address, one must force only geographically based links. > | Anything > | > else destroys the aggregatability of the address > | assignment. Since > | > we, as IETF members, cannot decree where folks will connect, geo > | > addressing is a nice theorectical goal which is unimplementable. > | > > | > Regards, > | > Tony > | -- > | marcelo bagnulo > | uc3m > | > | -- marcelo bagnulo uc3m From owner-multi6@ops.ietf.org Thu Apr 3 05:34:50 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12780 for ; Thu, 3 Apr 2003 05:34:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19123A-0004cf-00 for multi6-data@psg.com; Thu, 03 Apr 2003 02:34:28 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 191235-0004cT-00 for multi6@ops.ietf.org; Thu, 03 Apr 2003 02:34:23 -0800 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h33AXI628351; Thu, 3 Apr 2003 12:33:18 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Thu, 3 Apr 2003 12:33:04 +0200 Subject: Re: Geo pros and cons Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: To: "Tony Li" From: Iljitsch van Beijnum In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On woensdag, apr 2, 2003, at 01:38 Europe/Amsterdam, Tony Li wrote: > | Now obviously it is possible to lease a circuit to a > | remote location > | and connect to "the internet" in that location rather than > | close to home. > Since this happens all too frequently, we must deal with it. Sure. But I say we deal with it as an exceptional situation that may require additional resources rather than accept this as regular so regular mechanisms must be able to fullly support this. > The Internet is not a centrally run function. Instead it grows > organically by the needs of the users. In other words, the links > only show up where they make economic sense. Being routable makes economic sense. > If the routes are proportional to the number of areas and the areas > are growing, then you again have a rapidly growing routing table. The routes are proportional to the number of users in an area. I assert that for areas above a certain minimum geographic size, the number of users in an area is fairly constant. > As we concluded many years ago: for addressing to scale, it has > to match the topology. If addressing does not match the topology, > then additional information in the form of longer prefixes must be > advertised into the routing subsystem. Ergo, if one chooses geographic > address, one must force only geographically based links. Aggregation isn't a binary thing. CIDR can aggregate PA address space but not PI address space. Before CIDR, PI was the norm but now it's quite rare. With geographical aggregation the same will happen: in the beginning, aggregation will be limited. But unlike CIDR, you don't have to renumber to start aggregating: when a new local or regional link becomes available, you immediately gain aggregation. Also, the requirement for "geographically based links" doesn't have to be all that bad. If network A wants to handle the Italy geo region in Milan, but network B wants to do this in Chicago, they can use a "geographically based link" to peer between A's Milan router and B's Chicago router. With something like ATM or MPLS this is easy to implement. > Anything > else destroys the aggregatability of the address assignment. Since > we, as IETF members, cannot decree where folks will connect, geo > addressing is a nice theorectical goal which is unimplementable. I agree that geographic aggregation doesn't look all that good in theory, and that it lacks long term scalability. However, it's still much, much better than "straight PI" where we know the potential for aggregation is 0. For geo, we know the potential for aggregation is less than 1, but at least it's more than 0. So in the absense of better short-term solutions (unless you include forbidding multihoming as a short term "solution") and considering the fact that this can be implemented relatively painlessly, I think it is worth it. From owner-multi6@ops.ietf.org Thu Apr 3 05:38:34 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12858 for ; Thu, 3 Apr 2003 05:38:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19127s-0005QO-00 for multi6-data@psg.com; Thu, 03 Apr 2003 02:39:20 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 19127p-0005Oc-00 for multi6@ops.ietf.org; Thu, 03 Apr 2003 02:39:17 -0800 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h33AcE628359; Thu, 3 Apr 2003 12:38:14 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Thu, 3 Apr 2003 12:38:00 +0200 Subject: Re: Geo pros and cons Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: multi6@ops.ietf.org To: marcelo bagnulo From: Iljitsch van Beijnum In-Reply-To: <1049362270.760.8.camel@presto.it.uc3m.es> Message-Id: <57754B88-65C0-11D7-9E89-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On donderdag, apr 3, 2003, at 11:31 Europe/Amsterdam, marcelo bagnulo wrote: > I am certainly not suggesting forcing > the existence of links, just some sort of opportunistic usage of geo > aggregation. In areas where the interconnection exists, evaluate the > possibility of using geo addressing. If within the geo area the > interconnection is partitioned, just don't use it No, multihomers should (nearly) always use geo addresses, even if they can't be aggregated at that point. Then, when the network topology changes so that aggregation becomes possible, the end-users don't have to renumber. Also note that there is no need to have areas of a fixed size. If you can't aggregate within Germany because the east and the west are still partitioned, you can at least aggregate at the Europe or western Europe level and spare the rest of the world from having to carry all German /48s. From owner-multi6@ops.ietf.org Thu Apr 3 05:51:43 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13186 for ; Thu, 3 Apr 2003 05:51:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 1912KP-0008aj-00 for multi6-data@psg.com; Thu, 03 Apr 2003 02:52:17 -0800 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 1912KM-0008Yv-00 for multi6@ops.ietf.org; Thu, 03 Apr 2003 02:52:14 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h33Apwj25605; Thu, 3 Apr 2003 13:51:58 +0300 Date: Thu, 3 Apr 2003 13:51:58 +0300 (EEST) From: Pekka Savola To: Iljitsch van Beijnum cc: Tony Li , Subject: geo short vs long term? [Re: Geo pros and cons] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-31.7 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk On Thu, 3 Apr 2003, Iljitsch van Beijnum wrote: > So in the absense of better > short-term solutions (unless you include forbidding multihoming as a > short term "solution") and considering the fact that this can be > implemented relatively painlessly, I think it is worth it. I would not classify geo as a short-term solution. Sure, it can be implemented rather quickly, no doubt about that. For the first years "geo" is probably just a shorthand for "advertise full /48's from under specific geo-prefix". And in 3-5 years when we try to start aggregating, we might run into troubles. And what do we do if we can't solve those problems sufficiently? But can it be unimplemented if that's seen fit? Doesn't seem likely. So it seems to me that if we go for geo, we go for good. Which is why a lot of deliberation is required. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Thu Apr 3 07:24:12 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17350 for ; Thu, 3 Apr 2003 07:24:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 1913l3-00042A-00 for multi6-data@psg.com; Thu, 03 Apr 2003 04:23:53 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 1913l0-00041y-00 for multi6@ops.ietf.org; Thu, 03 Apr 2003 04:23:51 -0800 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h33CMl628539; Thu, 3 Apr 2003 14:22:47 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Thu, 3 Apr 2003 14:22:33 +0200 Subject: Re: geo short vs long term? [Re: Geo pros and cons] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: To: Pekka Savola From: Iljitsch van Beijnum In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On donderdag, apr 3, 2003, at 12:51 Europe/Amsterdam, Pekka Savola wrote: > I would not classify geo as a short-term solution. Short to intermediate term. > Sure, it can be implemented rather quickly, no doubt about that. For > the > first years "geo" is probably just a shorthand for "advertise full > /48's > from under specific geo-prefix". Agree. > And in 3-5 years when we try to start > aggregating, we might run into troubles. And what do we do if we can't > solve those problems sufficiently? We have to make sure we know in advance that we can handle all reasonable eventualities. > But can it be unimplemented if that's seen fit? Doesn't seem likely. The idea is that we create an upgrade path. Geographically aggregatable PI addresses could be used as identifiers in an identifier/locator separation solution. That way, we can get rid of the geo /48s in the routing table without the need for renumbering. From your previous message: > Similar seems to apply to geo-like approaches depending on > geo-aggregates. > Who (at the originating region) is creating the aggregate? And more > importantly, *why* should the sites or ISP's in the region be > encouraged > to *not* advertise their more specific geo prefix *anyway* (assuming > the > geo routing infrastructure might require that under some conditions)? ISPs are _supposed_ to announce all geo /48s for their customers everywhere. Aggregation happens inside each individual ISP network by creating private aggregates and selectively filtering geo /48s in certain routers. The only way for peer networks to frustrate aggration is to not interconnect or not announce geo /48s in the expected interconnect location. It seems likely that the largest networks will gravitate towards a common level of aggregation that conforms to the level of interconnection between those networks. Successfully aggregating more aggressively than this will be hard, and not announcing geo /48s in the closest place you interconnect makes no sense. When this has happened, smaller networks will be forced to play along and interconnect there where the large networks expect them to because large networks often can't be bothered to peer anyway, and breaking aggregation isn't likely to be a plus. For smaller networks aggregating is simple, as they can always dump traffic for which they have aggregated away the /48s in one of their transit's laps. From owner-multi6@ops.ietf.org Thu Apr 3 07:37:41 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17652 for ; Thu, 3 Apr 2003 07:37:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 1913ye-0007ao-00 for multi6-data@psg.com; Thu, 03 Apr 2003 04:37:56 -0800 Received: from ginger.lcs.mit.edu ([18.26.0.82]) by psg.com with esmtp (Exim 3.36 #1) id 1913yc-0007Za-00 for multi6@ops.ietf.org; Thu, 03 Apr 2003 04:37:54 -0800 Received: from ginger.lcs.mit.edu (localhost [127.0.0.1]) by ginger.lcs.mit.edu (8.12.9/8.12.9) with ESMTP id h33CbotU017014; Thu, 3 Apr 2003 07:37:50 -0500 Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.12.9/8.12.9/Submit) id h33Cbn1A017013; Thu, 3 Apr 2003 07:37:49 -0500 Date: Thu, 3 Apr 2003 07:37:49 -0500 From: "J. Noel Chiappa" Message-Id: <200304031237.h33Cbn1A017013@ginger.lcs.mit.edu> To: multi6@ops.ietf.org Subject: Re: geo short vs long term? [Re: Geo pros and cons] Cc: jnc@ginger.lcs.mit.edu X-Spam-Status: No, hits=-6.6 required=5.0 tests=BAYES_01 version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Look, everyone, this is all really stupid. Geographic addressing has been discussed extensively about 17 times in the IETF, and every time it has been rejected. Discussing it one more time is not going to change this. There is *never* going to be a rough consensus *in favour of* geographic addressing. There will *always* be a lot of people against it - enough to stop it in the proposal stage. The really sad thing is that something productive might have been done with all this time and energy that's being wasted. Noel From owner-multi6@ops.ietf.org Thu Apr 3 08:10:15 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18760 for ; Thu, 3 Apr 2003 08:10:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 1914UG-000GI6-00 for multi6-data@psg.com; Thu, 03 Apr 2003 05:10:36 -0800 Received: from ipl-67-0142.pppoe.stargate.net ([206.210.67.142] helo=localhost) by psg.com with esmtp (Exim 3.36 #1) id 1914UE-000GHu-00 for multi6@ops.ietf.org; Thu, 03 Apr 2003 05:10:34 -0800 Received: from [192.168.1.100] (localhost [127.0.0.1]) by localhost (8.12.7/8.12.2) with ESMTP id h33DAbDc000973 for ; Thu, 3 Apr 2003 08:10:37 -0500 (EST) Date: Thu, 03 Apr 2003 08:10:36 -0500 From: "Michael H. Lambert" To: multi6@ops.ietf.org Subject: Re: geo short vs long term? [Re: Geo pros and cons] Message-ID: <1125058.1049357436@[192.168.1.100]> In-Reply-To: <200304031237.h33Cbn1A017013@ginger.lcs.mit.edu> References: <200304031237.h33Cbn1A017013@ginger.lcs.mit.edu> X-Mailer: Mulberry/2.2.1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=-26.0 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Noel, Since you have more historical context than many of us on the list, could you please summarize the arguments which have been used against geo? I suspect that they are mainly financial and political, but there might be technical issues I'm unaware of. Thanks, Michael --On Thursday, 3 April 2003 07:37 -0500 "J. Noel Chiappa" wrote: > Geographic addressing has been discussed extensively about 17 times in the > IETF, and every time it has been rejected. Discussing it one more time is > not going to change this. There is *never* going to be a rough consensus > *in favour of* geographic addressing. There will *always* be a lot of > people against it - enough to stop it in the proposal stage. From owner-multi6@ops.ietf.org Thu Apr 3 08:13:42 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18824 for ; Thu, 3 Apr 2003 08:13:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 1914Y4-000HWI-00 for multi6-data@psg.com; Thu, 03 Apr 2003 05:14:32 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 1914Y0-000HW2-00 for multi6@ops.ietf.org; Thu, 03 Apr 2003 05:14:28 -0800 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h33DDO628601; Thu, 3 Apr 2003 15:13:24 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Thu, 3 Apr 2003 15:13:10 +0200 Subject: Re: geo short vs long term? [Re: Geo pros and cons] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: multi6@ops.ietf.org To: "J. Noel Chiappa" From: Iljitsch van Beijnum In-Reply-To: <200304031237.h33Cbn1A017013@ginger.lcs.mit.edu> Message-Id: <04DE3721-65D6-11D7-8DC3-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On donderdag, apr 3, 2003, at 14:37 Europe/Amsterdam, J. Noel Chiappa wrote: > Look, everyone, this is all really stupid. > Geographic addressing has been discussed extensively about 17 times in > the > IETF, and every time it has been rejected. Discussing it one more time > is not > going to change this. There is *never* going to be a rough consensus > *in > favour of* geographic addressing. There will *always* be a lot of > people > against it - enough to stop it in the proposal stage. If we sail too far to the west we fall off the earth and bumblebees can't fly. Since explaining it all again is unlikely to make a difference, I'll just observe that none of the objections I've heard to date include a part where they show "if you implement this, under reasonable real-world conditions W and X, router Y will need a routing table of Z routes, which is too large". From owner-multi6@ops.ietf.org Thu Apr 3 08:28:34 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19253 for ; Thu, 3 Apr 2003 08:28:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 1914lP-000LAu-00 for multi6-data@psg.com; Thu, 03 Apr 2003 05:28:19 -0800 Received: from zmamail05.zma.compaq.com ([161.114.64.105]) by psg.com with esmtp (Exim 3.36 #1) id 1914lM-000LAF-00 for multi6@ops.ietf.org; Thu, 03 Apr 2003 05:28:16 -0800 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id AEDA7A8D9; Thu, 3 Apr 2003 08:28:15 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 3 Apr 2003 08:28:15 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: geo short vs long term? [Re: Geo pros and cons] Date: Thu, 3 Apr 2003 08:28:15 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03ABD017@tayexc13.americas.cpqcorp.net> Thread-Topic: geo short vs long term? [Re: Geo pros and cons] Thread-Index: AcL55C6AG9pEVv5jSVO5UzYdjIe4qgAAEvsQ From: "Bound, Jim" To: "Iljitsch van Beijnum" , "J. Noel Chiappa" Cc: X-OriginalArrivalTime: 03 Apr 2003 13:28:15.0640 (UTC) FILETIME=[E1D3A980:01C2F9E4] X-Spam-Status: No, hits=-9.8 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA19253 I suggest if a subject has consenus even appearance of that and even if it was rehashed then just ask the list. I felt the same as Noel but at the IETF sat down and talked to a few of you and you have convinced me to listen. One thing we need to identify and note. If anyone objects to all ideas and builds not draft or solution or concrete roll up your sleeves proposal then that one is suspect for success here. My view is no decision is the worst decision. /jim > -----Original Message----- > From: Iljitsch van Beijnum [mailto:iljitsch@muada.com] > Sent: Thursday, April 03, 2003 8:13 AM > To: J. Noel Chiappa > Cc: multi6@ops.ietf.org > Subject: Re: geo short vs long term? [Re: Geo pros and cons] > > > On donderdag, apr 3, 2003, at 14:37 Europe/Amsterdam, J. Noel Chiappa > wrote: > > > Look, everyone, this is all really stupid. > > > Geographic addressing has been discussed extensively about > 17 times in > > the > > IETF, and every time it has been rejected. Discussing it > one more time > > is not > > going to change this. There is *never* going to be a rough > consensus > > *in > > favour of* geographic addressing. There will *always* be a lot of > > people > > against it - enough to stop it in the proposal stage. > > If we sail too far to the west we fall off the earth and bumblebees > can't fly. > > Since explaining it all again is unlikely to make a difference, I'll > just observe that none of the objections I've heard to date include a > part where they show "if you implement this, under reasonable > real-world conditions W and X, router Y will need a routing > table of Z > routes, which is too large". > > > From owner-multi6@ops.ietf.org Thu Apr 3 08:31:14 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19342 for ; Thu, 3 Apr 2003 08:31:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 1914p1-000MAT-00 for multi6-data@psg.com; Thu, 03 Apr 2003 05:32:03 -0800 Received: from maunaloa.aafes.com ([199.67.7.206]) by psg.com with esmtp (Exim 3.36 #1) id 1914ox-000M8A-00 for multi6@ops.ietf.org; Thu, 03 Apr 2003 05:32:00 -0800 Received: (from daemon@localhost) by maunaloa.aafes.com (8.12.8/8.12.8) id h33DVqOS072627; Thu, 3 Apr 2003 07:31:52 -0600 (CST) Received: from hqexch01.aafes.com(192.168.32.32) via SMTP by maunaloa.aafes.com, id smtpdQIFP1B; Thu Apr 3 07:31:39 2003 Received: by hqexch01.aafes.com with Internet Mail Service (5.5.2655.55) id ; Thu, 3 Apr 2003 07:30:22 -0600 Message-ID: From: "Grovesteen, Harold" To: "'Iljitsch van Beijnum'" , Tony Li Cc: multi6@ops.ietf.org Subject: RE: Geo pros and cons Date: Thu, 3 Apr 2003 07:30:18 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=-22.6 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,ORIGINAL_MESSAGE, QUOTED_EMAIL_TEXT autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk This definitely gets my vote! This solves my short term problem (next two years) without destroying the longer term goals of PA. After that I could easily be faced with bigger issues. My other short term answer is two 6to4 tunnels to each of my two IPv6 transit providers sourced from two routers. This provides identical reachability and failure survivability as IPv4 and eliminates the address selection issues and ingress filtering problems for either clients or servers (the priority for me). Both prefixes are advertised by both IPv6 transit providers. Not clean but workable. Just have to get the transit provider to agree to two tunnels. That's where the brow beating comes in. Harold Grovesteen -----Original Message----- From: Iljitsch van Beijnum [mailto:iljitsch@muada.com] Sent: Thursday, April 03, 2003 4:33 AM To: Tony Li Cc: multi6@ops.ietf.org Subject: Re: Geo pros and cons On woensdag, apr 2, 2003, at 01:38 Europe/Amsterdam, Tony Li wrote: > | Now obviously it is possible to lease a circuit to a > | remote location > | and connect to "the internet" in that location rather than > | close to home. > Since this happens all too frequently, we must deal with it. Sure. But I say we deal with it as an exceptional situation that may require additional resources rather than accept this as regular so regular mechanisms must be able to fullly support this. > The Internet is not a centrally run function. Instead it grows > organically by the needs of the users. In other words, the links > only show up where they make economic sense. Being routable makes economic sense. > If the routes are proportional to the number of areas and the areas > are growing, then you again have a rapidly growing routing table. The routes are proportional to the number of users in an area. I assert that for areas above a certain minimum geographic size, the number of users in an area is fairly constant. > As we concluded many years ago: for addressing to scale, it has > to match the topology. If addressing does not match the topology, > then additional information in the form of longer prefixes must be > advertised into the routing subsystem. Ergo, if one chooses geographic > address, one must force only geographically based links. Aggregation isn't a binary thing. CIDR can aggregate PA address space but not PI address space. Before CIDR, PI was the norm but now it's quite rare. With geographical aggregation the same will happen: in the beginning, aggregation will be limited. But unlike CIDR, you don't have to renumber to start aggregating: when a new local or regional link becomes available, you immediately gain aggregation. Also, the requirement for "geographically based links" doesn't have to be all that bad. If network A wants to handle the Italy geo region in Milan, but network B wants to do this in Chicago, they can use a "geographically based link" to peer between A's Milan router and B's Chicago router. With something like ATM or MPLS this is easy to implement. > Anything > else destroys the aggregatability of the address assignment. Since > we, as IETF members, cannot decree where folks will connect, geo > addressing is a nice theorectical goal which is unimplementable. I agree that geographic aggregation doesn't look all that good in theory, and that it lacks long term scalability. However, it's still much, much better than "straight PI" where we know the potential for aggregation is 0. For geo, we know the potential for aggregation is less than 1, but at least it's more than 0. So in the absense of better short-term solutions (unless you include forbidding multihoming as a short term "solution") and considering the fact that this can be implemented relatively painlessly, I think it is worth it. From owner-multi6@ops.ietf.org Thu Apr 3 08:34:17 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19417 for ; Thu, 3 Apr 2003 08:34:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 1914rq-000Mm8-00 for multi6-data@psg.com; Thu, 03 Apr 2003 05:34:58 -0800 Received: from ginger.lcs.mit.edu ([18.26.0.82]) by psg.com with esmtp (Exim 3.36 #1) id 1914rl-000Mhg-00 for multi6@ops.ietf.org; Thu, 03 Apr 2003 05:34:54 -0800 Received: from ginger.lcs.mit.edu (localhost [127.0.0.1]) by ginger.lcs.mit.edu (8.12.9/8.12.9) with ESMTP id h33DYqtU017428; Thu, 3 Apr 2003 08:34:52 -0500 Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.12.9/8.12.9/Submit) id h33DYp18017427; Thu, 3 Apr 2003 08:34:51 -0500 Date: Thu, 3 Apr 2003 08:34:51 -0500 From: "J. Noel Chiappa" Message-Id: <200304031334.h33DYp18017427@ginger.lcs.mit.edu> To: multi6@ops.ietf.org Subject: Re: geo short vs long term? [Re: Geo pros and cons] Cc: jnc@ginger.lcs.mit.edu X-Spam-Status: No, hits=-6.6 required=5.0 tests=BAYES_01 version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: "Michael H. Lambert" >> Geographic addressing has been discussed extensively about 17 times in >> the IETF, and every time it has been rejected. Discussing it one more >> time is not going to change this. There is *never* going to be a rough >> consensus *in favour of* geographic addressing. There will *always* be >> a lot of people against it > Since you have more historical context than many of us on the list, > could you please summarize the arguments which have been used against > geo? I suspect that they are mainly financial and political, but there > might be technical issues I'm unaware of. Actually, I don't think that's quite correct: the argument against it is in fact rooted in technical issues, although there are non-technical issues in the later stages. The analysis of geographic has been fairly well summarized in recent discussion here on the list, but very simply, it goes: - i) for the overhead of the routing to scale, the hierarchy of addressing abstractions has to be reasonably closely related to the actual interconnection topology; - ii) this means that either connectivity has to follow addressing, or addressing has to follow connectivity; - iii) the IETF cannot mandate where connectivity gets added; - iv) connectivity gets put in where there are actual traffic flows and/or commercial reasons to put it in. Therefore we have to have the addressing follow the connectivity, and an addressing scheme such as geographic, which to scale needs to have the connectivity follow the addressing, is not feasible. Noel PS: Everyone, about the "this is stupid" comment - that wasn't directed at anyone in particular, but at all of us, me included. I suddenly had my brain start to function, and realized that there is never going to be *rough consensus in favour of geographic* - which is what we'd need to go forward with it - and therefore further discussion thereof is not useful. I hope I didn't offend anyone - if I did, my apologies. From owner-multi6@ops.ietf.org Thu Apr 3 09:04:41 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20217 for ; Thu, 3 Apr 2003 09:04:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 1915L4-0004yF-00 for multi6-data@psg.com; Thu, 03 Apr 2003 06:05:10 -0800 Received: from mailout.zma.compaq.com ([161.114.64.104] helo=zmamail04.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 1915Kx-0004th-00 for multi6@ops.ietf.org; Thu, 03 Apr 2003 06:05:03 -0800 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id E2CD6693C; Thu, 3 Apr 2003 09:05:02 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 3 Apr 2003 09:05:02 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: geo short vs long term? [Re: Geo pros and cons] Date: Thu, 3 Apr 2003 09:05:02 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03ABD01E@tayexc13.americas.cpqcorp.net> Thread-Topic: geo short vs long term? [Re: Geo pros and cons] Thread-Index: AcL55wrg1Wza43FeT/iKVAL2/BodBAAApGhQ From: "Bound, Jim" To: "J. Noel Chiappa" , X-OriginalArrivalTime: 03 Apr 2003 14:05:02.0802 (UTC) FILETIME=[0565DB20:01C2F9EA] X-Spam-Status: No, hits=-9.8 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA20217 This is logical and makes sense. But practically, if say the U.S., Mexico, and Canada all had a toplevel GEO prefix would the connectivity issue still be real or just theoretical? Within this GEO if all had 2ffe then another set of bits for Mexico, U.S. and Canada how would that exacerbate routing problems in Austrailia or France? Thanks /jim > -----Original Message----- > From: J. Noel Chiappa [mailto:jnc@ginger.lcs.mit.edu] > Sent: Thursday, April 03, 2003 8:35 AM > To: multi6@ops.ietf.org > Cc: jnc@ginger.lcs.mit.edu > Subject: Re: geo short vs long term? [Re: Geo pros and cons] > > > > From: "Michael H. Lambert" > > >> Geographic addressing has been discussed extensively > about 17 times in > >> the IETF, and every time it has been rejected. > Discussing it one more > >> time is not going to change this. There is *never* > going to be a rough > >> consensus *in favour of* geographic addressing. There > will *always* be > >> a lot of people against it > > > Since you have more historical context than many of us > on the list, > > could you please summarize the arguments which have > been used against > > geo? I suspect that they are mainly financial and > political, but there > > might be technical issues I'm unaware of. > > Actually, I don't think that's quite correct: the argument > against it is in fact rooted in technical issues, although > there are non-technical issues in the later stages. > > The analysis of geographic has been fairly well summarized in > recent discussion here on the list, but very simply, it goes: > > - i) for the overhead of the routing to scale, the hierarchy > of addressing abstractions has to be reasonably closely > related to the actual interconnection topology; > - ii) this means that either connectivity has to follow > addressing, or addressing has to follow connectivity; > - iii) the IETF cannot mandate where connectivity gets added; > - iv) connectivity gets put in where there are actual traffic > flows and/or commercial reasons to put it in. > > Therefore we have to have the addressing follow the > connectivity, and an addressing scheme such as geographic, > which to scale needs to have the connectivity follow the > addressing, is not feasible. > > Noel > > > PS: Everyone, about the "this is stupid" comment - that > wasn't directed at anyone in particular, but at all of us, me > included. I suddenly had my brain start to function, and > realized that there is never going to be *rough consensus in > favour of geographic* - which is what we'd need to go forward > with it - and therefore further discussion thereof is not > useful. I hope I didn't offend anyone - if I did, my apologies. > > From owner-multi6@ops.ietf.org Thu Apr 3 10:22:15 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24537 for ; Thu, 3 Apr 2003 10:22:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 1916Xd-000PVv-00 for multi6-data@psg.com; Thu, 03 Apr 2003 07:22:13 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 1916XZ-000PVi-00 for multi6@ops.ietf.org; Thu, 03 Apr 2003 07:22:09 -0800 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h33FL5628834; Thu, 3 Apr 2003 17:21:05 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Thu, 3 Apr 2003 17:20:51 +0200 Subject: Re: geo short vs long term? [Re: Geo pros and cons] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: multi6@ops.ietf.org To: "J. Noel Chiappa" From: Iljitsch van Beijnum In-Reply-To: <200304031334.h33DYp18017427@ginger.lcs.mit.edu> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On donderdag, apr 3, 2003, at 15:34 Europe/Amsterdam, J. Noel Chiappa wrote: > i) for the overhead of the routing to scale, the hierarchy of > addressing > abstractions has to be reasonably closely related to the actual > interconnection topology; > - ii) this means that either connectivity has to follow addressing, or > addressing has to follow connectivity; > - iii) the IETF cannot mandate where connectivity gets added; > - iv) connectivity gets put in where there are actual traffic flows > and/or > commercial reasons to put it in. > Therefore we have to have the addressing follow the connectivity, and > an > addressing scheme such as geographic, which to scale needs to have the > connectivity follow the addressing, is not feasible. But does a addressing scheme that follows connectivity AND allows multihoming to a usable degree exist? If yes, now would be a good time to unveil it. If no, we need to select the addressing scheme that is slowest to fail scaling. From owner-multi6@ops.ietf.org Thu Apr 3 15:11:01 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10536 for ; Thu, 3 Apr 2003 15:11:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 191B23-000KHu-00 for multi6-data@psg.com; Thu, 03 Apr 2003 12:09:55 -0800 Received: from dmz2.procket.com ([65.174.124.37]) by psg.com with esmtp (Exim 3.36 #1) id 191B20-000KHf-00 for multi6@ops.ietf.org; Thu, 03 Apr 2003 12:09:52 -0800 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id 2DEB23443C; Thu, 3 Apr 2003 11:23:19 -0800 (PST) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h33K9pYB027729; Thu, 3 Apr 2003 12:09:51 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: geo short vs long term? [Re: Geo pros and cons] Date: Thu, 3 Apr 2003 12:09:51 -0800 Message-ID: Thread-Topic: geo short vs long term? [Re: Geo pros and cons] Thread-Index: AcL533dUe+653MfhQqGr2OPyPGH4lAAOwsBA From: "Tony Li" To: "J. Noel Chiappa" , X-Spam-Status: No, hits=-6.6 required=5.0 tests=BAYES_01 version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA10536 Noel, well said. More points: there are worse things than no decision. That would be the clearly wrong decision. We could, for example, choose to aggregate locators based on the lexographical ordering of the user's first name. We could choose not to aggregate and end up with another swamp. As to the issues with 'proving' that geo won't work, let me point out the very simple reasoning: - The Internet is continually growing at an exponential rate. Most people seem to peg the growth rate at 100% per year currently. The exact number is not an issue. - In the past, we've estimated that 10% of all sites would multi-home. Let's assume a constant rate of 10% of the world is an exception to the default aggregation rules that we pick. - From the above two, we can reason that our exception rate is going to continue to grow exponentially. Note that the rate of absolute growth is more of an issue than the exception rate. - Moore's law for memory suggests that memory sizes will double about every two years. However, memory speeds will not keep up. - Packet lookups are a function of memory bandwidth, so to sustain Internet bandwidth growth of 100% per year, we need to also increase memory bandwidth by about 100% per year. Using bigger, slower memories is not a realistic option. - Thus, the routing table really needs to be constrained to grow at about Moore's law for memory. - If the exceptions are growing at about 100% per year, and the memories are growing at about 100% every TWO years, then regardless of the starting point, the exceptions will overtake technology. - Therefore, we must find some mechanism that prevents the exceptions from growing at 100% per year. In short, the number of longer prefixes that are injected into routing cannot be a constant fraction of the number of sites that join. - Since everyone and their brother will want an exception for anything that they want to do that is outside of the norm, the norm MUST support almost every possible situation. Multihoming, in particular, must not cause exceptions. Even a constant percentage of multihomers must not cause exceptions. - For reasons that I've already explained, the economics of links in a geo system cause many sites to be exceptions. - Therefore, geo addressing leads to a system that will not scale for the long term. QED Tony | -----Original Message----- | From: J. Noel Chiappa [mailto:jnc@ginger.lcs.mit.edu] | Sent: Thursday, April 03, 2003 4:38 AM | To: multi6@ops.ietf.org | Cc: jnc@ginger.lcs.mit.edu | Subject: Re: geo short vs long term? [Re: Geo pros and cons] | | | Look, everyone, this is all really stupid. | | Geographic addressing has been discussed extensively about | 17 times in the | IETF, and every time it has been rejected. Discussing it | one more time is not | going to change this. There is *never* going to be a rough | consensus *in | favour of* geographic addressing. There will *always* be a | lot of people | against it - enough to stop it in the proposal stage. | | The really sad thing is that something productive might | have been done with | all this time and energy that's being wasted. | | Noel | | From owner-multi6@ops.ietf.org Thu Apr 3 15:17:00 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11286 for ; Thu, 3 Apr 2003 15:16:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 191B9g-000KcU-00 for multi6-data@psg.com; Thu, 03 Apr 2003 12:17:48 -0800 Received: from dmz2.procket.com ([65.174.124.37]) by psg.com with esmtp (Exim 3.36 #1) id 191B9a-000Kbr-00 for multi6@ops.ietf.org; Thu, 03 Apr 2003 12:17:42 -0800 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id 9FB893445C; Thu, 3 Apr 2003 11:31:08 -0800 (PST) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h33KHfYB028084; Thu, 3 Apr 2003 12:17:41 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: geo short vs long term? [Re: Geo pros and cons] Date: Thu, 3 Apr 2003 12:17:41 -0800 Message-ID: Thread-Topic: geo short vs long term? [Re: Geo pros and cons] Thread-Index: AcL55wrg1Wza43FeT/iKVAL2/BodBAAApGhQAAz32mA= From: "Tony Li" To: "Bound, Jim" , "J. Noel Chiappa" , X-Spam-Status: No, hits=-6.6 required=5.0 tests=BAYES_01 version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA11286 Jim, Yes, geo addressing at the continental level makes much more sense because the connectivity within a continent is pretty much a given. Not so at the metro or lower layers, so it doesn't recurse down nicely. Note that a hybrid system that was geo at the top and provider based below was proposed some 10 years ago, but some folks shouted it down because they didn't feel that the aggregation at the continental level would have a great effect. Of course, we had very few ISPs at that exact point in time and they were correct. For the moment. I would have zero issues with continental aggregation tied to lower layers that were topological. [Well, ok, I don't think that Antartica should get as much as China, but that's a nit. ;-) ] Tony | -----Original Message----- | From: Bound, Jim [mailto:Jim.Bound@hp.com] | Sent: Thursday, April 03, 2003 6:05 AM | To: J. Noel Chiappa; multi6@ops.ietf.org | Subject: RE: geo short vs long term? [Re: Geo pros and cons] | | | This is logical and makes sense. | | But practically, if say the U.S., Mexico, and Canada all | had a toplevel | GEO prefix would the connectivity issue still be real or just | theoretical? | | Within this GEO if all had 2ffe then another set of bits | for Mexico, | U.S. and Canada how would that exacerbate routing problems | in Austrailia | or France? | | Thanks | /jim | | | | | > -----Original Message----- | > From: J. Noel Chiappa [mailto:jnc@ginger.lcs.mit.edu] | > Sent: Thursday, April 03, 2003 8:35 AM | > To: multi6@ops.ietf.org | > Cc: jnc@ginger.lcs.mit.edu | > Subject: Re: geo short vs long term? [Re: Geo pros and cons] | > | > | > > From: "Michael H. Lambert" | > | > >> Geographic addressing has been discussed extensively | > about 17 times in | > >> the IETF, and every time it has been rejected. | > Discussing it one more | > >> time is not going to change this. There is *never* | > going to be a rough | > >> consensus *in favour of* geographic addressing. There | > will *always* be | > >> a lot of people against it | > | > > Since you have more historical context than many of us | > on the list, | > > could you please summarize the arguments which have | > been used against | > > geo? I suspect that they are mainly financial and | > political, but there | > > might be technical issues I'm unaware of. | > | > Actually, I don't think that's quite correct: the argument | > against it is in fact rooted in technical issues, although | > there are non-technical issues in the later stages. | > | > The analysis of geographic has been fairly well summarized in | > recent discussion here on the list, but very simply, it goes: | > | > - i) for the overhead of the routing to scale, the hierarchy | > of addressing abstractions has to be reasonably closely | > related to the actual interconnection topology; | > - ii) this means that either connectivity has to follow | > addressing, or addressing has to follow connectivity; | > - iii) the IETF cannot mandate where connectivity gets added; | > - iv) connectivity gets put in where there are actual traffic | > flows and/or commercial reasons to put it in. | > | > Therefore we have to have the addressing follow the | > connectivity, and an addressing scheme such as geographic, | > which to scale needs to have the connectivity follow the | > addressing, is not feasible. | > | > Noel | > | > | > PS: Everyone, about the "this is stupid" comment - that | > wasn't directed at anyone in particular, but at all of us, me | > included. I suddenly had my brain start to function, and | > realized that there is never going to be *rough consensus in | > favour of geographic* - which is what we'd need to go forward | > with it - and therefore further discussion thereof is not | > useful. I hope I didn't offend anyone - if I did, my apologies. | > | > | | From owner-multi6@ops.ietf.org Thu Apr 3 15:18:36 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11488 for ; Thu, 3 Apr 2003 15:18:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 191BBI-000KhT-00 for multi6-data@psg.com; Thu, 03 Apr 2003 12:19:28 -0800 Received: from dmz2.procket.com ([65.174.124.37]) by psg.com with esmtp (Exim 3.36 #1) id 191BBD-000Kh8-00 for multi6@ops.ietf.org; Thu, 03 Apr 2003 12:19:23 -0800 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id E96F43445C; Thu, 3 Apr 2003 11:32:49 -0800 (PST) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h33KJMYB028121; Thu, 3 Apr 2003 12:19:23 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: geo short vs long term? [Re: Geo pros and cons] Date: Thu, 3 Apr 2003 12:19:22 -0800 Message-ID: Thread-Topic: geo short vs long term? [Re: Geo pros and cons] Thread-Index: AcL59yrdRPDG6nVTTGKC7Vlp5Ufw7gAJu5yw From: "Tony Li" To: "Iljitsch van Beijnum" , "J. Noel Chiappa" Cc: X-Spam-Status: No, hits=-6.6 required=5.0 tests=BAYES_01 version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA11488 | But does a addressing scheme that follows connectivity AND allows | multihoming to a usable degree exist? | | If yes, now would be a good time to unveil it. Yes. If the addressing follows connectivity and sites are multiply connected, then they need to have multiple addresses. Tony From owner-multi6@ops.ietf.org Thu Apr 3 15:56:15 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13367 for ; Thu, 3 Apr 2003 15:56:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 191BlU-000MQL-00 for multi6-data@psg.com; Thu, 03 Apr 2003 12:56:52 -0800 Received: from goose.automagic.org ([199.212.90.4]) by psg.com with esmtp (Exim 3.36 #1) id 191BlS-000MQ1-00 for multi6@ops.ietf.org; Thu, 03 Apr 2003 12:56:50 -0800 Received: from isc.org (dhcp-k-1.automagic.org [199.212.90.17]) by goose.automagic.org (Postfix) with ESMTP id D94CC35602; Thu, 3 Apr 2003 15:56:36 -0500 (EST) Date: Thu, 3 Apr 2003 15:56:36 -0500 Subject: Re: A Way Forward Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: RJ Atkinson , Sean Doran , multi6@ops.ietf.org To: Kurt Erik Lindqvist From: Joe Abley In-Reply-To: <7D9BAF4C-5E3C-11D7-B5E2-000393AB1404@kurtis.pp.se> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Monday, Mar 24, 2003, at 16:06 Canada/Eastern, Kurt Erik Lindqvist wrote: >> I'd also like to see some requirements document get sorted out and >> published, so that we understand what issues we are trying to address. > > After discussing with Joe Abley in SF, he will resubmit the document > with changed normative references and title, and let's see if we then > can get consensus for that. > >> One possible way to sort it out would be for the document editor to >> hold >> an organised on-list document review section by section, with several >> days >> to discuss the current contents of each section. Other approaches >> might also work to sort through such a document. > > Joe? I've been travelling; sorry about the period of dead air. I'm back in Canada now, and do not appear to be dying from any infectious water-bourne virus, so all is good. I will submit the edited document shortly. Joe From owner-multi6@ops.ietf.org Thu Apr 3 16:46:27 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15782 for ; Thu, 3 Apr 2003 16:46:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 191CWm-000PGY-00 for multi6-data@psg.com; Thu, 03 Apr 2003 13:45:44 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 191CWj-000PGK-00 for multi6@ops.ietf.org; Thu, 03 Apr 2003 13:45:41 -0800 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h33LiZ629484; Thu, 3 Apr 2003 23:44:35 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Thu, 3 Apr 2003 23:44:21 +0200 Subject: Re: geo short vs long term? [Re: Geo pros and cons] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "J. Noel Chiappa" , To: "Tony Li" From: Iljitsch van Beijnum In-Reply-To: Message-Id: <6E149CAE-661D-11D7-A6D6-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On donderdag, apr 3, 2003, at 22:09 Europe/Amsterdam, Tony Li wrote: > - The Internet is continually growing at an exponential rate. > Most people seem to peg the growth rate at 100% per year > currently. The exact number is not an issue. Agree. > - In the past, we've estimated that 10% of all sites would > multi-home. Let's assume a constant rate of 10% of the > world is an exception to the default aggregation rules > that we pick. > - From the above two, we can reason that our exception rate > is going to continue to grow exponentially. Note that > the rate of absolute growth is more of an issue than the > exception rate. > - Moore's law for memory suggests that memory sizes will > double about every two years. However, memory speeds will > not keep up. So far so good. > - Packet lookups are a function of memory bandwidth, so to > sustain Internet bandwidth growth of 100% per year, we need > to also increase memory bandwidth by about 100% per year. > Using bigger, slower memories is not a realistic option. Am I missing something here, because I always thought looking up routes scales O(log(n)). If memory size isn't a problem, you could even use a 2^45 element array and make route lookups scale O(1). > - Thus, the routing table really needs to be constrained to > grow at about Moore's law for memory. Not for packet forwarding. The problem is processing the routing updates. Since the number of updates scales linearly with the number of routes, but you need to look up a route in order to process it and then possibly do some data structure manipulation as a result, this scales O(n*log(n)) which is not good. > - If the exceptions are growing at about 100% per year, and > the memories are growing at about 100% every TWO years, then > regardless of the starting point, the exceptions will overtake > technology. Unless we can make sure that the lines terminate before this happens. If we assume 10% of the population will multihome, there is an automatic limit around 1G multihomers around 2050. However, one person may want to multihome several times by then... > - Therefore, we must find some mechanism that prevents the > exceptions from growing at 100% per year. In short, the > number of longer prefixes that are injected into routing > cannot be a constant fraction of the number of sites that > join. Or we introduce another variable to bend the curve downwards. By no longer keeping a copy of the full global routing table in every individual router, but distributing it over a large number of routers, we can make sure we don't run out of memory (or CPU power) in the near future. > - Since everyone and their brother will want an exception > for anything that they want to do that is outside of the > norm, the norm MUST support almost every possible situation. > Multihoming, in particular, must not cause exceptions. > Even a constant percentage of multihomers must not cause > exceptions. Agree. But if we can make multihomers connect to their ISPs and make ISPs interconnect within regions multihoming no longer causes exceptions. We don't even need all multihomers and all ISPs to conform to this, just enough to keep us on the good side of Moore's law. > - For reasons that I've already explained, the economics > of links in a geo system cause many sites to be exceptions. It's very nice to have a cheap long distance links and multihome to distant ISPs, but what does that buy you if you can't be routable? Economics is about making rational decisions, not about forcing huge costs in one area to obtain slight savings in others. Besides, if links from Jersey City to Palo Alto are so much cheaper than across the Hudson, why not multihome to two ISPs in California and be geo aggregatable rather than connect to Palo Alto and NYC and break aggregation in the process. > - Therefore, geo addressing leads to a system that will not > scale for the long term. > QED The real reason geo won't scale in the long run is that at some point the number of multihomers in a city becomes too large, and I don't believe it is possible to do reasonable geographical aggregation within a single city. But let's not compare apples and oranges. I agree that geo aggregation won't solve the long term problem. However, I does offer short term relief and intermediate term disaster relief. If we can make every IPv6 enabled host use multiple addresses for every application within two years, that would be much better, but I don't see this happening fast enough that we can do without a short term solution. Iljitsch From owner-multi6@ops.ietf.org Thu Apr 3 18:34:22 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20131 for ; Thu, 3 Apr 2003 18:34:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 191ED3-0004Ro-00 for multi6-data@psg.com; Thu, 03 Apr 2003 15:33:29 -0800 Received: from mail3.microsoft.com ([131.107.3.123]) by psg.com with esmtp (Exim 3.36 #1) id 191ECq-0004RN-00 for multi6@ops.ietf.org; Thu, 03 Apr 2003 15:33:17 -0800 Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Thu, 3 Apr 2003 15:33:16 -0800 Received: from 157.54.8.155 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 03 Apr 2003 15:33:16 -0800 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Thu, 3 Apr 2003 15:33:15 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 3 Apr 2003 15:33:15 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3788.0); Thu, 3 Apr 2003 15:33:14 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6851.8 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: geo short vs long term? [Re: Geo pros and cons] Date: Thu, 3 Apr 2003 15:33:15 -0800 Message-ID: Thread-Topic: geo short vs long term? [Re: Geo pros and cons] Thread-Index: AcL533dUe+653MfhQqGr2OPyPGH4lAAOwsBAAAcD4aA= From: "Christian Huitema" To: "Tony Li" , "J. Noel Chiappa" , X-OriginalArrivalTime: 03 Apr 2003 23:33:14.0600 (UTC) FILETIME=[65B16680:01C2FA39] X-Spam-Status: No, hits=-9.8 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA20131 Tony, There are a few issues with your maths. First, the 100% per year figure relates to the traffic growth, not the growth in the number of hosts. The number of hosts does grow, but not nearly as fast. The host count measured by the Internet domain survey grew 20% last year, but that does not account for hosts behind NAT. If you assume that the traffic growth is caused equally by larger pipes and by more devices, then you get a growth in the number of hosts of about 40% per year. Second, the number of sites does not grow at the same pace as the number of hosts. For example, the number of PC per household or per office is increasing. The hypothetical 40% host grow could be split between a growth in the number of connected sites (new homes, new offices) and a growth in the number of hosts per site. This would result in a 20% yearly growth for the number of sites. Most of the sites being added are small sites, which are the least likely to be multihomed -- the big sites are already connected, probably already multihomed. So, there is a strong case that the 10% figure is probably an overstatement. But let's keep it. The cost of maintaining the routing tables is somewhere between O(N.log N) and O(N^2). Given the current size of 100,000 entries, a 20% increase would correspond to an increase of 22% to 44%. Moore's law corresponds to an increase of about 60% yearly. 60% beats 22%, or even 44%. There is no reason to panic. There is also no particular reason to love geographic addresses, but that is another issue. -- Christian Huitema > -----Original Message----- > From: Tony Li [mailto:Tony.Li@procket.com] > Sent: Thursday, April 03, 2003 12:10 PM > To: J. Noel Chiappa; multi6@ops.ietf.org > > > > Noel, well said. > > More points: there are worse things than no decision. That > would be the clearly wrong decision. We could, for example, > choose to aggregate locators based on the lexographical > ordering of the user's first name. We could choose not to > aggregate and end up with another swamp. > > As to the issues with 'proving' that geo won't work, let me > point out the very simple reasoning: > > - The Internet is continually growing at an exponential rate. > Most people seem to peg the growth rate at 100% per year > currently. The exact number is not an issue. > > - In the past, we've estimated that 10% of all sites would > multi-home. Let's assume a constant rate of 10% of the > world is an exception to the default aggregation rules > that we pick. > > - From the above two, we can reason that our exception rate > is going to continue to grow exponentially. Note that > the rate of absolute growth is more of an issue than the > exception rate. > > - Moore's law for memory suggests that memory sizes will > double about every two years. However, memory speeds will > not keep up. > > - Packet lookups are a function of memory bandwidth, so to > sustain Internet bandwidth growth of 100% per year, we need > to also increase memory bandwidth by about 100% per year. > Using bigger, slower memories is not a realistic option. > > - Thus, the routing table really needs to be constrained to > grow at about Moore's law for memory. > > - If the exceptions are growing at about 100% per year, and > the memories are growing at about 100% every TWO years, then > regardless of the starting point, the exceptions will overtake > technology. > > - Therefore, we must find some mechanism that prevents the > exceptions from growing at 100% per year. In short, the > number of longer prefixes that are injected into routing > cannot be a constant fraction of the number of sites that > join. > > - Since everyone and their brother will want an exception > for anything that they want to do that is outside of the > norm, the norm MUST support almost every possible situation. > Multihoming, in particular, must not cause exceptions. > Even a constant percentage of multihomers must not cause > exceptions. > > - For reasons that I've already explained, the economics > of links in a geo system cause many sites to be exceptions. > > - Therefore, geo addressing leads to a system that will not > scale for the long term. > > QED > > Tony > > > | -----Original Message----- > | From: J. Noel Chiappa [mailto:jnc@ginger.lcs.mit.edu] > | Sent: Thursday, April 03, 2003 4:38 AM > | To: multi6@ops.ietf.org > | Cc: jnc@ginger.lcs.mit.edu > | Subject: Re: geo short vs long term? [Re: Geo pros and cons] > | > | > | Look, everyone, this is all really stupid. > | > | Geographic addressing has been discussed extensively about > | 17 times in the > | IETF, and every time it has been rejected. Discussing it > | one more time is not > | going to change this. There is *never* going to be a rough > | consensus *in > | favour of* geographic addressing. There will *always* be a > | lot of people > | against it - enough to stop it in the proposal stage. > | > | The really sad thing is that something productive might > | have been done with > | all this time and energy that's being wasted. > | > | Noel > | > | > From owner-multi6@ops.ietf.org Thu Apr 3 22:23:06 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23961 for ; Thu, 3 Apr 2003 22:23:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 191HlP-000Fp9-00 for multi6-data@psg.com; Thu, 03 Apr 2003 19:21:11 -0800 Received: from zmamail05.zma.compaq.com ([161.114.64.105]) by psg.com with esmtp (Exim 3.36 #1) id 191HlM-000Fox-00 for multi6@ops.ietf.org; Thu, 03 Apr 2003 19:21:08 -0800 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id C8248632E; Thu, 3 Apr 2003 22:21:07 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 3 Apr 2003 22:21:07 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: geo short vs long term? [Re: Geo pros and cons] Date: Thu, 3 Apr 2003 22:21:07 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03ABD056@tayexc13.americas.cpqcorp.net> Thread-Topic: geo short vs long term? [Re: Geo pros and cons] Thread-Index: AcL55wrg1Wza43FeT/iKVAL2/BodBAAApGhQAAz32mAADuYQgA== From: "Bound, Jim" To: "Tony Li" , "J. Noel Chiappa" , X-OriginalArrivalTime: 04 Apr 2003 03:21:07.0707 (UTC) FILETIME=[3B7FF4B0:01C2FA59] X-Spam-Status: No, hits=-6.6 required=5.0 tests=BAYES_01 version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id WAA23961 Thanks Tony no response other than your mail was key input to my processes to think about this. I agree about Antartica too :--) Thank You, /jim >-----Original Message----- >From: Tony Li [mailto:Tony.Li@procket.com] >Sent: Thursday, April 03, 2003 3:18 PM >To: Bound, Jim; J. Noel Chiappa; multi6@ops.ietf.org >Subject: RE: geo short vs long term? [Re: Geo pros and cons] > > > > > >Jim, > >Yes, geo addressing at the continental level makes much more >sense because the connectivity within a continent is pretty much a >given. Not so at the metro or lower layers, so it doesn't >recurse down nicely. > >Note that a hybrid system that was geo at the top and provider >based below was proposed some 10 years ago, but some folks >shouted it down because they didn't feel that the aggregation >at the continental level would have a great effect. Of >course, we had very few ISPs at that exact point in time and >they were correct. For the moment. > >I would have zero issues with continental aggregation tied >to lower layers that were topological. [Well, ok, I don't >think that Antartica should get as much as China, but that's a >nit. ;-) ] > >Tony > > >| -----Original Message----- >| From: Bound, Jim [mailto:Jim.Bound@hp.com] >| Sent: Thursday, April 03, 2003 6:05 AM >| To: J. Noel Chiappa; multi6@ops.ietf.org >| Subject: RE: geo short vs long term? [Re: Geo pros and cons] >| >| >| This is logical and makes sense. >| >| But practically, if say the U.S., Mexico, and Canada all >| had a toplevel >| GEO prefix would the connectivity issue still be real or just >| theoretical? >| >| Within this GEO if all had 2ffe then another set of bits >| for Mexico, >| U.S. and Canada how would that exacerbate routing problems >| in Austrailia >| or France? >| >| Thanks >| /jim >| >| >| >| >| > -----Original Message----- >| > From: J. Noel Chiappa [mailto:jnc@ginger.lcs.mit.edu] >| > Sent: Thursday, April 03, 2003 8:35 AM >| > To: multi6@ops.ietf.org >| > Cc: jnc@ginger.lcs.mit.edu >| > Subject: Re: geo short vs long term? [Re: Geo pros and cons] >| > >| > >| > > From: "Michael H. Lambert" >| > >| > >> Geographic addressing has been discussed extensively >| > about 17 times in >| > >> the IETF, and every time it has been rejected. >| > Discussing it one more >| > >> time is not going to change this. There is *never* >| > going to be a rough >| > >> consensus *in favour of* geographic addressing. There >| > will *always* be >| > >> a lot of people against it >| > >| > > Since you have more historical context than many of us >| > on the list, >| > > could you please summarize the arguments which have >| > been used against >| > > geo? I suspect that they are mainly financial and >| > political, but there >| > > might be technical issues I'm unaware of. >| > >| > Actually, I don't think that's quite correct: the argument >| > against it is in fact rooted in technical issues, although >| > there are non-technical issues in the later stages. >| > >| > The analysis of geographic has been fairly well summarized in >| > recent discussion here on the list, but very simply, it goes: >| > >| > - i) for the overhead of the routing to scale, the hierarchy >| > of addressing abstractions has to be reasonably closely >| > related to the actual interconnection topology; >| > - ii) this means that either connectivity has to follow >| > addressing, or addressing has to follow connectivity; >| > - iii) the IETF cannot mandate where connectivity gets added; >| > - iv) connectivity gets put in where there are actual traffic >| > flows and/or commercial reasons to put it in. >| > >| > Therefore we have to have the addressing follow the >| > connectivity, and an addressing scheme such as geographic, >| > which to scale needs to have the connectivity follow the >| > addressing, is not feasible. >| > >| > Noel >| > >| > >| > PS: Everyone, about the "this is stupid" comment - that >| > wasn't directed at anyone in particular, but at all of us, me >| > included. I suddenly had my brain start to function, and >| > realized that there is never going to be *rough consensus in >| > favour of geographic* - which is what we'd need to go forward >| > with it - and therefore further discussion thereof is not >| > useful. I hope I didn't offend anyone - if I did, my apologies. >| > >| > >| >| > From owner-multi6@ops.ietf.org Fri Apr 4 02:57:32 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10544 for ; Fri, 4 Apr 2003 02:57:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 191M1i-0001Cd-00 for multi6-data@psg.com; Thu, 03 Apr 2003 23:54:18 -0800 Received: from dmz1.procket.com ([65.174.124.36]) by psg.com with esmtp (Exim 3.36 #1) id 191M1e-0001CQ-00 for multi6@ops.ietf.org; Thu, 03 Apr 2003 23:54:14 -0800 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id 8460D23C47; Thu, 3 Apr 2003 23:43:55 -0800 (PST) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h347s7YB026771; Thu, 3 Apr 2003 23:54:08 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: geo short vs long term? [Re: Geo pros and cons] Date: Thu, 3 Apr 2003 23:54:07 -0800 Message-ID: Thread-Topic: geo short vs long term? [Re: Geo pros and cons] Thread-Index: AcL533dUe+653MfhQqGr2OPyPGH4lAAOwsBAAAcD4aAAEiNhcA== From: "Tony Li" To: "Christian Huitema" , "J. Noel Chiappa" , X-Spam-Status: No, hits=-6.6 required=5.0 tests=BAYES_01 version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA10544 I would, without objection, like to wholly withdraw the entire mail message that I sent and refer everyone to Noel's mail. Please excuse my temporary insanity/stupidity. I know better. Tony | -----Original Message----- | From: Christian Huitema [mailto:huitema@windows.microsoft.com] | Sent: Thursday, April 03, 2003 3:33 PM | To: Tony Li; J. Noel Chiappa; multi6@ops.ietf.org | Subject: RE: geo short vs long term? [Re: Geo pros and cons] | | | Tony, | | There are a few issues with your maths. | | First, the 100% per year figure relates to the traffic | growth, not the | growth in the number of hosts. The number of hosts does | grow, but not | nearly as fast. The host count measured by the Internet | domain survey | grew 20% last year, but that does not account for hosts | behind NAT. If | you assume that the traffic growth is caused equally by | larger pipes and | by more devices, then you get a growth in the number of | hosts of about | 40% per year. | | Second, the number of sites does not grow at the same pace | as the number | of hosts. For example, the number of PC per household or | per office is | increasing. The hypothetical 40% host grow could be split between a | growth in the number of connected sites (new homes, new | offices) and a | growth in the number of hosts per site. This would result in a 20% | yearly growth for the number of sites. | | Most of the sites being added are small sites, which are the least | likely to be multihomed -- the big sites are already | connected, probably | already multihomed. So, there is a strong case that the | 10% figure is | probably an overstatement. But let's keep it. | | The cost of maintaining the routing tables is somewhere | between O(N.log | N) and O(N^2). Given the current size of 100,000 entries, | a 20% increase | would correspond to an increase of 22% to 44%. | | Moore's law corresponds to an increase of about 60% | yearly. 60% beats | 22%, or even 44%. There is no reason to panic. | | There is also no particular reason to love geographic | addresses, but | that is another issue. | | -- Christian Huitema | | > -----Original Message----- | > From: Tony Li [mailto:Tony.Li@procket.com] | > Sent: Thursday, April 03, 2003 12:10 PM | > To: J. Noel Chiappa; multi6@ops.ietf.org | > | > | > | > Noel, well said. | > | > More points: there are worse things than no decision. That | > would be the clearly wrong decision. We could, for example, | > choose to aggregate locators based on the lexographical | > ordering of the user's first name. We could choose not to | > aggregate and end up with another swamp. | > | > As to the issues with 'proving' that geo won't work, let me | > point out the very simple reasoning: | > | > - The Internet is continually growing at an exponential rate. | > Most people seem to peg the growth rate at 100% per year | > currently. The exact number is not an issue. | > | > - In the past, we've estimated that 10% of all sites would | > multi-home. Let's assume a constant rate of 10% of the | > world is an exception to the default aggregation rules | > that we pick. | > | > - From the above two, we can reason that our exception rate | > is going to continue to grow exponentially. Note that | > the rate of absolute growth is more of an issue than the | > exception rate. | > | > - Moore's law for memory suggests that memory sizes will | > double about every two years. However, memory speeds will | > not keep up. | > | > - Packet lookups are a function of memory bandwidth, so to | > sustain Internet bandwidth growth of 100% per year, we need | > to also increase memory bandwidth by about 100% per year. | > Using bigger, slower memories is not a realistic option. | > | > - Thus, the routing table really needs to be constrained to | > grow at about Moore's law for memory. | > | > - If the exceptions are growing at about 100% per year, and | > the memories are growing at about 100% every TWO years, then | > regardless of the starting point, the exceptions will overtake | > technology. | > | > - Therefore, we must find some mechanism that prevents the | > exceptions from growing at 100% per year. In short, the | > number of longer prefixes that are injected into routing | > cannot be a constant fraction of the number of sites that | > join. | > | > - Since everyone and their brother will want an exception | > for anything that they want to do that is outside of the | > norm, the norm MUST support almost every possible situation. | > Multihoming, in particular, must not cause exceptions. | > Even a constant percentage of multihomers must not cause | > exceptions. | > | > - For reasons that I've already explained, the economics | > of links in a geo system cause many sites to be exceptions. | > | > - Therefore, geo addressing leads to a system that will not | > scale for the long term. | > | > QED | > | > Tony | > | > | > | -----Original Message----- | > | From: J. Noel Chiappa [mailto:jnc@ginger.lcs.mit.edu] | > | Sent: Thursday, April 03, 2003 4:38 AM | > | To: multi6@ops.ietf.org | > | Cc: jnc@ginger.lcs.mit.edu | > | Subject: Re: geo short vs long term? [Re: Geo pros and cons] | > | | > | | > | Look, everyone, this is all really stupid. | > | | > | Geographic addressing has been discussed extensively about | > | 17 times in the | > | IETF, and every time it has been rejected. Discussing it | > | one more time is not | > | going to change this. There is *never* going to be a rough | > | consensus *in | > | favour of* geographic addressing. There will *always* be a | > | lot of people | > | against it - enough to stop it in the proposal stage. | > | | > | The really sad thing is that something productive might | > | have been done with | > | all this time and energy that's being wasted. | > | | > | Noel | > | | > | | > | | | From owner-multi6@ops.ietf.org Sat Apr 5 21:07:31 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19975 for ; Sat, 5 Apr 2003 21:07:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 191zVU-000ELr-00 for multi6-data@psg.com; Sun, 06 Apr 2003 02:03:40 +0000 Received: from buffoon.automagic.org ([208.185.30.208]) by psg.com with smtp (Exim 3.36 #1) id 191zV8-000EJL-00 for multi6@ops.ietf.org; Sat, 05 Apr 2003 18:03:18 -0800 Received: (qmail 33631 invoked by uid 0); 6 Apr 2003 02:03:17 -0000 Received: from localhost.automagic.org (HELO isc.org) (root@127.0.0.1) by localhost.automagic.org with SMTP; 6 Apr 2003 02:03:17 -0000 Date: Sat, 5 Apr 2003 21:03:21 -0500 Subject: Re: geo short vs long term? [Re: Geo pros and cons] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "Bound, Jim" , "J. Noel Chiappa" , To: "Tony Li" From: Joe Abley In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Thursday, Apr 3, 2003, at 15:17 Canada/Eastern, Tony Li wrote: > Yes, geo addressing at the continental level makes much more sense > because the connectivity within a continent is pretty much a > given. Connectivity within a continent may be a given for all continents at some point in the future. Today it's only really a given for North America, Australasia and Europe. Joe From owner-multi6@ops.ietf.org Sat Apr 5 22:01:38 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20621 for ; Sat, 5 Apr 2003 22:01:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 1920PA-0000EM-00 for multi6-data@psg.com; Sun, 06 Apr 2003 03:01:12 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 1920On-0000Dz-00; Sat, 05 Apr 2003 19:00:50 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.12) id 1920Om-000HXJ-00; Sat, 05 Apr 2003 19:00:48 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sat, 5 Apr 2003 19:00:46 -0800 To: Joe Abley Cc: multi6@ops.ietf.org Subject: Re: geo short vs long term? [Re: Geo pros and cons] References: Message-Id: X-Spam-Status: No, hits=-16.3 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT,REFERENCES autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Connectivity within a continent may be a given for all continents > at some point in the future. Today it's only really a given for > North America, Australasia and Europe. if you don't count the oceanic island nations, se asia, ... all of which backhaul a long way. net topology is extremely different from geography. this repeating idea of geographic aggregation simply ignores reality. randy From owner-multi6@ops.ietf.org Sat Apr 5 22:19:33 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20811 for ; Sat, 5 Apr 2003 22:19:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 1920fk-0003dS-00 for multi6-data@psg.com; Sun, 06 Apr 2003 03:18:20 +0000 Received: from buffoon.automagic.org ([208.185.30.208]) by psg.com with smtp (Exim 3.36 #1) id 1920fO-0003d2-00 for multi6@ops.ietf.org; Sat, 05 Apr 2003 19:17:58 -0800 Received: (qmail 38437 invoked by uid 0); 6 Apr 2003 03:17:57 -0000 Received: from localhost.automagic.org (HELO isc.org) (root@127.0.0.1) by localhost.automagic.org with SMTP; 6 Apr 2003 03:17:57 -0000 Date: Sat, 5 Apr 2003 22:18:01 -0500 Subject: Re: geo short vs long term? [Re: Geo pros and cons] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: Randy Bush From: Joe Abley In-Reply-To: Message-Id: <5F9AD972-67DE-11D7-BFDC-00039312C852@isc.org> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Saturday, Apr 5, 2003, at 22:00 Canada/Eastern, Randy Bush wrote: >> Connectivity within a continent may be a given for all continents >> at some point in the future. Today it's only really a given for >> North America, Australasia and Europe. > > if you don't count the oceanic island nations, se asia, ... all of > which backhaul a long way. net topology is extremely different > from geography. this repeating idea of geographic aggregation > simply ignores reality. Yes. That was my point. From owner-multi6@ops.ietf.org Sun Apr 6 05:31:33 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24973 for ; Sun, 6 Apr 2003 05:31:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 1926Ta-000PE5-00 for multi6-data@psg.com; Sun, 06 Apr 2003 09:30:10 +0000 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 1926TD-000PD6-00; Sun, 06 Apr 2003 01:29:47 -0800 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h369RN636869; Sun, 6 Apr 2003 11:27:24 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Sun, 6 Apr 2003 11:27:10 +0200 Subject: Re: geo short vs long term? [Re: Geo pros and cons] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Joe Abley , multi6@ops.ietf.org To: Randy Bush From: Iljitsch van Beijnum In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On zondag, apr 6, 2003, at 05:00 Europe/Amsterdam, Randy Bush wrote: >> Connectivity within a continent may be a given for all continents >> at some point in the future. Today it's only really a given for >> North America, Australasia and Europe. > if you don't count the oceanic island nations, se asia, ... all of > which backhaul a long way. net topology is extremely different > from geography. this repeating idea of geographic aggregation > simply ignores reality. Trying to get something right that was done wrong in the past isn't "repeating". The idea behind geographic addressing is not that the topology and addressing become interchangable. The simple fact that a multihomer connects to the net in two places makes this impossible by definition. The point is that it becomes possible to draw lines on the map in such a way that aggregating routing information that crosses these lines gets rid of enough routing information that the savings in routing table size are worth the effort. For this purpose, it is irrelevant that the aggregation circle with Singapore in the middle may also include Palo Alto and LA. That still gets rid of Asia/Pacific more specifics in most of the US and the rest of the world. And even if some Asian networks connect to other places, this only breaks aggregation for these specific networks. Maybe the savings aren't that big. But then again, the effort isn't all that huge either: the RIRs need to implement a tool that allows local internet registries (ISPs) to give out geography-based /48s to multihomers. That's all. (Aside: I'm not that familiar with the Asia/Pacific region, but I believe the interconnection within many countries isn't all that bad, it's the interconnection between countries in the region that's still in the early stages. So aggregating at the continent level wouldn't work well there, but aggregating on the country level could.) From owner-multi6@ops.ietf.org Sun Apr 6 09:49:46 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27534 for ; Sun, 6 Apr 2003 09:49:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 192AW9-00091Y-00 for multi6-data@psg.com; Sun, 06 Apr 2003 13:49:05 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 192AVo-0008wW-00; Sun, 06 Apr 2003 06:48:44 -0700 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.12) id 192AVm-0000Eg-00; Sun, 06 Apr 2003 06:48:42 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sun, 6 Apr 2003 09:48:41 -0400 To: Iljitsch van Beijnum Cc: Joe Abley , multi6@ops.ietf.org Subject: Re: geo short vs long term? [Re: Geo pros and cons] References: Message-Id: X-Spam-Status: No, hits=-16.3 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT,REFERENCES autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >>> Connectivity within a continent may be a given for all continents >>> at some point in the future. Today it's only really a given for >>> North America, Australasia and Europe. >> if you don't count the oceanic island nations, se asia, ... all of >> which backhaul a long way. net topology is extremely different >> from geography. this repeating idea of geographic aggregation >> simply ignores reality. > Trying to get something right that was done wrong in the past isn't > "repeating". not taking lessons from history and physical reality is naive at best, and dangerous at worst. randy From owner-multi6@ops.ietf.org Sun Apr 6 13:43:32 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01613 for ; Sun, 6 Apr 2003 13:43:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 192EAk-000Grq-00 for multi6-data@psg.com; Sun, 06 Apr 2003 17:43:14 +0000 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 192EAO-000Gla-00; Sun, 06 Apr 2003 10:42:52 -0700 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h36HeR637308; Sun, 6 Apr 2003 19:40:29 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Sun, 6 Apr 2003 19:40:14 +0200 Subject: Re: geo short vs long term? [Re: Geo pros and cons] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Joe Abley , multi6@ops.ietf.org To: Randy Bush From: Iljitsch van Beijnum In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On zondag, apr 6, 2003, at 15:48 Europe/Amsterdam, Randy Bush wrote: >> Trying to get something right that was done wrong in the past isn't >> "repeating". > not taking lessons from history and physical reality is naive at best, > and dangerous at worst. Is it really that hard to let go of preconceived notions? The only "lessons from history" I can find are discussions that went nowhere because neither party bothered to get into enough detail to see if something useful could be done or not. Physical reality is that every meter of fiber costs money. There are only two cost-effective ways to connect networks: over the shortest possible distances, or by aggregating as much traffic and as many logical connections over a single circuit as possible. Both allow good geographical aggregation. From owner-multi6@ops.ietf.org Sun Apr 6 14:27:58 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02316 for ; Sun, 6 Apr 2003 14:27:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 192EsA-000NFv-00 for multi6-data@psg.com; Sun, 06 Apr 2003 18:28:06 +0000 Received: from mail1.microsoft.com ([131.107.3.125]) by psg.com with esmtp (Exim 3.36 #1) id 192Ern-000NEQ-00 for multi6@ops.ietf.org; Sun, 06 Apr 2003 11:27:43 -0700 Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.6659); Sun, 6 Apr 2003 11:27:29 -0700 Received: from 157.54.5.25 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sun, 06 Apr 2003 11:27:42 -0700 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3788.0); Sun, 6 Apr 2003 11:27:43 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Sun, 6 Apr 2003 11:27:33 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3788.0); Sun, 6 Apr 2003 11:27:41 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6851.8 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: geo short vs long term? [Re: Geo pros and cons] Date: Sun, 6 Apr 2003 11:27:43 -0700 Message-ID: Thread-Topic: geo short vs long term? [Re: Geo pros and cons] Thread-Index: AcL8ZRrCB8WS7YL8Q0yaSFkxlni8ZwAA3G85 From: "Christian Huitema" To: "Iljitsch van Beijnum" , "Randy Bush" Cc: "Joe Abley" , X-OriginalArrivalTime: 06 Apr 2003 18:27:41.0568 (UTC) FILETIME=[3597F800:01C2FC6A] X-Spam-Status: No, hits=-16.3 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA02316 The lessons are pretty clear. I remember a time, not so long ago, when the shortest path from France to the UK actually was through Princeton, and the shortest path from some parts of France to other parts was through either Amsterdam or Geneva. The reality is that network topology is primarily driven by network economics, which themselves are only modestly driven by geography. In theory, it seems easier to lay fiber over short distances, but this is one of those cases where the difference between theory and practice is even greater in practice than in theory. In practice, you get into things like right of ways that prevent crossing streets, traffic pattern that are not local, satellites that don't particularly care about imediate proximity, or the simple fact that laying fiber accross a body of water is simpler that doing the same accross a mountain ridge. Then, you get competition between providers, and all sorts of non technical reasons such as trust, business affinity, etc. By the way, these non technical reasons apply also to various "virtual addressing" schemes that propose to use a provider independent overlay on top of a provider addressed network. Any kind of virtual aggregation is much more likely to be centered on business relations than on geography. ________________________________ From: Iljitsch van Beijnum [mailto:iljitsch@muada.com] Sent: Sun 4/6/2003 10:40 AM To: Randy Bush Cc: Joe Abley; multi6@ops.ietf.org Subject: Re: geo short vs long term? [Re: Geo pros and cons] On zondag, apr 6, 2003, at 15:48 Europe/Amsterdam, Randy Bush wrote: >> Trying to get something right that was done wrong in the past isn't >> "repeating". > not taking lessons from history and physical reality is naive at best, > and dangerous at worst. Is it really that hard to let go of preconceived notions? The only "lessons from history" I can find are discussions that went nowhere because neither party bothered to get into enough detail to see if something useful could be done or not. Physical reality is that every meter of fiber costs money. There are only two cost-effective ways to connect networks: over the shortest possible distances, or by aggregating as much traffic and as many logical connections over a single circuit as possible. Both allow good geographical aggregation. From owner-multi6@ops.ietf.org Sun Apr 6 18:00:39 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07154 for ; Sun, 6 Apr 2003 18:00:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 192I8Z-000757-00 for multi6-data@psg.com; Sun, 06 Apr 2003 21:57:15 +0000 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 192I8D-00074d-00 for multi6@ops.ietf.org; Sun, 06 Apr 2003 14:56:53 -0700 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h36Ltm637615 for ; Sun, 6 Apr 2003 23:55:48 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Sun, 6 Apr 2003 23:55:36 +0200 Mime-Version: 1.0 (Apple Message framework v551) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: RE: geo short vs long term? [Re: Geo pros and cons] From: Iljitsch van Beijnum To: multi6@ops.ietf.org Content-Transfer-Encoding: 7bit Message-Id: <7F9C8B20-687A-11D7-83FB-00039388672E@muada.com> X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-19.4 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT, USER_AGENT_APPLEMAIL autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On zondag, apr 6, 2003, at 20:27 Europe/Amsterdam, Christian Huitema wrote: > The lessons are pretty clear. I remember a time, not so long ago, when > the shortest path from France to the UK actually was through > Princeton, and the shortest path from some parts of France to other > parts was through either Amsterdam or Geneva. The reality is that > network topology is primarily driven by network economics, which > themselves are only modestly driven by geography. Yes, I remember those times too. :-) When I started out we were multihomed to a Dutch network and a British network and a lot of NL traffic over the British network went from London to Washington and back. Other European destinations were especially bad. A 500 km detour (from Paris over Amsterdam or the other way around) is something we shouldn't consider out of the ordinary. In the US for example, only a tiny fraction of all traffic should be expected to stay within the same city or state. In Europe this is different for reasons such as language, and most countries have at least one interconnect location of national importance. > In theory, it seems easier to lay fiber over short distances, but this > is one of those cases where the difference between theory and practice > is even greater in practice than in theory. In practice, you get into > things like right of ways that prevent crossing streets, I'm not even close to worrying about streets... > traffic pattern that are not local, satellites that don't particularly > care about imediate proximity, Yes, satellites are a problem. > or the simple fact that laying fiber accross a body of water is > simpler that doing the same accross a mountain ridge. Then, you get > competition between providers, and all sorts of non technical reasons > such as trust, business affinity, etc. All of this can explain why European or Asian traffic flows through the US (to name an exampel), but that doesn't make connectivity completely arbitrary: even if European traffic flows through the US, it's always the east coast, and west coast for Asian traffic. (At least, as far as I have observed.) It seems some of you guys are trying to convince me that geo aggregation can't work. I'm trying to convince you that it can and will. Rather than going over the same arguments again and again without convincing anyone, it might be a good idea to say what it takes to be convinced. For me, that would either be a fatal flaw in my draft that makes it impossible to get the necessary filtering off the ground in current BGP implementations, or something that shows that if geo aggregation is implemented in today's internet and new multihomers connect in a rational way, the savings in routing table size are negligible. What would it take for you to agree that geographic aggregation can be a useful short to intermediate term tool? > By the way, these non technical reasons apply also to various "virtual > addressing" schemes that propose to use a provider independent overlay > on top of a provider addressed network. Any kind of virtual > aggregation is much more likely to be centered on business relations > than on geography. If you base aggregation on business stuff, you must renumber when business changes. I don't think that is going to work well. The sad truth is that despite the renumbering tools we have and are building in IPv6, renumbering is only getting harder, not easier. We know we can't trust the DNS and no global PKI yet, so most access restrictions work on IP addresses. That's bad when you have a few hundred globally unique addresses, but in IPv6 you can have many, many more hosts in a /48. The more hosts with globally visible addresses and the more subnets, the harder renumbering becomes. From owner-multi6@ops.ietf.org Mon Apr 7 07:14:46 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15309 for ; Mon, 7 Apr 2003 07:14:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 192UYR-000CKO-00 for multi6-data@psg.com; Mon, 07 Apr 2003 11:12:47 +0000 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 192UYO-000CJy-00 for multi6@ops.ietf.org; Mon, 07 Apr 2003 04:12:44 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15004; Mon, 7 Apr 2003 07:10:10 -0400 (EDT) Message-Id: <200304071110.HAA15004@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: multi6@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-multi6-multihoming-requirements-04.txt Date: Mon, 07 Apr 2003 07:10:10 -0400 X-Spam-Status: No, hits=-3.5 required=5.0 tests=BAYES_01,MIME_BOUND_NEXTPART,NO_REAL_NAME,TO_MALFORMED version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Site Multihoming in IPv6 Working Group of the IETF. Title : Goals for IPv6 Site-Multihoming Architectures Author(s) : B. Black, V. Gill, J. Abley Filename : draft-ietf-multi6-multihoming-requirements-04.txt Pages : 9 Date : 2003-4-4 Site-multihoming, i.e. connecting to more than one IP service provider, is an essential component of service for many sites which are part of the Internet. Existing IPv4 site-multihoming practices provide a set of capabilities that it would ideally be accommodated by the adopted site-multihoming architecture in IPv6, and a set of limitations that must be overcome, relating in particular to scalability. This document outlines a set of goals for proposed new IPv6 site-multihoming architectures. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-multi6-multihoming-requirements-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-multi6-multihoming-requirements-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-multi6-multihoming-requirements-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-4-4160357.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-multi6-multihoming-requirements-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-multi6-multihoming-requirements-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-4-4160357.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-multi6@ops.ietf.org Mon Apr 7 16:52:51 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05675 for ; Mon, 7 Apr 2003 16:52:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 192db7-0009UD-00 for multi6-data@psg.com; Mon, 07 Apr 2003 20:52:09 +0000 Received: from dhcp1.se.kurtis.pp.se ([195.43.225.70]) by psg.com with esmtp (Exim 3.36 #1) id 192db2-0009Tf-00; Mon, 07 Apr 2003 13:52:05 -0700 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp1.se.kurtis.pp.se (8.12.7/8.10.2) with ESMTP id h37KrZWv004860; Mon, 7 Apr 2003 22:53:35 +0200 (CEST) Date: Mon, 7 Apr 2003 22:53:34 +0200 Subject: Re: geo short vs long term? [Re: Geo pros and cons] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "Iljitsch van Beijnum" , "Randy Bush" , "Joe Abley" , To: "Christian Huitema" From: Kurt Erik Lindqvist In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-16.1 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,USER_AGENT_APPLEMAIL autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > In theory, it seems easier to lay fiber over short distances, but this > is one of those cases where the difference between theory and practice > is even greater in practice than in theory. In practice, you get into > things like right of ways that prevent crossing streets, traffic > pattern that are not local, satellites that don't particularly care > about imediate proximity, or the simple fact that laying fiber accross > a body of water is simpler that doing the same accross a mountain > ridge. Then, you get competition between providers, and all sorts of > non technical reasons such as trust, business affinity, etc. > From my experience in building pan-continental networks, traffic tend to be very optimized within the network. Where it leaves is as you say a completely different question. - kurtis - From owner-multi6@ops.ietf.org Mon Apr 7 16:53:59 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05717 for ; Mon, 7 Apr 2003 16:53:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 192ddW-0009e9-00 for multi6-data@psg.com; Mon, 07 Apr 2003 20:54:38 +0000 Received: from dhcp1.se.kurtis.pp.se ([195.43.225.70]) by psg.com with esmtp (Exim 3.36 #1) id 192ddU-0009dg-00 for multi6@ops.ietf.org; Mon, 07 Apr 2003 13:54:36 -0700 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp1.se.kurtis.pp.se (8.12.7/8.10.2) with ESMTP id h37KuDWv004864; Mon, 7 Apr 2003 22:56:13 +0200 (CEST) Date: Mon, 7 Apr 2003 22:56:12 +0200 Subject: Re: geo short vs long term? [Re: Geo pros and cons] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: multi6@ops.ietf.org To: Iljitsch van Beijnum From: Kurt Erik Lindqvist In-Reply-To: <7F9C8B20-687A-11D7-83FB-00039388672E@muada.com> Message-Id: <5DCBF124-693B-11D7-B2DA-000393AB1404@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-16.1 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,USER_AGENT_APPLEMAIL autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > A 500 km detour (from Paris over Amsterdam or the other way around) is > something we shouldn't consider out of the ordinary. In the US for > example, only a tiny fraction of all traffic should be expected to > stay within the same city or state. In Europe this is different for > reasons such as language, and most countries have at least one > interconnect location of national importance. > But not all of them, or probably very little of total traffic is exchanged over them. In % of total traffic I think most of European traffic goes through fibers owned by Telehouse in London. Although not the fibers of Linx or LoNAP but through the private interconnects. - kurtis - From owner-multi6@ops.ietf.org Mon Apr 7 18:15:12 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08810 for ; Mon, 7 Apr 2003 18:15:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 192esx-000HG5-00 for multi6-data@psg.com; Mon, 07 Apr 2003 22:14:39 +0000 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 192esb-000HFF-00 for multi6@ops.ietf.org; Mon, 07 Apr 2003 15:14:17 -0700 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h37MDB639829; Tue, 8 Apr 2003 00:13:11 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Tue, 8 Apr 2003 00:13:00 +0200 Subject: Re: geo short vs long term? [Re: Geo pros and cons] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: multi6@ops.ietf.org To: Kurt Erik Lindqvist From: Iljitsch van Beijnum In-Reply-To: <5DCBF124-693B-11D7-B2DA-000393AB1404@kurtis.pp.se> Message-Id: <182BED4C-6946-11D7-A11A-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On maandag, apr 7, 2003, at 22:56 Europe/Amsterdam, Kurt Erik Lindqvist wrote: >> A 500 km detour (from Paris over Amsterdam or the other way around) >> is something we shouldn't consider out of the ordinary. In the US for >> example, only a tiny fraction of all traffic should be expected to >> stay within the same city or state. In Europe this is different for >> reasons such as language, and most countries have at least one >> interconnect location of national importance. > But not all of them, or probably very little of total traffic is > exchanged over them. In % of total traffic I think most of European > traffic goes through fibers owned by Telehouse in London. Although not > the fibers of Linx or LoNAP but through the private interconnects. From where I'm sitting most traffic seems to go through Amsterdam... In your experience, is it common for traffic from a source in a certain country to a destination in the same country to flow through another country in general and through London in particular? And how common as a percentage of all destinations/all traffic? From owner-multi6@ops.ietf.org Mon Apr 7 22:10:48 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14226 for ; Mon, 7 Apr 2003 22:10:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 192iYp-000JaK-00 for multi6-data@psg.com; Tue, 08 Apr 2003 02:10:07 +0000 Received: from garlic.apnic.net ([202.12.29.224]) by psg.com with esmtp (Exim 3.36 #1) id 192iYk-000JYc-00 for multi6@ops.ietf.org; Mon, 07 Apr 2003 19:10:02 -0700 Received: from garlic.apnic.net (localhost [127.0.0.1]) by garlic.apnic.net (8.12.8p1/8.12.8) with ESMTP id h3829bv2005661; Tue, 8 Apr 2003 12:09:39 +1000 (EST) Received: (from ggm@localhost) by garlic.apnic.net (8.12.8p1/8.12.8) id h3829bt2005600; Tue, 8 Apr 2003 12:09:37 +1000 (EST) Date: Tue, 8 Apr 2003 12:09:37 +1000 From: George Michaelson To: "Christian Huitema" Cc: Subject: Re: geo short vs long term? [Re: Geo pros and cons] Message-Id: <20030408120937.1ae7bdc5.ggm@apnic.net> In-Reply-To: References: Organization: APNIC Pty Ltd X-Mailer: Sylpheed version 0.8.10claws101 (GTK+ 1.2.10; i386--netbsdelf) X-Fruit-Of-The-Month-Club: persimmon Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-25.8 required=5.0 tests=BAYES_10,IN_REP_TO,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1, REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Sun, 6 Apr 2003 11:27:43 -0700 "Christian Huitema" wrote: > > By the way, these non technical reasons apply also to various "virtual > addressing" schemes that propose to use a provider independent overlay on top > of a provider addressed network. Any kind of virtual aggregation is much more > likely to be centered on business relations than on geography. Christian, as a confessed partisan supporter of some aspects of geographic addressing I think I can argue that virtual aggregation by layered/overlay networks is *neutral* for both business relations-based networking and geographic address assignment models. Can you be more explicit why overlay models favour one schema for address deployment more than another? The AP region has sub-registries under the regional registry which do, in practice hand out resource along economic/national boundaries. I do not think we should be arguing that *no* national/geo takes place, it clearly does. Maybe we should be asking more direct questions about the impact and effects. Layer-9 stuff reaching down into layer-3 and 2? There might be valid issues/concerns in the effects it has on connectivity and vice-versa, and equally valid observations to be made about the net effects on routing table complexity. I am probably over-optimistic about the benefits. But can I suggest that some of the opponents are equally over pessimistic? cheers -George -- George Michaelson | APNIC Email: ggm@apnic.net | PO Box 2131 Milton QLD 4064 Phone: +61 7 3367 0490 | Australia Fax: +61 7 3367 0482 | http://www.apnic.net From owner-multi6@ops.ietf.org Tue Apr 8 01:19:10 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17378 for ; Tue, 8 Apr 2003 01:19:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 192lSH-000GBo-00 for multi6-data@psg.com; Tue, 08 Apr 2003 05:15:33 +0000 Received: from dhcp1.se.kurtis.pp.se ([195.43.225.70]) by psg.com with esmtp (Exim 3.36 #1) id 192lSE-000GBa-00 for multi6@ops.ietf.org; Mon, 07 Apr 2003 22:15:30 -0700 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp1.se.kurtis.pp.se (8.12.7/8.10.2) with ESMTP id h385H7Wv004981; Tue, 8 Apr 2003 07:17:08 +0200 (CEST) Date: Tue, 8 Apr 2003 07:17:06 +0200 Subject: Re: geo short vs long term? [Re: Geo pros and cons] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: multi6@ops.ietf.org To: Iljitsch van Beijnum From: Kurt Erik Lindqvist In-Reply-To: <182BED4C-6946-11D7-A11A-00039388672E@muada.com> Message-Id: <576E0656-6981-11D7-B2DA-000393AB1404@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-16.1 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,USER_AGENT_APPLEMAIL autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >>> A 500 km detour (from Paris over Amsterdam or the other way around) >>> is something we shouldn't consider out of the ordinary. In the US >>> for example, only a tiny fraction of all traffic should be expected >>> to stay within the same city or state. In Europe this is different >>> for reasons such as language, and most countries have at least one >>> interconnect location of national importance. > >> But not all of them, or probably very little of total traffic is >> exchanged over them. In % of total traffic I think most of European >> traffic goes through fibers owned by Telehouse in London. Although >> not the fibers of Linx or LoNAP but through the private >> interconnects. > > From where I'm sitting most traffic seems to go through Amsterdam... > > In your experience, is it common for traffic from a source in a > certain country to a destination in the same country to flow through > another country in general and through London in particular? And how > common as a percentage of all destinations/all traffic? Well, it's either London or Amsterdam..:-) It I look at the old KQ network and what I know of the larger providers we peered with (so this information is around a year old) I would say that well over 50% of European traffic went through private peers. Of those peers I would say that between 60-75% went through London or Amsterdam. So yes, we did see a lot of traffic taking detours when heading for a peering. KQ might still not be a typical provider as we had such a large percentage of the transit market in Europe. This meant that we had very few problems with this. We had more problems with non-customers and other US based carriers traffic taking detours in their network to get to/from us. - kurtis - From owner-multi6@ops.ietf.org Tue Apr 8 03:20:45 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01192 for ; Tue, 8 Apr 2003 03:20:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 192nO5-000L9H-00 for multi6-data@psg.com; Tue, 08 Apr 2003 07:19:21 +0000 Received: from laptop2.kurtis.autonomica.se ([192.71.80.74] helo=dhcp1.se.kurtis.pp.se) by psg.com with esmtp (Exim 3.36 #1) id 192nO2-000L90-00 for multi6@ops.ietf.org; Tue, 08 Apr 2003 00:19:18 -0700 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp1.se.kurtis.pp.se (8.12.7/8.10.2) with ESMTP id h387KsWv005133 for ; Tue, 8 Apr 2003 09:20:55 +0200 (CEST) Date: Tue, 8 Apr 2003 09:20:53 +0200 Subject: Re: I-D ACTION:draft-ietf-multi6-multihoming-requirements-04.txt Content-Type: text/plain; delsp=yes; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v551) From: Kurt Erik Lindqvist To: multi6@ops.ietf.org In-Reply-To: <200304071110.HAA15004@ietf.org> Message-Id: X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-27.9 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_RFCI,REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA01192 All, Me and Sean will give people the time to (re-)read this document, and in two weeks issue WG last call on this. I hope this should not be to controversial...:-) - kurtis - On måndag, apr 7, 2003, at 13:10 Europe/Stockholm, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Site Multihoming in IPv6 Working > Group of the IETF. > > Title : Goals for IPv6 Site-Multihoming Architectures > Author(s) : B. Black, V. Gill, J. Abley > Filename : draft-ietf-multi6-multihoming-requirements-04.txt > Pages : 9 > Date : 2003-4-4 > > Site-multihoming, i.e. connecting to more than one IP service > provider, is an essential component of service for many sites which > are part of the Internet. Existing IPv4 site-multihoming practices > provide a set of capabilities that it would ideally be accommodated > by the adopted site-multihoming architecture in IPv6, and a set of > limitations that must be overcome, relating in particular to > scalability. > This document outlines a set of goals for proposed new IPv6 > site-multihoming architectures. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-multi6-multihoming- > requirements-04.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the > message. > > Internet-Drafts are also available by anonymous FTP. Login with the > username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-multi6-multihoming-requirements-04.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE > /internet-drafts/draft-ietf-multi6-multihoming-requirements-04.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > Content-Type: text/plain > Content-ID: <2003-4-4160357.I-D@ietf.org> From owner-multi6@ops.ietf.org Tue Apr 8 10:58:14 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16588 for ; Tue, 8 Apr 2003 10:58:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 192uX7-000I3O-00 for multi6-data@psg.com; Tue, 08 Apr 2003 14:57:09 +0000 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=SERVER2000.arneill-py.sacramento.ca.us) by psg.com with esmtp (Exim 3.36 #1) id 192uX3-000I30-00 for multi6@ops.ietf.org; Tue, 08 Apr 2003 07:57:05 -0700 Content-class: urn:content-classes:message Subject: RE: I-D ACTION:draft-ietf-multi6-multihoming-requirements-04.txt Date: Tue, 8 Apr 2003 07:56:56 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: <963621801C6D3E4A9CF454A1972AE8F50456D6@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Thread-Topic: I-D ACTION:draft-ietf-multi6-multihoming-requirements-04.txt Thread-Index: AcL9oNXWtm2BmhsVQZi0EnfABkgNeQAPi/iA From: "Michel Py" To: "Kurt Erik Lindqvist" , X-Spam-Status: No, hits=-16.3 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA16588 Are there any changes other than the removal of normative language? Michel. Me and Sean will give people the time to (re-)read this document, and in two weeks issue WG last call on this. I hope this should not be to controversial...:-) - kurtis - On måndag, apr 7, 2003, at 13:10 Europe/Stockholm, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Site Multihoming in IPv6 Working > Group of the IETF. > > Title : Goals for IPv6 Site-Multihoming Architectures > Author(s) : B. Black, V. Gill, J. Abley > Filename : draft-ietf-multi6-multihoming-requirements-04.txt > Pages : 9 > Date : 2003-4-4 > > Site-multihoming, i.e. connecting to more than one IP service > provider, is an essential component of service for many sites which > are part of the Internet. Existing IPv4 site-multihoming practices > provide a set of capabilities that it would ideally be accommodated > by the adopted site-multihoming architecture in IPv6, and a set of > limitations that must be overcome, relating in particular to > scalability. > This document outlines a set of goals for proposed new IPv6 > site-multihoming architectures. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-multi6-multihoming- > requirements-04.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the > message. > > Internet-Drafts are also available by anonymous FTP. Login with the > username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-multi6-multihoming-requirements-04.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE > /internet-drafts/draft-ietf-multi6-multihoming-requirements-04.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > Content-Type: text/plain > Content-ID: <2003-4-4160357.I-D@ietf.org> From owner-multi6@ops.ietf.org Tue Apr 8 13:50:08 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23817 for ; Tue, 8 Apr 2003 13:50:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 192xD7-0000BD-00 for multi6-data@psg.com; Tue, 08 Apr 2003 17:48:41 +0000 Received: from buffoon.automagic.org ([208.185.30.208]) by psg.com with smtp (Exim 3.36 #1) id 192xD0-0000Az-00 for multi6@ops.ietf.org; Tue, 08 Apr 2003 10:48:35 -0700 Received: (qmail 86438 invoked by uid 0); 8 Apr 2003 17:48:33 -0000 Received: from localhost.automagic.org (HELO isc.org) (root@127.0.0.1) by localhost.automagic.org with SMTP; 8 Apr 2003 17:48:33 -0000 Date: Tue, 8 Apr 2003 13:48:42 -0400 Subject: Re: I-D ACTION:draft-ietf-multi6-multihoming-requirements-04.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "Kurt Erik Lindqvist" , To: "Michel Py" From: Joe Abley In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F50456D6@server2000.arneill-py.sacramento.ca.us> Message-Id: <56491BD6-69EA-11D7-BFDC-00039312C852@isc.org> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-33.0 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,HTML_20_30,IN_REP_TO, PATCH_UNIFIED_DIFF,QUOTED_EMAIL_TEXT,REPLY_WITH_QUOTES, USER_AGENT_APPLEMAIL autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Tuesday, Apr 8, 2003, at 10:56 Canada/Eastern, Michel Py wrote: > Are there any changes other than the removal of normative language? Here's a unified diff of the rfc2629 xml source for the document (which should give an idea of the content changes without the noise of formatting changes): Index: draft-ietf-multi6-multihoming-requirements.xml =================================================================== RCS file: /home/cvs/doc/ietf/draft-ietf-multi6-multihoming-requirements.xml,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- draft-ietf-multi6-multihoming-requirements.xml 18 Jul 2002 15:30:57 -0000 1.2 +++ draft-ietf-multi6-multihoming-requirements.xml 4 Apr 2003 00:55:37 -0000 1.3 @@ -1,11 +1,31 @@ - + + + + + + - - Requirements for IPv6 Site-Multihoming Architectures + <title abbrev="IPv6 Site-Multihoming Goals"> + Goals for IPv6 Site-Multihoming Architectures + + Internet Software Consortium +
+ + 10805 Old River Road + Canada + N0L 1R0 + ON + Komoka + + +1 519 641 4368 + jabley@isc.org +
+ + Layer8 Networks
@@ -20,39 +40,23 @@
- - MFN -
- - 10805 Old River Road - Canada - N0L 1R0 - ON - Komoka - - +1 519 641 4368 - jabley@mfnx.net -
- - - + Operations and Management - Site Multihoming in IPv6 (multi6) + multi6 Site-multihoming, i.e. connecting to more than one IP service provider, is an essential component of service for many sites which are part of the Internet. Existing IPv4 site-multihoming - practices, described in a companion draft - , - provides a set of capabilities that must be accommodated + practices provide a set of capabilities that it would ideally + be accommodated by the adopted site-multihoming architecture in IPv6, and a set of limitations that must be overcome, relating in particular to scalability. - This document outlines a set of requirements for a new IPv6 - site-multihoming architecture. + This document outlines a set of goals for proposed new IPv6 + site-multihoming architectures. @@ -62,8 +66,7 @@ Current IPv4 site-multihoming practices have been added on to the CIDR architecture , which assumes that routing table entries can be aggregated based - upon a hierarchy of customers and service providers - . + upon a hierarchy of customers and service providers. However, it appears that this hierarchy is being supplanted by a dense mesh @@ -85,11 +88,6 @@
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in RFC 2119 - . - A "site" is an entity autonomously operating a network using IP and, in particular, determining the addressing plan and routing policy for that network. This definition @@ -112,15 +110,14 @@ connectivity between the site and its transit providers' sites.
-
+
The following capabilities of current IPv4 multihoming - practices MUST be supported by an IPv6 multihoming - architecture. IPv4 multihoming is discussed in more detail - in . + practices should be supported by an IPv6 multihoming + architecture.
- By multihoming, a site MUST be able to + By multihoming, a site should be able to insulate itself from certain failure modes within one or more transit providers, as well as failures in the network providing interconnection among one or more transit providers. @@ -135,7 +132,7 @@ single incident in the street. The two circuits are said to "share fate". - The multihoming architecture MUST accommodate (in the general + The multihoming architecture should accommodate (in the general case, issues of shared fate notwithstanding) continuity of connectivity during the following failures: @@ -152,7 +149,7 @@
- By multihoming, a site MUST be able to + By multihoming, a site should be able to distribute both inbound and outbound traffic between multiple transit providers. This requirement is for concurrent use of the multiple transit providers, not just the usage @@ -161,19 +158,19 @@
- By multihoming, a site MUST be able to protect + By multihoming, a site should be able to protect itself from performance difficulties directly between the site's transit providers. For example, suppose site E obtains transit from transit providers T1 and T2, and there is long-term congestion between - T1 and T2. The multihoming architecture MUST allow E to + T1 and T2. The multihoming architecture should allow E to ensure that in normal operation none of its traffic is carried over the congested interconnection T1-T2. The process - by which this is achieved MAY be a manual one. + by which this is achieved should be a manual one. - A multihomed site MUST be able to distribute + A multihomed site should be able to distribute inbound traffic from particular multiple transit providers according to the particular address range within their site which is sourcing or sinking the traffic. @@ -184,7 +181,7 @@ beyond technical scope (e.g. cost, acceptable use conditions, etc.) For example, customer C homed to ISP A may wish to shift traffic of a certain class or application, NNTP, for example, to ISP B as matter - of policy. A new IPv6 multihoming proposal MUST provide support + of policy. A new IPv6 multihoming proposal should provide support for site-multihoming for external policy reasons.
@@ -193,13 +190,13 @@ networks with real customers, simplicity is paramount. The current multihoming solution is quite straightforward to deploy and maintain. A new IPv6 multihoming - proposal MUST NOT be substantially more complex to deploy and + proposal should not be substantially more complex to deploy and operate than current IPv4 multihoming practices.
- Multihoming solutions MUST provide re-homing transparency + Multihoming solutions should provide re-homing transparency for transport-layer sessions; i.e. exchange of data between devices on the multihomed site and devices elsewhere @@ -207,25 +204,25 @@ that associated with the transient packet loss during the re-homing event. - New transport-layer sessions MUST be able to be created + New transport-layer sessions should be able to be created following a re-homing event. Transport-layer sessions include those involving transport-layer protocols such as TCP, UDP and SCTP over IP. Applications which communicate over raw - IP and other network-layer protocols MAY also enjoy + IP and other network-layer protocols may also enjoy re-homing transparency.
- Multi-homing solutions either MUST be compatible with the + Multi-homing solutions either should be compatible with the observed dynamics of the current DNS system, or the solutions - MUST have demonstrate that the modified name resolution + should demonstrate that the modified name resolution system required to support them are readily deployable.
- Multihoming solutions MUST NOT preclude filtering packets + Multihoming solutions should not preclude filtering packets with forged or otherwise inappropriate source IP addresses at the administrative boundary of the multihomed site.
@@ -241,24 +238,24 @@ of the routing system. This issue is discussed in great detail in . - A new IPv6 multihoming architecture MUST scale + A new IPv6 multihoming architecture should scale to accommodate orders of magnitude more multihomed sites without imposing unreasonable requirements on the routing system.
- The solution MAY require changes to IPv6 router implementations, + The solution may require changes to IPv6 router implementations, but these changes must be either minor, or in the form of logically separate functions added to existing functions. - Such changes MUST NOT prevent normal single-homed operation, and + Such changes should not prevent normal single-homed operation, and routers implementing these changes must be able to interoperate fully with hosts and routers not implementing them.
- The solution MUST NOT destroy IPv6 connectivity for a legacy host + The solution should not destroy IPv6 connectivity for a legacy host implementing RFC 2373 , RFC 2460 , RFC 2553 and other basic IPv6 @@ -273,41 +270,41 @@ connections were still operational. If the solution requires changes to the host stack, these changes - MUST be either minor, or in the form of logically separate functions + should be either minor, or in the form of logically separate functions added to existing functions. If the solution requires changes to the socket API and/or the - transport layer, it MUST be possible to retain the original + transport layer, it should be possible to retain the original socket API and transport protocols in parallel, even if they cannot benefit from multihoming. - The multihoming solution MAY allow host or application + The multihoming solution may allow host or application changes if that would enhance session survivability.
- The solution MAY involve interaction between a site's hosts - and its routing system; such an interaction MUST be simple, + The solution may involve interaction between a site's hosts + and its routing system; such an interaction should be simple, scaleable and securable.
- It MUST be posssible for staff responsible for the operation + It should be posssible for staff responsible for the operation of a site to monitor and configure the site's multihoming system.
- A multihoming strategy MAY require cooperation between a site - and its transit providers, but MUST NOT require cooperation + A multihoming strategy may require cooperation between a site + and its transit providers, but should not require cooperation (relating specifically to the multihomed site) directly between the transit providers.
- There MAY be more than one approach to multihoming, provided + There may be more than one approach to multihoming, provided all approaches are orthogonal (e.g. each approach addresses a distinct segment or category within the site multihoming problem. Multiple solutions will incur a greater management @@ -320,31 +317,13 @@
- A multihomed site MUST NOT be more vulnerable to + A multihomed site should not be more vulnerable to security breaches than a traditionally IPv4-multihomed site.
- - - - IPv4 Multihoming Motivation, Practices and - Limitations (work-in-progress) - - Metromedia Fiber Network Inc. - - - Layer8 Networks - - - Metromedia Fiber Network Inc. - - - - - - + Classless Inter-Domain Routing (CIDR): an Address @@ -387,18 +366,6 @@ <date month="February" year="1996" /> </front> <seriesInfo name="RFC" value="1918" /> - </reference> - - <reference anchor="refs.RFC2119"> - <front> - <title>Key words for use in RFCs to Indicate - Requirement Levels - - Harvard University - - - - From owner-multi6@ops.ietf.org Tue Apr 8 17:18:08 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02822 for ; Tue, 8 Apr 2003 17:18:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 1930Rz-000DeK-00 for multi6-data@psg.com; Tue, 08 Apr 2003 21:16:15 +0000 Received: from [2002:c08b:2e21:3:250:baff:fe2d:b704] (helo=noxmail.sandelman.ottawa.on.ca) by psg.com with esmtp (Exim 3.36 #1) id 1930Rv-000De5-00 for multi6@ops.ietf.org; Tue, 08 Apr 2003 14:16:11 -0700 Received: from sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca [192.139.46.20]) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h38JRrM16946 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Tue, 8 Apr 2003 15:27:54 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (marajade [127.0.0.1] (may be forged)) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h38JRrok026868 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Tue, 8 Apr 2003 15:27:54 -0400 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by marajade.sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-5) with ESMTP id h38JRkXu026864 for ; Tue, 8 Apr 2003 15:27:53 -0400 Message-Id: <200304081927.h38JRkXu026864@marajade.sandelman.ottawa.on.ca> To: multi6@ops.ietf.org Subject: Re: geo short vs long term? [Re: Geo pros and cons] In-reply-to: Your message of "Tue, 08 Apr 2003 12:09:37 +1000." <20030408120937.1ae7bdc5.ggm@apnic.net> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Tue, 08 Apr 2003 15:27:45 -0400 From: Michael Richardson X-Spam-Status: No, hits=-9.8 required=5.0 tests=BAYES_01,IN_REP_TO autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk >>>>> "George" == George Michaelson writes: George> should be asking more direct questions about the impact and George> effects. Layer-9 George> stuff reaching down into layer-3 and 2? A question: assuming no installed base, and a layer-9 that can be mutable in any fashion we want, (I.e. we live on a planet with a uniform, homogeneous landmass, with a uniform distribution of multihomers), is there a multihoming solution within the constraints of our requirements that we can agree upon? This is a serious question. Now, if there is such a solution, can we adequately describe the boundaries of its applicability? ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ From owner-multi6@ops.ietf.org Thu Apr 10 01:43:45 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26986 for ; Thu, 10 Apr 2003 01:43:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 193UpF-000Pgl-00 for multi6-data@psg.com; Thu, 10 Apr 2003 05:42:17 +0000 Received: from jazz-1.trumpet.com.au ([203.5.119.62]) by psg.com with esmtp (Exim 3.36 #1) id 193Uoi-000PcR-00 for multi6@ops.ietf.org; Wed, 09 Apr 2003 22:41:44 -0700 Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id PAA21872 for ; Thu, 10 Apr 2003 15:41:42 +1000 (EST) Date: Thu, 10 Apr 2003 15:41:42 +1000 (EST) From: Peter Tattam To: Multi6 Working Group Subject: old GSE idea Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-12.3 required=5.0 tests=BAYES_01,USER_AGENT_PINE autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk I was doing a tidy up of my document folders and ran across this which is also online. Doesn't look like many people have referenced it - most of the hits look like web crawlers. http://jazz-1.trumpet.com.au/ipv6-draft/GSE-plus-routing-idea-july-21-1999.htm I wonder if some of it may be relevant to recent discussions. (you might want to ignore the junk about ARPing for routing id's - that probably won't fly) The relevant bit is the break up of the address bits. Apologies if it resembles other drafts. Peter -- Peter R. Tattam peter@trumpet.com Managing Director, Trumpet Software International Pty Ltd Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 From owner-multi6@ops.ietf.org Fri Apr 11 12:35:00 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20194 for ; Fri, 11 Apr 2003 12:35:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 1941SX-00002c-00 for multi6-data@psg.com; Fri, 11 Apr 2003 16:33:01 +0000 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 1941SU-000Q0R-00 for multi6@ops.ietf.org; Fri, 11 Apr 2003 09:32:58 -0700 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h3BGVl648656 for ; Fri, 11 Apr 2003 18:31:48 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Fri, 11 Apr 2003 18:28:06 +0200 Mime-Version: 1.0 (Apple Message framework v551) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: Resolving geo discussions From: Iljitsch van Beijnum To: multi6@ops.ietf.org Content-Transfer-Encoding: 7bit Message-Id: <93235598-6C3A-11D7-A4A7-00039388672E@muada.com> X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-9.7 required=5.0 tests=BAYES_01,USER_AGENT_APPLEMAIL autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Last week we had another round of "this can't work" / "yes it can" discussions about geographic aggregation. While doing this from time to time is a lot of fun, I'm sure we can all find more productive things to do with our time. So how do we resolve this in a way that is satisfactory to everyone? The way I see it, many of the "con" arguments may turn out to be quite valid. However, there are also many ways in which geo aggregation could be successful. Maybe it will solve the multihoming scaling problem for 10, 5 or just 2 years. Or it just helps regional networks to optimize their routing. I don't think there is any way to determine this beforehand. But it should be possible to adequately predict the costs and risks in advance. The costs for the internet community as a whole mostly consist of the RIRs having to implement tools to make it possible to assign geographically aggregatable PI addresses to multihomers. The only risk that I can see is that the GAPI addresses will in essence turn out to be nothing more than regular PI addresses. This means an explosion of the global routing table, and subsequently at some point networks will start to filter out GAPI more specifics. Is there a way we can arrive on some consensus as to whether the (potential) downsides are worth the potential gain? We could experiment with this for a set amount of time in 6bone space, for instance. From owner-multi6@ops.ietf.org Fri Apr 11 13:05:03 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21393 for ; Fri, 11 Apr 2003 13:05:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 1941x5-0002n1-00 for multi6-data@psg.com; Fri, 11 Apr 2003 17:04:35 +0000 Received: from mail2.microsoft.com ([131.107.3.124]) by psg.com with esmtp (Exim 3.36 #1) id 1941x3-0002mn-00 for multi6@ops.ietf.org; Fri, 11 Apr 2003 10:04:33 -0700 Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Fri, 11 Apr 2003 10:04:32 -0700 Received: from 157.54.6.150 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 11 Apr 2003 10:04:32 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3789.0); Fri, 11 Apr 2003 10:04:32 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Fri, 11 Apr 2003 10:04:31 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3788.0); Fri, 11 Apr 2003 10:04:31 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6851.8 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Resolving geo discussions Date: Fri, 11 Apr 2003 10:04:30 -0700 Message-ID: Thread-Topic: Resolving geo discussions Thread-Index: AcMASvJkSqoCwj+2QKmo/1qj5J9elwAAO2hA From: "Christian Huitema" To: "Iljitsch van Beijnum" , X-OriginalArrivalTime: 11 Apr 2003 17:04:31.0525 (UTC) FILETIME=[6B5C9550:01C3004C] X-Spam-Status: No, hits=-9.8 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA21393 > The way I see it, many of the "con" arguments may turn out to be quite > valid. However, there are also many ways in which geo aggregation could > be successful. Maybe it will solve the multihoming scaling problem for > 10, 5 or just 2 years. Or it just helps regional networks to optimize > their routing. I don't think there is any way to determine this > beforehand. We have had this discussion many times in the past 10 years. After many rounds of e-mail, the consensus generally is that if geo is going to happen, it will happen "bottom up" and be user driven. For example, one may see the chamber of commerce of lower Picardy request a /32 from RIPE, and use it to provides "independent" /48 addresses to its members, using a combination of tunnels and arrangements with local ISP. In fact, there are already a few virtual ISP operating under this model. -- Christian Huitema From owner-multi6@ops.ietf.org Fri Apr 11 13:35:22 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22377 for ; Fri, 11 Apr 2003 13:35:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 1942R9-0005To-00 for multi6-data@psg.com; Fri, 11 Apr 2003 17:35:39 +0000 Received: from ginger.lcs.mit.edu ([18.26.0.82]) by psg.com with esmtp (Exim 3.36 #1) id 1942R6-0005Ta-00 for multi6@ops.ietf.org; Fri, 11 Apr 2003 10:35:36 -0700 Received: from ginger.lcs.mit.edu (localhost [127.0.0.1]) by ginger.lcs.mit.edu (8.12.9/8.12.9) with ESMTP id h3BHZYtU024231; Fri, 11 Apr 2003 13:35:34 -0400 Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.12.9/8.12.9/Submit) id h3BHZY0x024230; Fri, 11 Apr 2003 13:35:34 -0400 Date: Fri, 11 Apr 2003 13:35:34 -0400 From: "J. Noel Chiappa" Message-Id: <200304111735.h3BHZY0x024230@ginger.lcs.mit.edu> To: multi6@ops.ietf.org Subject: RE: Resolving geo discussions Cc: jnc@ginger.lcs.mit.edu X-Spam-Status: No, hits=-6.6 required=5.0 tests=BAYES_01 version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: Iljitsch van Beijnum > another round of "this can't work" / "yes it can" discussions about > geographic aggregation. While doing this from time to time is a lot of > fun, I'm sure we can all find more productive things to do with our > time. Exactly. > So how do we resolve this in a way that is satisfactory to everyone? We probably can't. The two sides are pretty firmly entrenched, and without changing that, some group is likely to be unhappy. > Is there a way we can arrive on some consensus as to whether the > (potential) downsides are worth the potential gain? No, because there will almost certainly be a large contingent who do not agree with that position (that "the (potential) downsides are worth the potential gain"). So I don't think any consensus around that position is feasible. As Christian points out, there is nothing to stop people from experimenting with it locally, though. Noel From owner-multi6@ops.ietf.org Fri Apr 11 14:52:46 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24473 for ; Fri, 11 Apr 2003 14:52:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 1943dO-000CXc-00 for multi6-data@psg.com; Fri, 11 Apr 2003 18:52:22 +0000 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 1943dL-000CXN-00 for multi6@ops.ietf.org; Fri, 11 Apr 2003 11:52:19 -0700 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h3BIpC648864; Fri, 11 Apr 2003 20:51:12 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Fri, 11 Apr 2003 20:51:01 +0200 Subject: Re: Resolving geo discussions Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: To: "Christian Huitema" From: Iljitsch van Beijnum In-Reply-To: Message-Id: <8A59662F-6C4E-11D7-AC2C-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On vrijdag, apr 11, 2003, at 19:04 Europe/Amsterdam, Christian Huitema wrote: >> I don't think there is any way to determine this beforehand. > We have had this discussion many times in the past 10 years. After many > rounds of e-mail, the consensus generally is that if geo is going to > happen, it will happen "bottom up" and be user driven. This is news to me. I would really appreciate some pointers to archives of these past discussions. > For example, one > may see the chamber of commerce of lower Picardy request a /32 from > RIPE, and use it to provides "independent" /48 addresses to its > members, > using a combination of tunnels and arrangements with local ISP. In > fact, > there are already a few virtual ISP operating under this model. So if I want to do this in a slightly larger area, say everything within a 20000 km radius of The Hague, I could get a larger address block, say a /16? From owner-multi6@ops.ietf.org Fri Apr 11 15:22:21 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26307 for ; Fri, 11 Apr 2003 15:22:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 194482-000FkU-00 for multi6-data@psg.com; Fri, 11 Apr 2003 19:24:02 +0000 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 19447y-000Fjq-00 for multi6@ops.ietf.org; Fri, 11 Apr 2003 12:23:58 -0700 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h3BJMo648898; Fri, 11 Apr 2003 21:22:50 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Fri, 11 Apr 2003 21:22:39 +0200 Subject: Re: Resolving geo discussions Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: multi6@ops.ietf.org To: "J. Noel Chiappa" From: Iljitsch van Beijnum In-Reply-To: <200304111735.h3BHZY0x024230@ginger.lcs.mit.edu> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On vrijdag, apr 11, 2003, at 19:35 Europe/Amsterdam, J. Noel Chiappa wrote: >> So how do we resolve this in a way that is satisfactory to everyone? > We probably can't. The two sides are pretty firmly entrenched, and > without > changing that, some group is likely to be unhappy. Still, I think it would be useful to try sufficiently hard that the remaining disagreements can only be attributed to differing world views, and not to lack of understanding or effort. Then at least we all know we don't have to do it again for a good long time. >> Is there a way we can arrive on some consensus as to whether the >> (potential) downsides are worth the potential gain? > No, because there will almost certainly be a large contingent who do > not > agree with that position (that "the (potential) downsides are worth the > potential gain"). So I don't think any consensus around that position > is > feasible. Why not? We're all reasonable people, aren't we? Obviously everyone is going to assess things (especially the risks) differently, but a nice large safety margin should help here. By the way, why would people who are against geo aggregation be against trying it? That way, they get to say "I told you so" when it fails. > As Christian points out, there is nothing to stop people from > experimenting > with it locally, though. I think what many people fail to realize is that you get to encode a small amount of information in the addressing hierarchy "for free". Being able to determine where a network is (for whatever definition of "where" we choose to apply) just by looking at the first bits of the prefix can be very useful in certain circumstances. However, the fact that this information is there doesn't mean everyone automatically has to act on it. In other words: if having an organization announce the /32 is the only way to get this show on the road, that's not the best way to do it, but it's better than nothing. But we should then still allocate these /32s from some kind of geographical addressing scheme so we get to do more in the future without renumbering if this is successful. From owner-multi6@ops.ietf.org Fri Apr 11 16:23:52 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28529 for ; Fri, 11 Apr 2003 16:23:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 194548-000LYC-00 for multi6-data@psg.com; Fri, 11 Apr 2003 20:24:04 +0000 Received: from mail1.microsoft.com ([131.107.3.125]) by psg.com with esmtp (Exim 3.36 #1) id 194545-000LXY-00 for multi6@ops.ietf.org; Fri, 11 Apr 2003 13:24:01 -0700 Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.6659); Fri, 11 Apr 2003 13:24:01 -0700 Received: from 157.54.8.155 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 11 Apr 2003 13:24:01 -0700 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Fri, 11 Apr 2003 13:24:00 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Fri, 11 Apr 2003 13:24:00 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3788.0); Fri, 11 Apr 2003 13:24:00 -0700 x-mimeole: Produced By Microsoft Exchange V6.5.6851.8 Content-class: urn:content-classes:message Subject: RE: Resolving geo discussions Date: Fri, 11 Apr 2003 13:23:56 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: Thread-Topic: Resolving geo discussions Thread-Index: AcMAW4erb7i8jn9jRKyRGZ8c49rb/AADBAMA From: "Christian Huitema" To: "Iljitsch van Beijnum" Cc: X-OriginalArrivalTime: 11 Apr 2003 20:24:00.0087 (UTC) FILETIME=[492E3670:01C30068] X-Spam-Status: No, hits=-10.4 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1 autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA28529 > > We have had this discussion many times in the past 10 years. After many > > rounds of e-mail, the consensus generally is that if geo is going to > > happen, it will happen "bottom up" and be user driven. > > This is news to me. I would really appreciate some pointers to archives > of these past discussions. Try the Big Internet mailing archives: ftp://munnari.oz.au/big-internet/list-archive > > For example, one > > may see the chamber of commerce of lower Picardy request a /32 from > > RIPE, and use it to provides "independent" /48 addresses to its > > members, > > using a combination of tunnels and arrangements with local ISP. In > > fact, > > there are already a few virtual ISP operating under this model. > > So if I want to do this in a slightly larger area, say everything > within a 20000 km radius of The Hague, I could get a larger address > block, say a /16? Not really. You will be subject to the same slow-start algorithm as regular ISP. You probably will get a /32 first, and when you will have demonstrated that you serve more than N sites, you will get a /30, etc. -- Christian Huitema From owner-multi6@ops.ietf.org Fri Apr 11 16:26:24 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28594 for ; Fri, 11 Apr 2003 16:26:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19458M-000M74-00 for multi6-data@psg.com; Fri, 11 Apr 2003 20:28:26 +0000 Received: from sj-core-1.cisco.com ([171.71.177.237]) by psg.com with esmtp (Exim 3.36 #1) id 19458J-000M6r-00 for multi6@ops.ietf.org; Fri, 11 Apr 2003 13:28:23 -0700 Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h3BKSLmi028287 for ; Fri, 11 Apr 2003 13:28:21 -0700 (PDT) Received: from cisco.com (dhcp-10-32-118-159.cisco.com [10.32.118.159]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with ESMTP id NAA29480 for ; Fri, 11 Apr 2003 13:28:20 -0700 (PDT) Date: Fri, 11 Apr 2003 13:28:42 -0700 Subject: Re: Resolving geo discussions Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) From: Darrell Root To: multi6@ops.ietf.org Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: <2FBD3AE4-6C5C-11D7-9FD7-000393C1B27E@cisco.com> X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit In theory the IETF gives large credence to "working code". Since this theoretical argument appears unresolvable, perhaps the way to proceed would be to allow some pilots (as previously suggested) and see whether geo works in practice. The proponents get an opportunity to prove that it works. The opponents get an opportunity to demonstrate the damage that the pilots caused to the v6 DFZ. But any damage would be limited to the extent of the pilots. The trick is getting the resources to execute the pilots. As long as this WG allows the allocation of a few pilot geo blocks (and allows sufficient freedom for the proponents to make their attempt), the proponents have most of the burden of making the attempt. Just my $0.02 regarding how to resolve this in a satisfactory way. Darrell Root droot@cisco.com On Friday, April 11, 2003, at 12:22 PM, Iljitsch van Beijnum wrote: > On vrijdag, apr 11, 2003, at 19:35 Europe/Amsterdam, J. Noel Chiappa > wrote: > >>> So how do we resolve this in a way that is satisfactory to everyone? > >> We probably can't. The two sides are pretty firmly entrenched, and >> without >> changing that, some group is likely to be unhappy. > > Still, I think it would be useful to try sufficiently hard that the > remaining disagreements can only be attributed to differing world > views, and not to lack of understanding or effort. Then at least we > all know we don't have to do it again for a good long time. > >>> Is there a way we can arrive on some consensus as to whether the >>> (potential) downsides are worth the potential gain? > >> No, because there will almost certainly be a large contingent who do >> not >> agree with that position (that "the (potential) downsides are worth >> the >> potential gain"). So I don't think any consensus around that position >> is >> feasible. > > Why not? We're all reasonable people, aren't we? Obviously everyone is > going to assess things (especially the risks) differently, but a nice > large safety margin should help here. > > By the way, why would people who are against geo aggregation be > against trying it? That way, they get to say "I told you so" when it > fails. > >> As Christian points out, there is nothing to stop people from >> experimenting >> with it locally, though. > > I think what many people fail to realize is that you get to encode a > small amount of information in the addressing hierarchy "for free". > Being able to determine where a network is (for whatever definition of > "where" we choose to apply) just by looking at the first bits of the > prefix can be very useful in certain circumstances. However, the fact > that this information is there doesn't mean everyone automatically has > to act on it. > > In other words: if having an organization announce the /32 is the only > way to get this show on the road, that's not the best way to do it, > but it's better than nothing. But we should then still allocate these > /32s from some kind of geographical addressing scheme so we get to do > more in the future without renumbering if this is successful. > > From owner-multi6@ops.ietf.org Fri Apr 11 17:05:25 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00476 for ; Fri, 11 Apr 2003 17:05:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 1945jt-0000PP-00 for multi6-data@psg.com; Fri, 11 Apr 2003 21:07:13 +0000 Received: from mailout.zma.compaq.com ([161.114.64.103] helo=zmamail03.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 1945jm-0000NE-00 for multi6@ops.ietf.org; Fri, 11 Apr 2003 14:07:06 -0700 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 1315E186D; Fri, 11 Apr 2003 17:07:06 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Fri, 11 Apr 2003 17:07:05 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Resolving geo discussions Date: Fri, 11 Apr 2003 17:07:05 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03241110@tayexc13.americas.cpqcorp.net> Thread-Topic: Resolving geo discussions Thread-Index: AcMAW4erb7i8jn9jRKyRGZ8c49rb/AADBAMAAAF8PbA= From: "Bound, Jim" To: "Christian Huitema" , "Iljitsch van Beijnum" Cc: X-OriginalArrivalTime: 11 Apr 2003 21:07:05.0974 (UTC) FILETIME=[4E7D4160:01C3006E] X-Spam-Status: No, hits=-9.8 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA00476 I have to throw in the towel and say I think Tony, Noel and Christian convinced me. Geo as core method in our architecture is not going to fly nor should we try to push this as RFC std. But doing bottom up probably will happen is my guess. I think an INFO RFC or BCP would get consensus here stating the ramifications of using this approach, but its your own trip. I would suggest this would put this debate as lets document it and issue BCP and we move on to solve the problem at hand with architecture we can review. Maybe if we had matrix of each one proposed on slide we could share as idea? - We kill this discussion and turn it into work with deliverable. - We remove it to continue the architecture effort - And maybe we could produce a doc INFO/BCP that would be useful and the IETF would think we have some clue as a team to produce something others can use :--) - And we don't discuss it for 10 more years and just point to the RFC which will be useful to those who have children and come here to do work someday :--) /jim > -----Original Message----- > From: Christian Huitema [mailto:huitema@windows.microsoft.com] > Sent: Friday, April 11, 2003 4:24 PM > To: Iljitsch van Beijnum > Cc: multi6@ops.ietf.org > Subject: RE: Resolving geo discussions > > > > > We have had this discussion many times in the past 10 years. After > many > > > rounds of e-mail, the consensus generally is that if geo > is going to > > > happen, it will happen "bottom up" and be user driven. > > > > This is news to me. I would really appreciate some pointers to > archives > > of these past discussions. > > Try the Big Internet mailing archives: > ftp://munnari.oz.au/big-internet/list-archive > > > > For example, one > > > may see the chamber of commerce of lower Picardy request > a /32 from > > > RIPE, and use it to provides "independent" /48 addresses to its > > > members, using a combination of tunnels and arrangements > with local > > > ISP. In fact, > > > there are already a few virtual ISP operating under this model. > > > > So if I want to do this in a slightly larger area, say everything > > within a 20000 km radius of The Hague, I could get a larger address > > block, say a /16? > > Not really. You will be subject to the same slow-start > algorithm as regular ISP. You probably will get a /32 first, > and when you will have demonstrated that you serve more than > N sites, you will get a /30, etc. > > -- Christian Huitema > > > From owner-multi6@ops.ietf.org Sat Apr 12 11:39:00 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29689 for ; Sat, 12 Apr 2003 11:39:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 194N6O-0001U7-00 for multi6-data@psg.com; Sat, 12 Apr 2003 15:39:36 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 194N6B-0001Te-00 for multi6@ops.ietf.org; Sat, 12 Apr 2003 08:39:23 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h3CFdHv31609; Sat, 12 Apr 2003 18:39:17 +0300 Date: Sat, 12 Apr 2003 18:39:17 +0300 (EEST) From: Pekka Savola To: Christian Huitema cc: Iljitsch van Beijnum , Subject: RE: Resolving geo discussions In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-31.7 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk On Fri, 11 Apr 2003, Christian Huitema wrote: > > > For example, one > > > may see the chamber of commerce of lower Picardy request a /32 from > > > RIPE, and use it to provides "independent" /48 addresses to its > > > members, > > > using a combination of tunnels and arrangements with local ISP. In > > > fact, > > > there are already a few virtual ISP operating under this model. > > > > So if I want to do this in a slightly larger area, say everything > > within a 20000 km radius of The Hague, I could get a larger address > > block, say a /16? > > Not really. You will be subject to the same slow-start algorithm as > regular ISP. You probably will get a /32 first, and when you will have > demonstrated that you serve more than N sites, you will get a /30, etc. Getting more than /32 is possible if it can be justified. For example, in RIPE: "Organisations may qualify for an initial allocation greater than /32 by submitting documentation that reasonably justifies the request. If so, the allocation size will be based on the number of existing users and the extent of the organisation's infrastructure." Not likely to happen if there are no existing users, though.. :-) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Mon Apr 14 05:13:18 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28739 for ; Mon, 14 Apr 2003 05:13:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 194zzl-000CKI-00 for multi6-data@psg.com; Mon, 14 Apr 2003 09:11:21 +0000 Received: from d12lmsgate-3.de.ibm.com ([194.196.100.236]) by psg.com with esmtp (Exim 3.36 #1) id 194zzO-000CJy-00 for multi6@ops.ietf.org; Mon, 14 Apr 2003 09:10:59 +0000 Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (8.12.9/8.12.8) with ESMTP id h3E9AqCi019442; Mon, 14 Apr 2003 11:10:52 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.de.ibm.com (8.12.8/NCO/VER6.5) with SMTP id h3E9AfTA182694; Mon, 14 Apr 2003 11:10:47 +0200 Received: from dhcp21-82.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA35024 from ; Mon, 14 Apr 2003 11:10:37 +0200 Message-Id: <3E9A7B38.6C57C83E@hursley.ibm.com> Date: Mon, 14 Apr 2003 11:11:20 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: "Bound, Jim" Cc: multi6@ops.ietf.org Subject: Re: Resolving geo discussions References: <9C422444DE99BC46B3AD3C6EAFC9711B03241110@tayexc13.americas.cpqcorp.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-29.3 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Yes, I think it is time to get out an info RFC on this. Indeed I haven't seen any new arguments for a number of years. We need a brave person to act as document editor though. rian "Bound, Jim" wrote: > > I have to throw in the towel and say I think Tony, Noel and Christian > convinced me. Geo as core method in our architecture is not going to > fly nor should we try to push this as RFC std. But doing bottom up > probably will happen is my guess. I think an INFO RFC or BCP would get > consensus here stating the ramifications of using this approach, but its > your own trip. > > I would suggest this would put this debate as lets document it and issue > BCP and we move on to solve the problem at hand with architecture we can > review. Maybe if we had matrix of each one proposed on slide we could > share as idea? > > - We kill this discussion and turn it into work with deliverable. > - We remove it to continue the architecture effort > - And maybe we could produce a doc INFO/BCP that would be useful and the > IETF would think we have some clue as a team to produce something others > can use :--) > - And we don't discuss it for 10 more years and just point to the RFC > which will be useful to those who have children and come here to do work > someday :--) > > /jim > > > -----Original Message----- > > From: Christian Huitema [mailto:huitema@windows.microsoft.com] > > Sent: Friday, April 11, 2003 4:24 PM > > To: Iljitsch van Beijnum > > Cc: multi6@ops.ietf.org > > Subject: RE: Resolving geo discussions > > > > > > > > We have had this discussion many times in the past 10 years. After > > many > > > > rounds of e-mail, the consensus generally is that if geo > > is going to > > > > happen, it will happen "bottom up" and be user driven. > > > > > > This is news to me. I would really appreciate some pointers to > > archives > > > of these past discussions. > > > > Try the Big Internet mailing archives: > > ftp://munnari.oz.au/big-internet/list-archive > > > > > > For example, one > > > > may see the chamber of commerce of lower Picardy request > > a /32 from > > > > RIPE, and use it to provides "independent" /48 addresses to its > > > > members, using a combination of tunnels and arrangements > > with local > > > > ISP. In fact, > > > > there are already a few virtual ISP operating under this model. > > > > > > So if I want to do this in a slightly larger area, say everything > > > within a 20000 km radius of The Hague, I could get a larger address > > > block, say a /16? > > > > Not really. You will be subject to the same slow-start > > algorithm as regular ISP. You probably will get a /32 first, > > and when you will have demonstrated that you serve more than > > N sites, you will get a /30, etc. > > > > -- Christian Huitema From owner-multi6@ops.ietf.org Mon Apr 14 07:39:03 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01170 for ; Mon, 14 Apr 2003 07:39:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 1952JE-000IWW-00 for multi6-data@psg.com; Mon, 14 Apr 2003 11:39:36 +0000 Received: from smtpzilla1.xs4all.nl ([194.109.127.137]) by psg.com with esmtp (Exim 3.36 #1) id 1952It-000IVk-00 for multi6@ops.ietf.org; Mon, 14 Apr 2003 11:39:15 +0000 Received: from muada.com (daisy.xs4all.nl [194.109.13.84]) by smtpzilla1.xs4all.nl (8.12.9/8.12.9) with ESMTP id h3EBcYYU047103; Mon, 14 Apr 2003 13:38:52 +0200 (CEST) Date: Mon, 14 Apr 2003 13:38:27 +0200 Subject: Re: Resolving geo discussions Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "Bound, Jim" , multi6@ops.ietf.org To: Brian E Carpenter From: Iljitsch van Beijnum In-Reply-To: <3E9A7B38.6C57C83E@hursley.ibm.com> Message-Id: <9B9B05BA-6E6D-11D7-9E1D-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On maandag, apr 14, 2003, at 11:11 Europe/Amsterdam, Brian E Carpenter wrote: > Yes, I think it is time to get out an info RFC on this. Indeed I > haven't > seen any new arguments for a number of years. We need a brave person to > act as document editor though. What exactly do we want to be in this RFC? If it's just "if you're going to do geo, beware of ..." I'll be happy to include something like that in the upcoming rewrite of my draft. Iljitsch van Beijnum From owner-multi6@ops.ietf.org Mon Apr 14 09:38:23 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05108 for ; Mon, 14 Apr 2003 09:38:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 1954AI-000MJx-00 for multi6-data@psg.com; Mon, 14 Apr 2003 13:38:30 +0000 Received: from d12lmsgate-5.de.ibm.com ([194.196.100.238]) by psg.com with esmtp (Exim 3.36 #1) id 19549w-000MJj-00 for multi6@ops.ietf.org; Mon, 14 Apr 2003 13:38:08 +0000 Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-5.de.ibm.com (8.12.9/8.12.8) with ESMTP id h3EDbvju056978; Mon, 14 Apr 2003 15:37:57 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.de.ibm.com (8.12.8/NCO/VER6.5) with SMTP id h3EDbvTA260484; Mon, 14 Apr 2003 15:37:57 +0200 Received: from dhcp21-82.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA52572 from ; Mon, 14 Apr 2003 15:37:46 +0200 Message-Id: <3E9AB9D5.26B2DD56@hursley.ibm.com> Date: Mon, 14 Apr 2003 15:38:29 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Iljitsch van Beijnum Cc: multi6@ops.ietf.org Subject: Re: Resolving geo discussions References: <9B9B05BA-6E6D-11D7-9E1D-00039388672E@muada.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-29.3 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Iljitsch van Beijnum wrote: > > On maandag, apr 14, 2003, at 11:11 Europe/Amsterdam, Brian E Carpenter > wrote: > > > Yes, I think it is time to get out an info RFC on this. Indeed I > > haven't > > seen any new arguments for a number of years. We need a brave person to > > act as document editor though. > > What exactly do we want to be in this RFC? > > If it's just "if you're going to do geo, beware of ..." I'll be happy > to include something like that in the upcoming rewrite of my draft. I think it needs to build on the observation that there is no congruence between network topology and geography to show that we have no way to make geo addresses aggregate in practice. It doesn't need to be that long. But since it's an abstract "why this doesn't work" argument, I think it needs to be separate from any specific technical proposal. Brian From owner-multi6@ops.ietf.org Mon Apr 14 10:09:25 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06566 for ; Mon, 14 Apr 2003 10:09:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 1954fd-000NUQ-00 for multi6-data@psg.com; Mon, 14 Apr 2003 14:10:53 +0000 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by psg.com with esmtp (Exim 3.36 #1) id 1954fG-000NSZ-00 for multi6@ops.ietf.org; Mon, 14 Apr 2003 14:10:31 +0000 Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id PAA01021; Mon, 14 Apr 2003 15:10:27 +0100 (BST) Received: from login.ecs.soton.ac.uk (login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3p2/8.9.3) with ESMTP id PAA03685; Mon, 14 Apr 2003 15:10:27 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h3EEARY30485; Mon, 14 Apr 2003 15:10:27 +0100 Date: Mon, 14 Apr 2003 15:10:26 +0100 From: Tim Chown To: multi6@ops.ietf.org Cc: Jordi Palet Subject: Re: Resolving geo discussions Message-ID: <20030414141026.GO26424@login.ecs.soton.ac.uk> Mail-Followup-To: multi6@ops.ietf.org, Jordi Palet References: <9B9B05BA-6E6D-11D7-9E1D-00039388672E@muada.com> <3E9AB9D5.26B2DD56@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E9AB9D5.26B2DD56@hursley.ibm.com> User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-38.8 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MUTT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk On Mon, Apr 14, 2003 at 03:38:29PM +0200, Brian E Carpenter wrote: > > I think it needs to build on the observation that there is no congruence > between network topology and geography to show that we have no way to make > geo addresses aggregate in practice. It doesn't need to be that long. > But since it's an abstract "why this doesn't work" argument, I think > it needs to be separate from any specific technical proposal. Well, geography meets topology at an IX, so the exchange-based addressing experiments being done by Euro6IX are interesting in this respect, possibly. Perhaps Jordi can comment on that. Tim From owner-multi6@ops.ietf.org Mon Apr 14 10:38:40 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07899 for ; Mon, 14 Apr 2003 10:38:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19557m-000OLf-00 for multi6-data@psg.com; Mon, 14 Apr 2003 14:39:58 +0000 Received: from pc154.iihe.ac.be ([193.190.246.174]) by psg.com with smtp (Exim 3.36 #1) id 19557P-000OKB-00 for multi6@ops.ietf.org; Mon, 14 Apr 2003 14:39:36 +0000 Received: from consulintel02 ([193.190.247.197]) by helios.iihe.ac.be (8.11.6/8.11.6) with SMTP id h3EEae900345 for ; Mon, 14 Apr 2003 16:36:40 +0200 Message-ID: <009f01c30293$ad66f640$c5f7bec1@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: <9B9B05BA-6E6D-11D7-9E1D-00039388672E@muada.com> <3E9AB9D5.26B2DD56@hursley.ibm.com> <20030414141026.GO26424@login.ecs.soton.ac.uk> Subject: Re: Resolving geo discussions Date: Mon, 14 Apr 2003 16:39:35 +0200 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Status: No, hits=-22.6 required=5.0 tests=BAYES_01,ORIGINAL_MESSAGE,QUOTED_EMAIL_TEXT,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Right, I'm following the discussion in "silent mode", because I've no cycles now with the preparation of several new projects, and the Madrid Summit, in addition to my regular work in several projects ... not too much ! But I'm sure that other people from Euro6IX can also comment on this. Anyway, if I survive to my actual 1-hour sleep time per day, at the end of the month, I will try to be more proactive. Regards, Jordi ----- Original Message ----- From: "Tim Chown" To: Cc: "Jordi Palet" Sent: Monday, April 14, 2003 4:10 PM Subject: Re: Resolving geo discussions > On Mon, Apr 14, 2003 at 03:38:29PM +0200, Brian E Carpenter wrote: > > > > I think it needs to build on the observation that there is no congruence > > between network topology and geography to show that we have no way to make > > geo addresses aggregate in practice. It doesn't need to be that long. > > But since it's an abstract "why this doesn't work" argument, I think > > it needs to be separate from any specific technical proposal. > > Well, geography meets topology at an IX, so the exchange-based addressing > experiments being done by Euro6IX are interesting in this respect, > possibly. Perhaps Jordi can comment on that. > > Tim > From owner-multi6@ops.ietf.org Mon Apr 14 11:37:13 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09664 for ; Mon, 14 Apr 2003 11:37:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19562t-0000C6-00 for multi6-data@psg.com; Mon, 14 Apr 2003 15:38:59 +0000 Received: from d12lmsgate-4.de.ibm.com ([194.196.100.237]) by psg.com with esmtp (Exim 3.36 #1) id 19562E-0000AE-00 for multi6@ops.ietf.org; Mon, 14 Apr 2003 15:38:18 +0000 Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-4.de.ibm.com (8.12.9/8.12.8) with ESMTP id h3EFbgDI092292; Mon, 14 Apr 2003 17:37:43 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.de.ibm.com (8.12.8/NCO/VER6.5) with SMTP id h3EFbcTA225342; Mon, 14 Apr 2003 17:37:39 +0200 Received: from dhcp21-82.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA31690 from ; Mon, 14 Apr 2003 17:37:34 +0200 Message-Id: <3E9AD5E8.91387EE3@hursley.ibm.com> Date: Mon, 14 Apr 2003 17:38:17 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Tim Chown Cc: multi6@ops.ietf.org, Jordi Palet Subject: Re: Resolving geo discussions References: <9B9B05BA-6E6D-11D7-9E1D-00039388672E@muada.com> <3E9AB9D5.26B2DD56@hursley.ibm.com> <20030414141026.GO26424@login.ecs.soton.ac.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-29.3 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Tim Chown wrote: > > On Mon, Apr 14, 2003 at 03:38:29PM +0200, Brian E Carpenter wrote: > > > > I think it needs to build on the observation that there is no congruence > > between network topology and geography to show that we have no way to make > > geo addresses aggregate in practice. It doesn't need to be that long. > > But since it's an abstract "why this doesn't work" argument, I think > > it needs to be separate from any specific technical proposal. > > Well, geography meets topology at an IX, so the exchange-based addressing > experiments being done by Euro6IX are interesting in this respect, > possibly. Perhaps Jordi can comment on that. > There's no doubt that if you can persuade all the upstream ISPs to do the right thing, and persuade all the local downstream ISPs to do the right thing, the IX-based addressing model can help a lot (and can simply use PA space as if it was PI). But I don't think the economic forces involved will exercise the required persuasion. Brian From owner-multi6@ops.ietf.org Mon Apr 14 11:58:43 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10244 for ; Mon, 14 Apr 2003 11:58:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 1956Mz-0000xy-00 for multi6-data@psg.com; Mon, 14 Apr 2003 15:59:45 +0000 Received: from ginger.lcs.mit.edu ([18.26.0.82]) by psg.com with esmtp (Exim 3.36 #1) id 1956MN-0000wI-00 for multi6@ops.ietf.org; Mon, 14 Apr 2003 15:59:07 +0000 Received: from ginger.lcs.mit.edu (localhost [127.0.0.1]) by ginger.lcs.mit.edu (8.12.9/8.12.9) with ESMTP id h3EFx3tU018329; Mon, 14 Apr 2003 11:59:03 -0400 Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.12.9/8.12.9/Submit) id h3EFx2Y3018328; Mon, 14 Apr 2003 11:59:02 -0400 Date: Mon, 14 Apr 2003 11:59:02 -0400 From: "J. Noel Chiappa" Message-Id: <200304141559.h3EFx2Y3018328@ginger.lcs.mit.edu> To: multi6@ops.ietf.org Subject: Re: Resolving geo discussions Cc: jnc@ginger.lcs.mit.edu X-Spam-Status: No, hits=-6.6 required=5.0 tests=BAYES_01 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: Brian E Carpenter > There's no doubt that if you can persuade all the upstream ISPs to do > the right thing, and persuade all the local downstream ISPs to do the > right thing, the IX-based addressing model can help a lot (and can > simply use PA space as if it was PI). But I don't think the economic > forces involved will exercise the required persuasion. As an aside, and also in tune with your comment, people might want to note that getting addresses from a local exchange (what I used to call a "cooperative exchange point") has a big advantage, which is that you're not tied to a single supplier; i.e. it's effectively number portability, as the exchange can switch members in the set of carriers providing service without anyone renumbering. Of course, if you decide you're unhappy with the exchange, and want to leave, then you are stuck! :-) Also, this may lead ISP's to decide that they'd rather not support exchanges, since the customers are less locked-in (q.v. your comments about economic forces)! However, I'd imagine that if the exchange is big enough, and there are enough competing carriers, some carrier(s) will decide they'd rather have less-locked-in business, than no business at all. After all, plenty of markets operate without this level of lock-in. Noel From owner-multi6@ops.ietf.org Mon Apr 14 12:14:30 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10618 for ; Mon, 14 Apr 2003 12:14:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 1956cl-0001dv-00 for multi6-data@psg.com; Mon, 14 Apr 2003 16:16:03 +0000 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by psg.com with esmtp (Exim 3.36 #1) id 1956cP-0001cB-00 for multi6@ops.ietf.org; Mon, 14 Apr 2003 16:15:42 +0000 Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id RAA02673 for ; Mon, 14 Apr 2003 17:15:40 +0100 (BST) Received: from login.ecs.soton.ac.uk (login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3p2/8.9.3) with ESMTP id RAA13902 for ; Mon, 14 Apr 2003 17:15:40 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h3EGFeh01233 for multi6@ops.ietf.org; Mon, 14 Apr 2003 17:15:40 +0100 Date: Mon, 14 Apr 2003 17:15:40 +0100 From: Tim Chown To: multi6@ops.ietf.org Subject: Re: Resolving geo discussions Message-ID: <20030414161540.GZ26424@login.ecs.soton.ac.uk> Mail-Followup-To: multi6@ops.ietf.org References: <200304141559.h3EFx2Y3018328@ginger.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200304141559.h3EFx2Y3018328@ginger.lcs.mit.edu> User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-38.8 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MUTT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk On Mon, Apr 14, 2003 at 11:59:02AM -0400, J. Noel Chiappa wrote: > > From: Brian E Carpenter > > > There's no doubt that if you can persuade all the upstream ISPs to do > > the right thing, and persuade all the local downstream ISPs to do the > > right thing, the IX-based addressing model can help a lot (and can > > simply use PA space as if it was PI). But I don't think the economic > > forces involved will exercise the required persuasion. > > As an aside, and also in tune with your comment, people might want to note > that getting addresses from a local exchange (what I used to call a > "cooperative exchange point") has a big advantage, which is that you're not > tied to a single supplier; i.e. it's effectively number portability, as the > exchange can switch members in the set of carriers providing service without > anyone renumbering. That is the plus, and what I understand Euro6IX is investigating. > Of course, if you decide you're unhappy with the exchange, and want to leave, > then you are stuck! :-) Well, there are only so many exchanges in any big city :) But if you can arrange to stay with the same exchange, your chances of retaining your address block from that exchange are higher. > Also, this may lead ISP's to decide that they'd rather not support exchanges, > since the customers are less locked-in (q.v. your comments about economic > forces)! However, I'd imagine that if the exchange is big enough, and there > are enough competing carriers, some carrier(s) will decide they'd rather have > less-locked-in business, than no business at all. After all, plenty of markets > operate without this level of lock-in. Hopefully someone on the network modelling side of Euro6IX can comment. Tim From owner-multi6@ops.ietf.org Mon Apr 14 18:20:42 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24994 for ; Mon, 14 Apr 2003 18:20:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 195CJP-000MjS-00 for multi6-data@psg.com; Mon, 14 Apr 2003 22:20:27 +0000 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 195CJ2-000Mfg-00 for multi6@ops.ietf.org; Mon, 14 Apr 2003 22:20:04 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h3EMItE57804; Tue, 15 Apr 2003 00:18:55 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Tue, 15 Apr 2003 00:18:44 +0200 Subject: Re: Resolving geo discussions Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: multi6@ops.ietf.org To: Brian E Carpenter From: Iljitsch van Beijnum In-Reply-To: <3E9AB9D5.26B2DD56@hursley.ibm.com> Message-Id: <0DD80421-6EC7-11D7-9A51-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On maandag, apr 14, 2003, at 15:38 Europe/Amsterdam, Brian E Carpenter wrote: >> What exactly do we want to be in this RFC? > think it needs to build on the observation that there is no congruence > between network topology and geography to show that we have no way to > make > geo addresses aggregate in practice. It doesn't need to be that long. > But since it's an abstract "why this doesn't work" argument, I think > it needs to be separate from any specific technical proposal. I disagree. The whole point of this RFC would be to end the discussion. That's not going to happen by simply presenting one viewpoint. Either it needs to be an overview that lists all the arguments pro and con and possibly drawing some conclusions along the way, or if it only presents a single point of view it must get into the nitty gritty and not suffice with "I know someone in Jakarta who connects to Reykjavik so geo aggregation can't work". Why don't we do some calculations to see how good or bad it can work? For instance, even in a worst case scenario when distribution of interconnection is completely random, there is always some gain to be had: if there are m interconnects, having an aggregate point to one interconnect and then filter out all routes that are identical to the aggregate must save 1/m-th in the routing table size in all nodes except the one sourcing the aggregate. If we accept some constraints, we can do much better. For instance, if we use a fully switched network (not inconceivable with MPLS) we can have one node that sources the aggregate and holds all more specifics, all other nodes only need the aggregate and the more specifics learned from the local interconnect, which is 1/m-th of all more specifics on average. In a routed network, the gains aren't as big as all intermediate nodes need to know the more specifics for packets that may need to be routed through them, but some quick guestimates land around the 50% mark. That's 18 months according to Moore, which doesn't sound like much but 1.5 years interest on the "aluminum factory" as one former boss used to call it (our new network cost the same as an aluminum factory (and probably used as much electricity too)) adds up to a substantial pile of change. From owner-multi6@ops.ietf.org Tue Apr 15 11:45:59 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01988 for ; Tue, 15 Apr 2003 11:45:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 195Sd5-000EUD-00 for multi6-data@psg.com; Tue, 15 Apr 2003 15:45:51 +0000 Received: from d12lmsgate-2.de.ibm.com ([194.196.100.235]) by psg.com with esmtp (Exim 3.36 #1) id 195Scc-000ETB-00 for multi6@ops.ietf.org; Tue, 15 Apr 2003 15:45:23 +0000 Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (8.12.9/8.12.8) with ESMTP id h3FFjCUm017012; Tue, 15 Apr 2003 17:45:13 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.de.ibm.com (8.12.8/NCO/VER6.5) with SMTP id h3FFjBhe275874; Tue, 15 Apr 2003 17:45:12 +0200 Received: from dhcp21-82.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA54348 from ; Tue, 15 Apr 2003 17:45:04 +0200 Message-Id: <3E9C292B.A4EA139D@hursley.ibm.com> Date: Tue, 15 Apr 2003 17:45:47 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Iljitsch van Beijnum Cc: multi6@ops.ietf.org Subject: Re: Resolving geo discussions References: <0DD80421-6EC7-11D7-9A51-00039388672E@muada.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-29.9 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1, REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Iljitsch van Beijnum wrote: > > On maandag, apr 14, 2003, at 15:38 Europe/Amsterdam, Brian E Carpenter > wrote: > > >> What exactly do we want to be in this RFC? > > > think it needs to build on the observation that there is no congruence > > between network topology and geography to show that we have no way to > > make > > geo addresses aggregate in practice. It doesn't need to be that long. > > But since it's an abstract "why this doesn't work" argument, I think > > it needs to be separate from any specific technical proposal. > > I disagree. The whole point of this RFC would be to end the discussion. > That's not going to happen by simply presenting one viewpoint. Either > it needs to be an overview that lists all the arguments pro and con and Of course > possibly drawing some conclusions along the way, It needs to, otherwise it can't be used as a reference to avoid future repeat discussions. > or if it only presents > a single point of view I think you mean "a clear conclusion" :-) > it must get into the nitty gritty and not > suffice with "I know someone in Jakarta who connects to Reykjavik so > geo aggregation can't work". Yes, but there is the pesky interaction with economic forces to consider. That makes it hard to avoid the final conclusion being a judgement. > > Why don't we do some calculations to see how good or bad it can work? > > For instance, even in a worst case scenario when distribution of > interconnection is completely random, there is always some gain to be > had: if there are m interconnects, having an aggregate point to one > interconnect and then filter out all routes that are identical to the > aggregate must save 1/m-th in the routing table size in all nodes > except the one sourcing the aggregate. > > If we accept some constraints, we can do much better. For instance, if > we use a fully switched network (not inconceivable with MPLS) we can > have one node that sources the aggregate and holds all more specifics, > all other nodes only need the aggregate and the more specifics learned > from the local interconnect, which is 1/m-th of all more specifics on > average. I don't think that allows for the economic constraints that mean that certain traffic is only allowed to travel on links paid for by certain parties. In other words you can theorize about some ideal mathematical model, but how do you mix in the economic constraints? One of today's constraints, for example, is "get rid of the packet as quick as you can, unless it's going to my own customer" and that has major impact on the BGP4 topology. I think this quickly gets into Research Group territory. > > In a routed network, the gains aren't as big as all intermediate nodes > need to know the more specifics for packets that may need to be routed > through them, but some quick guestimates land around the 50% mark. > That's 18 months according to Moore, which doesn't sound like much but > 1.5 years interest on the "aluminum factory" as one former boss used to > call it (our new network cost the same as an aluminum factory (and > probably used as much electricity too)) adds up to a substantial pile > of change. But it isn't just Moore's law. It's convergence time. And this is exactly where we are still waiting for useable output from the Routing Research Group. Brian From owner-multi6@ops.ietf.org Tue Apr 15 13:03:46 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04094 for ; Tue, 15 Apr 2003 13:03:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 195Tr2-000HQY-00 for multi6-data@psg.com; Tue, 15 Apr 2003 17:04:20 +0000 Received: from tele2-1-1-dialup-140.freesurf.ch ([194.230.196.140] helo=dhcp1.se.kurtis.pp.se) by psg.com with esmtp (Exim 3.36 #1) id 195Tqd-000HOu-00 for multi6@ops.ietf.org; Tue, 15 Apr 2003 17:03:56 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp1.se.kurtis.pp.se (8.12.9/8.10.2) with ESMTP id h3FH5HBQ001544; Tue, 15 Apr 2003 19:05:19 +0200 (CEST) Date: Tue, 15 Apr 2003 19:00:12 +0200 Subject: Re: Resolving geo discussions Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: Darrell Root From: Kurt Erik Lindqvist In-Reply-To: <2FBD3AE4-6C5C-11D7-9FD7-000393C1B27E@cisco.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-16.7 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1, USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > In theory the IETF gives large credence to "working code". Since this > theoretical argument appears unresolvable, perhaps the way to proceed > would be to allow some pilots (as previously suggested) and see whether > geo works in practice. > > The proponents get an opportunity to prove that it works. The > opponents > get an opportunity to demonstrate the damage that the pilots caused > to the v6 DFZ. But any damage would be limited to the extent of the > pilots. > > The trick is getting the resources to execute the pilots. As long as > this > WG allows the allocation of a few pilot geo blocks (and allows > sufficient > freedom for the proponents to make their attempt), the proponents > have most of the burden of making the attempt. > > Just my $0.02 regarding how to resolve this in a satisfactory way. > Well, I am not sure we need the WG to give a few blocks for this. I think that we to prove GEO allocations work, you could do with any give size of block. Even /48 (although it gets somewhat harder). As for discussion so far - I think that if someone would write up the discussions so far, as to why geo aggregation won't work, that would be easier to compare to the proposals. - kurtis - From owner-multi6@ops.ietf.org Tue Apr 15 13:04:21 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04146 for ; Tue, 15 Apr 2003 13:04:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 195Tsx-000HW2-00 for multi6-data@psg.com; Tue, 15 Apr 2003 17:06:19 +0000 Received: from tele2-1-1-dialup-140.freesurf.ch ([194.230.196.140] helo=dhcp1.se.kurtis.pp.se) by psg.com with esmtp (Exim 3.36 #1) id 195TsZ-000HUf-00 for multi6@ops.ietf.org; Tue, 15 Apr 2003 17:05:56 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp1.se.kurtis.pp.se (8.12.9/8.10.2) with ESMTP id h3FH5LBQ001547; Tue, 15 Apr 2003 19:05:23 +0200 (CEST) Date: Tue, 15 Apr 2003 19:01:37 +0200 Subject: Re: Resolving geo discussions Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "Christian Huitema" , "Iljitsch van Beijnum" , To: "Bound, Jim" From: Kurt Erik Lindqvist In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B03241110@tayexc13.americas.cpqcorp.net> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.7 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On fredag, apr 11, 2003, at 23:07 Europe/Stockholm, Bound, Jim wrote: > > I would suggest this would put this debate as lets document it and > issue > BCP and we move on to solve the problem at hand with architecture we > can > review. Maybe if we had matrix of each one proposed on slide we could > share as idea? > > - We kill this discussion and turn it into work with deliverable. > - We remove it to continue the architecture effort > - And maybe we could produce a doc INFO/BCP that would be useful and > the > IETF would think we have some clue as a team to produce something > others > can use :--) > - And we don't discuss it for 10 more years and just point to the RFC > which will be useful to those who have children and come here to do > work > someday :--) > > Well, what you are saying is along the lines I tried to say in my other mail. Although I am not sure a BCP is the right way forward. I think we need something that more looks like the scenarios documents from v6ops. - kurtis - From owner-multi6@ops.ietf.org Tue Apr 15 13:04:46 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04169 for ; Tue, 15 Apr 2003 13:04:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 195TtP-000HXj-00 for multi6-data@psg.com; Tue, 15 Apr 2003 17:06:47 +0000 Received: from tele2-1-1-dialup-140.freesurf.ch ([194.230.196.140] helo=dhcp1.se.kurtis.pp.se) by psg.com with esmtp (Exim 3.36 #1) id 195Tsd-000HUe-00 for multi6@ops.ietf.org; Tue, 15 Apr 2003 17:06:00 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp1.se.kurtis.pp.se (8.12.9/8.10.2) with ESMTP id h3FH5TBQ001550; Tue, 15 Apr 2003 19:05:32 +0200 (CEST) Date: Tue, 15 Apr 2003 19:02:17 +0200 Subject: Re: Resolving geo discussions Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "Bound, Jim" , multi6@ops.ietf.org To: Brian E Carpenter From: Kurt Erik Lindqvist In-Reply-To: <3E9A7B38.6C57C83E@hursley.ibm.com> Message-Id: <03874828-6F64-11D7-886B-000393AB1404@kurtis.pp.se> X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA04169 Anyone? :-) - kurtis - On måndag, apr 14, 2003, at 11:11 Europe/Stockholm, Brian E Carpenter wrote: > Yes, I think it is time to get out an info RFC on this. Indeed I > haven't > seen any new arguments for a number of years. We need a brave person to > act as document editor though. > > rian > > "Bound, Jim" wrote: >> >> I have to throw in the towel and say I think Tony, Noel and Christian >> convinced me. Geo as core method in our architecture is not going to >> fly nor should we try to push this as RFC std. But doing bottom up >> probably will happen is my guess. I think an INFO RFC or BCP would >> get >> consensus here stating the ramifications of using this approach, but >> its >> your own trip. >> >> I would suggest this would put this debate as lets document it and >> issue >> BCP and we move on to solve the problem at hand with architecture we >> can >> review. Maybe if we had matrix of each one proposed on slide we could >> share as idea? >> >> - We kill this discussion and turn it into work with deliverable. >> - We remove it to continue the architecture effort >> - And maybe we could produce a doc INFO/BCP that would be useful and >> the >> IETF would think we have some clue as a team to produce something >> others >> can use :--) >> - And we don't discuss it for 10 more years and just point to the RFC >> which will be useful to those who have children and come here to do >> work >> someday :--) >> >> /jim >> >>> -----Original Message----- >>> From: Christian Huitema [mailto:huitema@windows.microsoft.com] >>> Sent: Friday, April 11, 2003 4:24 PM >>> To: Iljitsch van Beijnum >>> Cc: multi6@ops.ietf.org >>> Subject: RE: Resolving geo discussions >>> >>> >>>>> We have had this discussion many times in the past 10 years. After >>> many >>>>> rounds of e-mail, the consensus generally is that if geo >>> is going to >>>>> happen, it will happen "bottom up" and be user driven. >>>> >>>> This is news to me. I would really appreciate some pointers to >>> archives >>>> of these past discussions. >>> >>> Try the Big Internet mailing archives: >>> ftp://munnari.oz.au/big-internet/list-archive >>> >>>>> For example, one >>>>> may see the chamber of commerce of lower Picardy request >>> a /32 from >>>>> RIPE, and use it to provides "independent" /48 addresses to its >>>>> members, using a combination of tunnels and arrangements >>> with local >>>>> ISP. In fact, >>>>> there are already a few virtual ISP operating under this model. >>>> >>>> So if I want to do this in a slightly larger area, say everything >>>> within a 20000 km radius of The Hague, I could get a larger address >>>> block, say a /16? >>> >>> Not really. You will be subject to the same slow-start >>> algorithm as regular ISP. You probably will get a /32 first, >>> and when you will have demonstrated that you serve more than >>> N sites, you will get a /30, etc. >>> >>> -- Christian Huitema > From owner-multi6@ops.ietf.org Tue Apr 15 17:15:52 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12314 for ; Tue, 15 Apr 2003 17:15:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 195XmW-0001WJ-00 for multi6-data@psg.com; Tue, 15 Apr 2003 21:15:56 +0000 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 195XmA-0001W0-00 for multi6@ops.ietf.org; Tue, 15 Apr 2003 21:15:34 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h3FLEOE59957; Tue, 15 Apr 2003 23:14:24 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Tue, 15 Apr 2003 23:14:14 +0200 Subject: Re: Resolving geo discussions Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: Brian E Carpenter From: Iljitsch van Beijnum In-Reply-To: <3E9C292B.A4EA139D@hursley.ibm.com> Message-Id: <35D65AB2-6F87-11D7-8CEB-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On dinsdag, apr 15, 2003, at 17:45 Europe/Amsterdam, Brian E Carpenter wrote: >> or if it only presents >> a single point of view > I think you mean "a clear conclusion" :-) Do I? >> it must get into the nitty gritty and not >> suffice with "I know someone in Jakarta who connects to Reykjavik so >> geo aggregation can't work". > Yes, but there is the pesky interaction with economic forces to > consider. > That makes it hard to avoid the final conclusion being a judgement. Economy is much like routing: if you get to assign the costs, you can pretty much make it do anything. [...] >> If we accept some constraints, we can do much better. [...] > I don't think that allows for the economic constraints that > mean that certain traffic is only allowed to travel on links > paid for by certain parties. I'm only concerned with routing inside individual provider networks, so this shouldn't be a problem. > In other words you can theorize > about some ideal mathematical model, but how do you mix in > the economic constraints? One of today's constraints, for example, > is "get rid of the packet as quick as you can, unless it's going > to my own customer" and that has major impact on the BGP4 topology. Yes, this is an important issue. Please read section 10 in my draft, but here is my conclusion: Since networks can control the level of late exit routing by (selectively) de-aggregating and many interconnection (peering) agreements call for equal traffic volumes in both directions, the potential for changes in the flow of traffic should not adversely affect existing networks. > I think this quickly gets into Research Group territory. Hm, can we afford to wait for results there? The way I see it, if we start giving out GAPI addresses now, we have a few years to come up with good aggregation before we really need it. If it turns out that geo aggregation is unworkable a solution like MHAP that can use PI addresses without the need to have them in the routing tables can still save us without renumbering. Only if that doesn't work either the GAPI users need to renumber. On the other hand, if the IRTF comes up with something good in 3 years, everyone who is multihoming using some kind of ad-hoc method such as shooting holes in PA will need to renumber at that point for it to work. That probably means that very few people will use it as renumbering is a huge pain. >> In a routed network, the gains aren't as big as all intermediate nodes >> need to know the more specifics for packets that may need to be routed >> through them, but some quick guestimates land around the 50% mark. >> That's 18 months according to Moore, which doesn't sound like much but >> 1.5 years interest on the "aluminum factory" as one former boss used >> to >> call it (our new network cost the same as an aluminum factory (and >> probably used as much electricity too)) adds up to a substantial pile >> of change. > But it isn't just Moore's law. It's convergence time. And this is > exactly > where we are still waiting for useable output from the Routing > Research Group. Aggregation helps with convergence too. From owner-multi6@ops.ietf.org Tue Apr 15 21:51:00 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19564 for ; Tue, 15 Apr 2003 21:50:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 195c4h-000EFI-00 for multi6-data@psg.com; Wed, 16 Apr 2003 01:50:59 +0000 Received: from host217-37-202-105.in-addr.btopenworld.com ([217.37.202.105] helo=ab.use.net) by psg.com with esmtp (Exim 3.36 #1) id 195c4K-000EER-00 for multi6@ops.ietf.org; Wed, 16 Apr 2003 01:50:36 +0000 Received: from ab.use.net (conf.use.net [217.37.202.109]) by ab.use.net (Postfix) with ESMTP id 772EF39742; Wed, 16 Apr 2003 01:50:33 +0000 (GMT) Date: Wed, 16 Apr 2003 02:50:33 +0100 Subject: Re: Resolving geo discussions Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Sean Doran , Brian E Carpenter , multi6@ops.ietf.org To: Iljitsch van Beijnum From: Sean Doran In-Reply-To: <35D65AB2-6F87-11D7-8CEB-00039388672E@muada.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-28.3 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit WRT geographical address assignments: mutually-hostile sites overlap physically already, and the incidence of this is increasing. Site multihoming approaches which do not take this into account should already be considered unworkable. Even perfect GPS knowledge in every device does not eliminate the need to have a DHCP dialogue or some other configuration activity in the host or in the network (or both), in the presence of multiple overlapping administrative domains. Geographical addressing strategies of any variety must be able to cope with this sort of thing (think of a set of overlapping 802.1 networks at an IETF venue: one for normal hotel guests, one for hotel operating activities, and one for IETF attendees, each with different access and usage policies, wireless network names, passwords, and inter-network connectivity), or they are simply uninteresting. On Tuesday, Apr 15, 2003, at 22:14 Europe/London, Iljitsch van Beijnum wrote: > The way I see it, if we start giving out GAPI addresses now, we have a > few years to come up with good aggregation before we really need it. > If it turns out that geo aggregation is unworkable a solution like > MHAP that can use PI addresses without the need to have them in the > routing tables can still save us without renumbering. Only if that > doesn't work either the GAPI users need to renumber. Single IPv6 numbers are not obviously rich enough to convey information about more than one network attachment point. Consequently, things with multiple attachment points need more than one number (leading to a possible explosion of addresses in the presence of very rich connectivity), or distant parties need to be able to map single numbers to multiple attachment points (leading to a possible explosion of information in the mapping system), or distant parties must remain ignorant of the existence of multiple attachment points (leading to non-optimal routing). Where there is a mechanism whereby numbered things acquire their numbers in a more timely and shorter-term fashion than today's long-term static assignment to DHCP servers and to some hosts, then the question of what the numbers are becomes relevant in analysing the risk of these explosive increases of connectivity information. Imagine that we could build a GPS receiver into every single device that is IPv6 capable. This does not provide these devices insight into their network locations, because in a single cubic metre in a telehousing facility, a device's next-hop might be able to attach to several providers simultaneously, but it might not be able to attach to all of the providers at once due to failures, economics, or policy. Simply knowing where the device is physically does not allow a distant party to make a good decision about which of several different providers' first-hop routers is the best next-hop to that physical coordinate. This is already not a purely theoretical problem. There are already many individual cubic metres (and centimetres and even millimetres) wherein there are growing amounts of numbered things. Some of these things really do need multiple numbers rather than clever ways of deriving physical location, particularly considering, for example, virtual routers (e.g. cosinecom.com) participating in multiple discrete virtual and actual network topologies within different administrative domains. This is one way some providers support VPNs, and there are existing real-world cases of deploying a virtual router platform into a telco central office. Other providers are offered a virtual access router which in effect behaves and is managed as if it were a real physical access router in that facility, as opposed to being offered ATM or ethernet based aggregation and backhaul. If you are doing DHCP or configuration activity in the host, then you might as well use standard topologically assigned ("PA") addressing and take advantage of the fact that this just works for the singly-numbered case, and it is easy to acquire multiple numbers this way, should the host and the site both support that and find it useful. There is so little to be gained for the cost of maintaining a fine-grained geographical address distribution strategy globally that, to put it bluntly, nobody who is actually in a position to support such a thing is likely to be remotely interested in doing so. > On the other hand, if the IRTF comes up with something good "The IRTF" is us. The people overlap is substantial. There is no magic resource hiding in the IRTF that is not here as well. > renumbering is a huge pain. This is the root of the problem. "Never renumber" is the wrong solution. Sean. From owner-multi6@ops.ietf.org Tue Apr 15 22:07:06 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19890 for ; Tue, 15 Apr 2003 22:07:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 195cM5-000F8j-00 for multi6-data@psg.com; Wed, 16 Apr 2003 02:08:57 +0000 Received: from host217-37-202-105.in-addr.btopenworld.com ([217.37.202.105] helo=ab.use.net) by psg.com with esmtp (Exim 3.36 #1) id 195cLi-000F6G-00 for multi6@ops.ietf.org; Wed, 16 Apr 2003 02:08:34 +0000 Received: from ab.use.net (conf.use.net [217.37.202.109]) by ab.use.net (Postfix) with ESMTP id 467EE39742; Wed, 16 Apr 2003 02:08:33 +0000 (GMT) Date: Wed, 16 Apr 2003 03:08:32 +0100 Subject: Re: Resolving geo discussions Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Sean Doran , Iljitsch van Beijnum , multi6@ops.ietf.org To: Brian E Carpenter From: Sean Doran In-Reply-To: <3E9C292B.A4EA139D@hursley.ibm.com> Message-Id: <5301A1D4-6FB0-11D7-9ED5-0003938E4DE4@ab.use.net> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Tuesday, Apr 15, 2003, at 16:45 Europe/London, Brian E Carpenter wrote: > One of today's constraints, for example, > is "get rid of the packet as quick as you can, unless it's going > to my own customer" and that has major impact on the BGP4 topology. Hot-potato routing, which you describe reasonably well in the quote above, is an artifact of the non-use of MEDs. This is not a very strong requirement, and mostly exists because of mid-1990s differences in internal metrics between Sprintlink and InternetMCI leading to the realization that one could never really rely upon neighbour A's MEDs making sense in comparison with neighbour B. Decreasing inter-provider trust over time also eroded the value of MEDs from other networks, and ignoring/rewriting them effectively led to mutual hot-potato routing becoming commonplace. However, it was never universal, and still isn't. There are networks which accept MEDs from e.g. customers, just as there was a network which did static MED-like multi-exit handling in the PR^H^HRADB. The BGP4 topology (assuming we could agree on a definition) is not affected by the MED/no-MED decision because of the inability to compare reliably and in a useful way MEDs offered by different ASes announcing the same prefix. > I think this quickly gets into Research Group territory. Unless it gets in the way of actual charter-relevant work, I personally don't mind this sort of discussion happening on this list instead of on one within the RRG. The people are going to be the same anyway, for the most part, and at the moment it doesn't really matter in which forum clue gets applied, so long as it can be (or does). > But it isn't just Moore's law. It's convergence time. And this is > exactly > where we are still waiting for useable output from the Routing > Research Group. Frank & I would be thrilled if you would volunteer yourself to manage a subgroup focused on producing exactly this output. irtf-rr-chairs@puck.nether.net. Other applicants also seriously welcome. Sean. From owner-multi6@ops.ietf.org Tue Apr 15 22:30:56 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20217 for ; Tue, 15 Apr 2003 22:30:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 195cj7-000GTp-00 for multi6-data@psg.com; Wed, 16 Apr 2003 02:32:45 +0000 Received: from host217-37-202-105.in-addr.btopenworld.com ([217.37.202.105] helo=ab.use.net) by psg.com with esmtp (Exim 3.36 #1) id 195cij-000GTR-00 for multi6@ops.ietf.org; Wed, 16 Apr 2003 02:32:22 +0000 Received: from ab.use.net (conf.use.net [217.37.202.109]) by ab.use.net (Postfix) with ESMTP id 979A239742; Wed, 16 Apr 2003 02:32:20 +0000 (GMT) Date: Wed, 16 Apr 2003 03:32:20 +0100 Subject: Re: Resolving geo discussions Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Sean Doran , multi6@ops.ietf.org To: "J. Noel Chiappa" From: Sean Doran In-Reply-To: <200304141559.h3EFx2Y3018328@ginger.lcs.mit.edu> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Noel - On Monday, Apr 14, 2003, at 16:59 Europe/London, J. Noel Chiappa wrote: > Also, this may lead ISP's to decide that they'd rather not support > exchanges, Too late. It has been many years since there has been any exchange in the world with anything close to universal participation. The paragraph at the end of your message is thus not imagination but clairvoyance. > since the customers are less locked-in No, there are bigger problems ranging from whether the exchange operator is vaguely competent now (let alone dealing with scale) to which of several local exchange operators you want to pay to connect to (they aren't charities, and they compete in places like London, Frankfurt and Paris), to which of my customers is really likely to announce the exchange-related address space in its entirety to me, given the trickiness of recovering the money they pay me for the traffic this attracts from their competitors who also attach to the exchange point. If you believe in customer lock-in, then you are so out of touch with the market in competitive places like Europe that I'd like to introduce you to several people who would love to sell you their phenomenally successful due to customer lock-in PA-address-using ISPs at low low extra value prices. :-) Site renumbering *is* a pain, but it's a pain a site might only have to do once or maybe twice annually, given typical transit contract lengths, and there are various ugly technologies that make the job easier. (If I mention NAT, though, I fear someone will seriously bruise his knees...) Back to your neck of the woods, i.e., market-free theory :-) -- what do you think of three axes to describe the problem we're looking at: the frequency of the start renumbering, the amount / clustering of renumbering things, and the time to complete the renumbering process? This could describe a site changing providers annually, a laptop switching between different wireless networks, or a "Schroedinger's network" that is 'stuck' in a long renumbering process that ends only when a network connection fails, and begins again when the connection recovers, among other things, and has been an interesting thinking instrument for me. Sean. From owner-multi6@ops.ietf.org Tue Apr 15 22:40:23 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20359 for ; Tue, 15 Apr 2003 22:40:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 195csY-000H1D-00 for multi6-data@psg.com; Wed, 16 Apr 2003 02:42:30 +0000 Received: from host217-37-202-105.in-addr.btopenworld.com ([217.37.202.105] helo=ab.use.net) by psg.com with esmtp (Exim 3.36 #1) id 195csC-000GyV-00 for multi6@ops.ietf.org; Wed, 16 Apr 2003 02:42:08 +0000 Received: from ab.use.net (conf.use.net [217.37.202.109]) by ab.use.net (Postfix) with ESMTP id 07B6939742; Wed, 16 Apr 2003 02:42:07 +0000 (GMT) Date: Wed, 16 Apr 2003 03:42:06 +0100 Subject: Re: Resolving geo discussions Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Sean Doran , multi6@ops.ietf.org, Jordi Palet To: Tim Chown From: Sean Doran In-Reply-To: <20030414141026.GO26424@login.ecs.soton.ac.uk> Message-Id: <0354A09A-6FB5-11D7-9ED5-0003938E4DE4@ab.use.net> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-19.4 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Monday, Apr 14, 2003, at 15:10 Europe/London, Tim Chown wrote: > Well, geography meets topology at an IX, Hmm... Except to the extent that the logical connection of distant physical things to IXes has been a common practise (and indeed, a popular product) for a number of years, and that the old practise of bridging together different physical locations into the same L2 LAN/LIS has not yet been abandoned... What were the geographical coordinates of MAE-WEST again? And there will be lots of interesting places with LINX addresses, I guess. :-) http://www.linx.net/members/index.thtml Sean. From owner-multi6@ops.ietf.org Tue Apr 15 22:52:49 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20642 for ; Tue, 15 Apr 2003 22:52:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 195d3z-000Hg4-00 for multi6-data@psg.com; Wed, 16 Apr 2003 02:54:19 +0000 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=SERVER2000.arneill-py.sacramento.ca.us) by psg.com with esmtp (Exim 3.36 #1) id 195d3d-000HdJ-00 for multi6@ops.ietf.org; Wed, 16 Apr 2003 02:53:57 +0000 Content-class: urn:content-classes:message Subject: RE: Resolving geo discussions Date: Tue, 15 Apr 2003 19:53:56 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Message-ID: <963621801C6D3E4A9CF454A1972AE8F504573C@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Thread-Topic: Resolving geo discussions thread-index: AcMDweXh0WgrZK+dS3Kms1lgyd3yeQAATcAg From: "Michel Py" To: "Sean Doran" Cc: X-Spam-Status: No, hits=-6.4 required=5.0 tests=BAYES_00 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id WAA20642 Wow, Sean Doran has come out of hibernation and is giving us a great deal of entertainment today. > Sean Doran wrote: > Site renumbering *is* a pain, but it's a pain a site might > only have to do once or maybe twice annually A site would renumber twice a year? Sean, go back to sleep. You are a disgrace to this ML. Michel. From owner-multi6@ops.ietf.org Tue Apr 15 23:09:00 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20998 for ; Tue, 15 Apr 2003 23:09:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 195dK3-000IZe-00 for multi6-data@psg.com; Wed, 16 Apr 2003 03:10:55 +0000 Received: from host217-37-202-105.in-addr.btopenworld.com ([217.37.202.105] helo=ab.use.net) by psg.com with esmtp (Exim 3.36 #1) id 195dJf-000IYv-00 for multi6@ops.ietf.org; Wed, 16 Apr 2003 03:10:32 +0000 Received: from ab.use.net (conf.use.net [217.37.202.109]) by ab.use.net (Postfix) with ESMTP id A0DD339742; Wed, 16 Apr 2003 03:10:30 +0000 (GMT) Date: Wed, 16 Apr 2003 04:10:30 +0100 Subject: Re: old GSE idea Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Sean Doran , Multi6 Working Group To: Peter Tattam From: Sean Doran In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Thursday, Apr 10, 2003, at 06:41 Europe/London, Peter Tattam wrote: > I wonder if some of it may be relevant to recent discussions. (you > might want > to ignore the junk about ARPing for routing id's - that probably won't > fly) > The relevant bit is the break up of the address bits. Apologies if it > resembles other drafts. No need to apologize. In general, the idea is that there is a bit of space that is free for the network to rewrite at will because it is not an end-to-end value. One way of looking at it is that it is a way of cooperating with NAT by way of a trade-off: sacrifice a part of the address for the network to adjust, and constrain the amount of work host developers need to do to accomodate their existence. There is probably a more p.c. way of putting this, but I am not the department of warm and fuzzy feelings. Personally, I like this approach because it's obviously workable today. However, I prefer at this point to consider the option of unifying the v4 and v6 Internet routing tables for operational reasons, at least for now. Perry Metzger and I had a friendly (well...) exchange about this on a public list some time ago (3-4 Dec 1999). The general idea is that leveraging off v4 experience and expertise is attractive to large operators and other in-the-core supporting organizations, and is acceptable to host-side and other at-the-edge folks because it needn't get in the way thanks to tunneling, 6to4 and the like. So, rather than maintain a routing system specific to GSE, as in your GSE+, why not just stuff a v4 address into the v6 one, such that the v4 address (for example) describes the decapsulation point of an IPv6-in-IPv4 tunnel? This doesn't seem to be prima facie at variance with your old idea, which correctly identifies an effective requirement for an "AFI"-like subfield in the higher-order bits of the v6 address in order to experiment with different routing and addressing semantics within the existing v6 address and header syntax. Sean. From owner-multi6@ops.ietf.org Tue Apr 15 23:14:12 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21055 for ; Tue, 15 Apr 2003 23:14:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 195dOz-000Ium-00 for multi6-data@psg.com; Wed, 16 Apr 2003 03:16:01 +0000 Received: from host217-37-202-105.in-addr.btopenworld.com ([217.37.202.105] helo=ab.use.net) by psg.com with esmtp (Exim 3.36 #1) id 195dOd-000IuP-00 for multi6@ops.ietf.org; Wed, 16 Apr 2003 03:15:39 +0000 Received: from ab.use.net (conf.use.net [217.37.202.109]) by ab.use.net (Postfix) with ESMTP id 6D4EA39742; Wed, 16 Apr 2003 03:15:37 +0000 (GMT) Date: Wed, 16 Apr 2003 04:15:36 +0100 Subject: Re: geo short vs long term? [Re: Geo pros and cons] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Sean Doran , multi6@ops.ietf.org To: Michael Richardson From: Sean Doran In-Reply-To: <200304081927.h38JRkXu026864@marajade.sandelman.ottawa.on.ca> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Tuesday, Apr 8, 2003, at 20:27 Europe/London, Michael Richardson wrote: > is there a multihoming solution within the constraints of our > requirements that we can > agree upon? > > This is a serious question. The only honest answer is: no, not yet. The problem is not exclusive to the "we can agree upon" part of your question, either. Sorry, Sean. (serious answer) From owner-multi6@ops.ietf.org Tue Apr 15 23:32:45 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21373 for ; Tue, 15 Apr 2003 23:32:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 195dgy-000Jzy-00 for multi6-data@psg.com; Wed, 16 Apr 2003 03:34:36 +0000 Received: from host217-37-202-105.in-addr.btopenworld.com ([217.37.202.105] helo=ab.use.net) by psg.com with esmtp (Exim 3.36 #1) id 195dgU-000Jyv-00 for multi6@ops.ietf.org; Wed, 16 Apr 2003 03:34:06 +0000 Received: from ab.use.net (conf.use.net [217.37.202.109]) by ab.use.net (Postfix) with ESMTP id D04EC39742; Wed, 16 Apr 2003 03:34:04 +0000 (GMT) Date: Wed, 16 Apr 2003 04:34:04 +0100 Subject: Re: geo short vs long term? [Re: Geo pros and cons] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Sean Doran , Joe Abley , multi6@ops.ietf.org To: Randy Bush From: Sean Doran In-Reply-To: Message-Id: <45AB6F48-6FBC-11D7-9ED5-0003938E4DE4@ab.use.net> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Sunday, Apr 6, 2003, at 04:00 Europe/London, Randy Bush wrote: > if you don't count the oceanic island nations, se asia, ... all of > which backhaul a long way. net topology is extremely different > from geography. this repeating idea of geographic aggregation > simply ignores reality. Standing in my building does not give you the right to expect me to deliver packets to you. If your GPRS operator gives you an address related to my building's physical location, and packets arrive via my immediate provider to me for that address, rather than to you through your GSM operator, I will drop them on the floor, even though *in principle* I could deliver them to you via, say, wavelan, or a 100baseTX port. (I don't really want you on my network though; I have more business-productive things to pay for than the porn you're surfing while in my lobby, never mind security issues...) Your GPRS operator, therefore, will have to give you addresses that are unrelated to my building's physical location, even when you're standing in it. If we ever have a "visitor" network, you can bet that those packets will cross only the public Internet, not my corporate WAN. You'll get public IP addresses rather than internal (and mostly 1918) ones, because you will only be allowed to connect to the visitor wireless LAN (or the visitor 100baseTX plug) no matter what desk you put your laptop upon, even if it's mine. Sean. From owner-multi6@ops.ietf.org Wed Apr 16 00:07:10 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22014 for ; Wed, 16 Apr 2003 00:07:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 195eDt-000M9k-00 for multi6-data@psg.com; Wed, 16 Apr 2003 04:08:37 +0000 Received: from host217-37-202-105.in-addr.btopenworld.com ([217.37.202.105] helo=ab.use.net) by psg.com with esmtp (Exim 3.36 #1) id 195eDV-000M8x-00 for multi6@ops.ietf.org; Wed, 16 Apr 2003 04:08:14 +0000 Received: from ab.use.net (conf.use.net [217.37.202.109]) by ab.use.net (Postfix) with ESMTP id 567E539742; Wed, 16 Apr 2003 04:08:12 +0000 (GMT) Date: Wed, 16 Apr 2003 05:08:11 +0100 Subject: Re: geo short vs long term? [Re: Geo pros and cons] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Sean Doran , Randy Bush , Joe Abley , multi6@ops.ietf.org To: Iljitsch van Beijnum From: Sean Doran In-Reply-To: Message-Id: <0A0CA024-6FC1-11D7-9ED5-0003938E4DE4@ab.use.net> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Sunday, Apr 6, 2003, at 10:27 Europe/London, Iljitsch van Beijnum wrote: > The idea behind geographic addressing is not that the topology and > addressing become interchangable. The simple fact that a multihomer > connects to the net in two places makes this impossible by definition. No, this is not true, unless you insist a multihomer only ever uses one address to fit a constrained L2 topology. Multi-address-with-existing-v6-semantics and multi-address-using-GSE-or-other-split-I/L approaches both preserve the direct relationship between topology and address or locator. MPLS/2547 and other line, cloud and lan virtualizations ("liberate your Internet traffic from the tyranny of physical infrastructure!") likewise, only the other way around: they can adjust topology to fit existing addresses. > The point is that it becomes possible to draw lines on the map in such > a way that aggregating routing information that crosses these lines > gets rid of enough routing information that the savings in routing > table size are worth the effort. > > For this purpose, it is irrelevant that the aggregation circle with > Singapore in the middle may also include Palo Alto and LA. That still > gets rid of Asia/Pacific more specifics in most of the US and the rest > of the world. And even if some Asian networks connect to other places, > this only breaks aggregation for these specific networks. > > Maybe the savings aren't that big. The savings are enormous. Aggregating the entire western hemisphere behind a single prefix would be wonderful. (I propose using existing Sprint address space.) However you are overlooking the fact that there are costs too (on top of the monopoly rent I will gladly extract from hundreds of millions of people like you, who will deliver all your North American traffic only to me). In particular, should connectivity between me and something covered by my single prefix fail, you and everyone else in the eastern hemisphere will not know this -- not a really problem, except for the cases where there are longer paths available which still work. I suggest that aggressive regulation will constrain this problem, so engineers need not think about the dissolution of abstraction boundaries, and other things that go bump in the night. Massive spending on local redundancy and resiliency is the correct answer. The industry's approach -- connecting to more than one provider -- is fundamentally a bad idea. Fortunately, gentle guidance will resolve this surprising failure of the market, and lead to a more stable and reliable Internet for everyone. > But then again, the effort isn't all that huge either: the RIRs need > to implement a tool that allows local internet registries (ISPs) to > give out geography-based /48s to multihomers. That's all. My approach is even easier. "No, you can't have an address, unless you get it from Sprint". This requires no new tools (they have already deployed the vacation program and procmail), and offers ARIN a considerable opportunity for staff reduction. I also think it's cheaper to pay me obscene one-provider charges in a few years than it will be to deal with a routing system with a hundred thousand residentially multihoming /48s in each of hundreds of major cities. My neighbours, oddly enough, use different providers than I do, so their providers would have to know about my /48, and mine theirs, and no aggregation is possible for this immediate area for any set of providers operating within the closest abstraction/aggregation boundary. This is not atypical, in my experience, and boundary pressure is likely to force a trade-off between leaking global exceptions and increasing local state. Sigh. I wish I were the One True Monopoly. You should too: there'd be less of this sort of email. Try working on SAPI: "Sean-Assigned Public Internet addresses". That'd be much cooler. Sean. From owner-multi6@ops.ietf.org Wed Apr 16 00:28:24 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22435 for ; Wed, 16 Apr 2003 00:28:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 195eYs-000Ncu-00 for multi6-data@psg.com; Wed, 16 Apr 2003 04:30:18 +0000 Received: from host217-37-202-105.in-addr.btopenworld.com ([217.37.202.105] helo=ab.use.net) by psg.com with esmtp (Exim 3.36 #1) id 195eYW-000NYw-00 for multi6@ops.ietf.org; Wed, 16 Apr 2003 04:29:56 +0000 Received: from ab.use.net (conf.use.net [217.37.202.109]) by ab.use.net (Postfix) with ESMTP id 975D039742; Wed, 16 Apr 2003 04:29:54 +0000 (GMT) Date: Wed, 16 Apr 2003 05:29:54 +0100 Subject: Re: Resolving geo discussions Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Sean Doran , To: "Michel Py" From: Sean Doran In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F504573C@server2000.arneill-py.sacramento.ca.us> Message-Id: <1238CAE0-6FC4-11D7-9ED5-0003938E4DE4@ab.use.net> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-19.2 required=5.0 tests=BAYES_00,EMAIL_ATTRIBUTION,IN_REP_TO,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wednesday, Apr 16, 2003, at 03:53 Europe/London, Michel Py wrote: > A site would renumber twice a year? > > Sean, go back to sleep. You are a disgrace to this ML. Why? Because I meet in the market place enterprises which deploy NATs explicitly to facilitate exactly this? Prices are falling. People want short-term contracts with few strings. I apologize for uttering this horrifically disgraceful statement, and will comply with your wish, if there is rough consensus from the rest of the WG. Sean. From owner-multi6@ops.ietf.org Wed Apr 16 03:47:56 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21525 for ; Wed, 16 Apr 2003 03:47:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 195heN-0008mr-00 for multi6-data@psg.com; Wed, 16 Apr 2003 07:48:11 +0000 Received: from d12lmsgate-5.de.ibm.com ([194.196.100.238]) by psg.com with esmtp (Exim 3.36 #1) id 195hdk-0008m8-00 for multi6@ops.ietf.org; Wed, 16 Apr 2003 07:47:32 +0000 Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-5.de.ibm.com (8.12.9/8.12.8) with ESMTP id h3G7lOju076372 for ; Wed, 16 Apr 2003 09:47:24 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.de.ibm.com (8.12.8/NCO/VER6.5) with SMTP id h3G7lLRB247870 for ; Wed, 16 Apr 2003 09:47:22 +0200 Received: from dhcp21-82.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA51784 from ; Wed, 16 Apr 2003 09:47:19 +0200 Message-Id: <3E9D0AB1.3C95DA91@hursley.ibm.com> Date: Wed, 16 Apr 2003 09:48:01 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: multi6@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-multi6-multihoming-requirements-04.txt References: <200304071110.HAA15004@ietf.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-16.9 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I think this is about ready to ship. Just a few points, essentially editorial except for the very last one. > Abstract > > Site-multihoming, i.e. connecting to more than one IP service > provider, is an essential component of service for many sites which > are part of the Internet. Existing IPv4 site-multihoming practices > provide a set of capabilities that it would ideally be accommodated > by the adopted site-multihoming architecture in IPv6, and a set of > limitations that must be overcome, relating in particular to > scalability. The second sentence is very hard to understand, contains at least one grammatical error, and distracts from the main message. I would simply delete it. ... > 3.2.2 Impact on Routers > > The solution may require changes to IPv6 router implementations, but > these changes must be either minor, or in the form of logically s/must/should/ > separate functions added to existing functions. > > Such changes should not prevent normal single-homed operation, and > routers implementing these changes must be able to interoperate fully s/must/should/ > with hosts and routers not implementing them. > > 3.2.3 Impact on Hosts > > The solution should not destroy IPv6 connectivity for a legacy host > implementing RFC 2373 [3], RFC 2460 [5], RFC 2553 [6] and other basic s/2373/3513/ > IPv6 specifications current in November 2001. That is to say, if a s/November 2001/April 2003/ > host can work in a single-homed site, it must still be able to work s/must/should/ > in a multihomed site, even if it cannot benefit from > site-multihoming. > > It would be compatible with this requirement for such a host to lose s/requirement/goal/ > connectivity if a site lost connectivity to one transit provider, > despite the fact that other transit provider connections were still > operational. ... > 3.2.7 Multiple Solutions > > There may be more than one approach to multihoming, provided all > approaches are orthogonal (e.g. each approach addresses a distinct s/(e.g./i.e./ > segment or category within the site multihoming problem. Multiple > solutions will incur a greater management overhead, however, and the > adopted solutions SHOULD attempt to cover as many multihoming s/SHOULD/should/ > scenarios as possible. s/scenarios/scenarios and goals/ > > 4. Security Considerations > > A multihomed site should not be more vulnerable to security breaches > than a traditionally IPv4-multihomed site. Should we add "or a single-homed IPv6 site"? Brian From owner-multi6@ops.ietf.org Wed Apr 16 04:03:07 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21759 for ; Wed, 16 Apr 2003 04:03:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 195htm-0009AN-00 for multi6-data@psg.com; Wed, 16 Apr 2003 08:04:06 +0000 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 195htG-000999-00; Wed, 16 Apr 2003 08:03:34 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h3G82OE61174; Wed, 16 Apr 2003 10:02:24 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Wed, 16 Apr 2003 10:02:14 +0200 Subject: Re: geo short vs long term? [Re: Geo pros and cons] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Randy Bush , Joe Abley , multi6@ops.ietf.org To: Sean Doran From: Iljitsch van Beijnum In-Reply-To: <0A0CA024-6FC1-11D7-9ED5-0003938E4DE4@ab.use.net> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On woensdag, apr 16, 2003, at 06:08 Europe/Amsterdam, Sean Doran wrote: >> The idea behind geographic addressing is not that the topology and >> addressing become interchangable. The simple fact that a multihomer >> connects to the net in two places makes this impossible by >> definition. > No, this is not true, unless you insist a multihomer only ever uses > one address > to fit a constrained L2 topology. You really have been in hibernation, haven't you? Constrained L4 architecture, anyone? Multiaddressing needs a huge amount of work before it can catch up with the level of functionality provided by today's routing-based approaches. That's why we're still discussing the routing stuff, even though we know it has inherent scalability problems. >> The point is that it becomes possible to draw lines on the map in >> such a way that aggregating routing information that crosses these >> lines gets rid of enough routing information that the savings in >> routing table size are worth the effort. [...] >> Maybe the savings aren't that big. > The savings are enormous. Aggregating the entire western hemisphere > behind > a single prefix would be wonderful. (I propose using existing Sprint > address space.) Ok, here you cross the line between being purposefully ignorant and being offensive. I think your comments here disqualify you as chair of this wg, and I am asking you here and now to step back and let someone else, who can take all of this seriously, take over. > However you are overlooking the fact that there are costs too (on top > of the > monopoly rent I will gladly extract from hundreds of millions of > people like you, who will deliver all your North American traffic only > to me). Ha ha. Is this the way the IETF is supposed to work? People volunteer many hours of work only to be mocked? Didn't you even read the *title* of my draft? "Provider-_I_n_t_e_r_n_a_l_ Aggregation based on Geography to Support Multihoming in IPv6" > Massive spending on local redundancy and resiliency is the correct > answer. > The industry's approach -- connecting to more than one provider -- is > fundamentally a bad idea. So you agree you have no business chairing a _multihoming_ in IPv6 wg? Two final quotes for those of you still reading: > My approach is even easier. "No, you can't have an address, unless > you get it from Sprint". > Try working on SAPI: "Sean-Assigned Public Internet addresses". > That'd be much cooler. Iljitsch van Beijnum From owner-multi6@ops.ietf.org Wed Apr 16 04:08:38 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21947 for ; Wed, 16 Apr 2003 04:08:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 195i04-0009L1-00 for multi6-data@psg.com; Wed, 16 Apr 2003 08:10:36 +0000 Received: from dmz2.procket.com ([65.174.124.37]) by psg.com with esmtp (Exim 3.36 #1) id 195hzj-0009KS-00 for multi6@ops.ietf.org; Wed, 16 Apr 2003 08:10:15 +0000 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id D179C34447; Wed, 16 Apr 2003 00:23:56 -0700 (PDT) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h3G8A8YB010169; Wed, 16 Apr 2003 01:10:08 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Resolving geo discussions Date: Wed, 16 Apr 2003 01:10:07 -0700 Message-ID: Thread-Topic: Resolving geo discussions Thread-Index: AcMD1UGwofeQaoqhTTGF7IYvOt21KAAGkGeQ From: "Tony Li" To: "Sean Doran" , "Michel Py" Cc: X-Spam-Status: No, hits=-6.6 required=5.0 tests=BAYES_01 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA21947 Nay. And the ad hominem remarks are out of place here. Tony | -----Original Message----- | From: Sean Doran [mailto:smd@ab.use.net] | Sent: Tuesday, April 15, 2003 9:30 PM | To: Michel Py | Cc: Sean Doran; multi6@ops.ietf.org | Subject: Re: Resolving geo discussions | | | | On Wednesday, Apr 16, 2003, at 03:53 Europe/London, Michel | Py wrote: | | > A site would renumber twice a year? | > | > Sean, go back to sleep. You are a disgrace to this ML. | | Why? Because I meet in the market place enterprises | which deploy NATs explicitly to facilitate exactly this? | | Prices are falling. People want short-term contracts with | few strings. | | I apologize for uttering this horrifically disgraceful statement, | and will comply with your wish, if there is rough consensus from | the rest of the WG. | | Sean. | | | From owner-multi6@ops.ietf.org Wed Apr 16 08:57:46 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29121 for ; Wed, 16 Apr 2003 08:57:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 195mRp-000JNu-00 for multi6-data@psg.com; Wed, 16 Apr 2003 12:55:33 +0000 Received: from host217-37-202-105.in-addr.btopenworld.com ([217.37.202.105] helo=ab.use.net) by psg.com with esmtp (Exim 3.36 #1) id 195mRJ-000JLa-00 for multi6@ops.ietf.org; Wed, 16 Apr 2003 12:55:01 +0000 Received: from ab.use.net (conf.use.net [217.37.202.109]) by ab.use.net (Postfix) with ESMTP id 2267B39742; Wed, 16 Apr 2003 12:54:59 +0000 (GMT) Date: Wed, 16 Apr 2003 13:54:58 +0100 Subject: Re: I-D ACTION:draft-ietf-multi6-multihoming-requirements-04.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Sean Doran , multi6@ops.ietf.org To: Brian E Carpenter From: Sean Doran In-Reply-To: <3E9D0AB1.3C95DA91@hursley.ibm.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wednesday, Apr 16, 2003, at 08:48 Europe/London, Brian E Carpenter wrote: >> 4. Security Considerations >> >> A multihomed site should not be more vulnerable to security >> breaches >> than a traditionally IPv4-multihomed site. > > Should we add "or a single-homed IPv6 site"? Site multihoming has costs. One of the obvious possible side-effects of being multihomed is an increase in potential vulnerabilities. I would prefer to see them documented than precluded (the known space in which a solution may be found is already too small) or denied. I think the goal of being no worse for a site than multihoming using IPv4 is admirable and at least mostly tractable. Sean. From owner-multi6@ops.ietf.org Wed Apr 16 09:09:44 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29763 for ; Wed, 16 Apr 2003 09:09:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 195mhB-000KGA-00 for multi6-data@psg.com; Wed, 16 Apr 2003 13:11:25 +0000 Received: from host217-37-202-105.in-addr.btopenworld.com ([217.37.202.105] helo=ab.use.net) by psg.com with esmtp (Exim 3.36 #1) id 195mgf-000KEU-00 for multi6@ops.ietf.org; Wed, 16 Apr 2003 13:10:53 +0000 Received: from ab.use.net (conf.use.net [217.37.202.109]) by ab.use.net (Postfix) with ESMTP id 891B339742; Wed, 16 Apr 2003 13:10:51 +0000 (GMT) Date: Wed, 16 Apr 2003 14:10:51 +0100 Subject: Re: geo short vs long term? [Re: Geo pros and cons] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Sean Doran , Randy Bush , Joe Abley , multi6@ops.ietf.org To: Iljitsch van Beijnum From: Sean Doran In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wednesday, Apr 16, 2003, at 09:02 Europe/London, Iljitsch van Beijnum wrote: > Constrained L4 architecture, anyone? Multiaddressing needs a huge > amount of work before it can catch up with the level of functionality > provided by today's routing-based approaches. That's why we're still > discussing the routing stuff, even though we know it has inherent > scalability problems. Do you think the WG could arrive at a consensus on exactly these points? That is: multi6 could, if there was agreement, document that the L4 architecture as it stands now is in the way of considering solutions which we do not at present "know ... has inherent scalability problems". I happen to favour such a recognition/admission of the problem. Whether this would trigger useful reactions outside multi6 is a point which interests me enormously. > Ok, here you cross the line between being purposefully ignorant and > being offensive. I think your comments here disqualify you as chair of > this wg, and I am asking you here and now to step back and let someone > else, who can take all of this seriously, take over. I would seriously appreciate it if someone would volunteer himself or herself to the ADs so that I am freer to address (apologies for the pun) many of the discussions here in a much more me-like fashion. Sean. From owner-multi6@ops.ietf.org Wed Apr 16 09:38:42 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00870 for ; Wed, 16 Apr 2003 09:38:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 195n98-000M70-00 for multi6-data@psg.com; Wed, 16 Apr 2003 13:40:18 +0000 Received: from buffoon.automagic.org ([208.185.30.208]) by psg.com with smtp (Exim 3.36 #1) id 195n8a-000M2X-00 for multi6@ops.ietf.org; Wed, 16 Apr 2003 13:39:44 +0000 Received: (qmail 42760 invoked by uid 0); 16 Apr 2003 13:39:42 -0000 Received: from localhost.automagic.org (HELO isc.org) (root@127.0.0.1) by localhost.automagic.org with SMTP; 16 Apr 2003 13:39:42 -0000 Date: Wed, 16 Apr 2003 09:39:55 -0400 Subject: Re: I-D ACTION:draft-ietf-multi6-multihoming-requirements-04.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: Brian E Carpenter From: Joe Abley In-Reply-To: <3E9D0AB1.3C95DA91@hursley.ibm.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wednesday, Apr 16, 2003, at 03:48 Canada/Eastern, Brian E Carpenter wrote: > I think this is about ready to ship. Just a few points, essentially > editorial except for the very last one. > >> Abstract >> >> Site-multihoming, i.e. connecting to more than one IP service >> provider, is an essential component of service for many sites which >> are part of the Internet. Existing IPv4 site-multihoming practices >> provide a set of capabilities that it would ideally be accommodated >> by the adopted site-multihoming architecture in IPv6, and a set of >> limitations that must be overcome, relating in particular to >> scalability. > > The second sentence is very hard to understand, contains at least one > grammatical error, and distracts from the main message. I would simply > delete it. Very happy to do so, and I apologise for my hideous wordcrime. > ... >> 3.2.2 Impact on Routers >> >> The solution may require changes to IPv6 router implementations, >> but >> these changes must be either minor, or in the form of logically > s/must/should/ fixed >> separate functions added to existing functions. >> >> Such changes should not prevent normal single-homed operation, and >> routers implementing these changes must be able to interoperate >> fully > s/must/should/ fixed >> with hosts and routers not implementing them. >> >> 3.2.3 Impact on Hosts >> >> The solution should not destroy IPv6 connectivity for a legacy host >> implementing RFC 2373 [3], RFC 2460 [5], RFC 2553 [6] and other >> basic > s/2373/3513/ fixed >> IPv6 specifications current in November 2001. That is to say, if a > s/November 2001/April 2003/ fixed already >> host can work in a single-homed site, it must still be able to work > s/must/should/ fixed >> in a multihomed site, even if it cannot benefit from >> site-multihoming. >> >> It would be compatible with this requirement for such a host to >> lose > s/requirement/goal/ fixed >> connectivity if a site lost connectivity to one transit provider, >> despite the fact that other transit provider connections were still >> operational. > > ... > >> 3.2.7 Multiple Solutions >> >> There may be more than one approach to multihoming, provided all >> approaches are orthogonal (e.g. each approach addresses a distinct > s/(e.g./i.e./ Arrgh, fixed. >> segment or category within the site multihoming problem. Multiple >> solutions will incur a greater management overhead, however, and >> the >> adopted solutions SHOULD attempt to cover as many multihoming > s/SHOULD/should/ fixed >> scenarios as possible. > s/scenarios/scenarios and goals/ good idea >> >> 4. Security Considerations >> >> A multihomed site should not be more vulnerable to security >> breaches >> than a traditionally IPv4-multihomed site. > > Should we add "or a single-homed IPv6 site"? Is that reasonable? Or does the addition of an entry-point to a single-homed site make it inherently more vulnerable, in some small way? In response to some other private feedback, I also added the following sentence to the security section: Any changes to routing practices made to accommodate multihomed sites should not cause non-multihomed sites to become more vulnerable to security breaches. Comments on that would be appreciated. Thanks, Brian. Joe From owner-multi6@ops.ietf.org Wed Apr 16 09:39:16 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00895 for ; Wed, 16 Apr 2003 09:39:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 195n9g-000M8K-00 for multi6-data@psg.com; Wed, 16 Apr 2003 13:40:52 +0000 Received: from d12lmsgate-4.de.ibm.com ([194.196.100.237]) by psg.com with esmtp (Exim 3.36 #1) id 195n8m-000M31-00 for multi6@ops.ietf.org; Wed, 16 Apr 2003 13:39:57 +0000 Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-4.de.ibm.com (8.12.9/8.12.8) with ESMTP id h3GDdkDI020422 for ; Wed, 16 Apr 2003 15:39:51 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.de.ibm.com (8.12.8/NCO/VER6.5) with SMTP id h3GDdURB154758 for ; Wed, 16 Apr 2003 15:39:36 +0200 Received: from dhcp21-82.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA57714 from ; Wed, 16 Apr 2003 15:39:26 +0200 Message-Id: <3E9D5D38.A6711638@hursley.ibm.com> Date: Wed, 16 Apr 2003 15:40:08 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Multi6 Working Group Subject: Re: old GSE idea References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-29.3 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I think we should fly up one level and discuss a hypothetical world in which addresses in A000::/3 are deemed to be mutable in flight between bits 3 and 47 inclusive. See what it does to TCP, SCTP and IPSEC for example. Then fly down again and look at the idea of doing GSE within A000::/3. Brian Sean Doran wrote: > > On Thursday, Apr 10, 2003, at 06:41 Europe/London, Peter Tattam wrote: > > > I wonder if some of it may be relevant to recent discussions. (you > > might want > > to ignore the junk about ARPing for routing id's - that probably won't > > fly) > > The relevant bit is the break up of the address bits. Apologies if it > > resembles other drafts. > > No need to apologize. > > In general, the idea is that there is a bit of space that is free for > the > network to rewrite at will because it is not an end-to-end value. > One way of looking at it is that it is a way of cooperating with NAT > by way of a trade-off: sacrifice a part of the address for the network > to adjust, and constrain the amount of work host developers need to do > to accomodate their existence. There is probably a more p.c. way > of putting this, but I am not the department of warm and fuzzy feelings. > > Personally, I like this approach because it's obviously workable today. > However, I prefer at this point to consider the option of unifying the > v4 and v6 Internet routing tables for operational reasons, at least for > now. > Perry Metzger and I had a friendly (well...) exchange about this on > a public list some time ago (3-4 Dec 1999). The general idea is that > leveraging off v4 experience and expertise is attractive to large > operators > and other in-the-core supporting organizations, and is acceptable > to host-side and other at-the-edge folks because it needn't get in the > way > thanks to tunneling, 6to4 and the like. > > So, rather than maintain a routing system specific to GSE, as in your > GSE+, > why not just stuff a v4 address into the v6 one, such that the v4 > address > (for example) describes the decapsulation point of an IPv6-in-IPv4 > tunnel? > > This doesn't seem to be prima facie at variance with your old idea, > which > correctly identifies an effective requirement for an "AFI"-like > subfield in the > higher-order bits of the v6 address in order to experiment with > different > routing and addressing semantics within the existing v6 address and > header syntax. > > Sean. -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment at the IBM Zurich Laboratory, Switzerland From owner-multi6@ops.ietf.org Wed Apr 16 09:48:34 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01110 for ; Wed, 16 Apr 2003 09:48:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 195nIu-000Ml9-00 for multi6-data@psg.com; Wed, 16 Apr 2003 13:50:24 +0000 Received: from d12lmsgate-3.de.ibm.com ([194.196.100.236]) by psg.com with esmtp (Exim 3.36 #1) id 195nIG-000Mgf-00 for multi6@ops.ietf.org; Wed, 16 Apr 2003 13:49:44 +0000 Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (8.12.9/8.12.8) with ESMTP id h3GDmwCi111470; Wed, 16 Apr 2003 15:49:12 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.de.ibm.com (8.12.8/NCO/VER6.5) with SMTP id h3GDmrRB268348; Wed, 16 Apr 2003 15:48:54 +0200 Received: from dhcp21-82.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA26074 from ; Wed, 16 Apr 2003 15:48:48 +0200 Message-Id: <3E9D5F6A.85F93206@hursley.ibm.com> Date: Wed, 16 Apr 2003 15:49:30 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Tony Li Cc: Sean Doran , Michel Py , multi6@ops.ietf.org Subject: Re: Resolving geo discussions References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-29.3 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I agree. Actually I am hoping to see more from the co-chairs, not less. Now seriously about renumbering, it is something that IPv6 facilitates, but we still haven't taken the sting out of it, and that is a challenge yet to be solved. Not in this WG though. Brian Tony Li wrote: > > Nay. And the ad hominem remarks are out of place here. > > Tony > > | -----Original Message----- > | From: Sean Doran [mailto:smd@ab.use.net] > | Sent: Tuesday, April 15, 2003 9:30 PM > | To: Michel Py > | Cc: Sean Doran; multi6@ops.ietf.org > | Subject: Re: Resolving geo discussions > | > | > | > | On Wednesday, Apr 16, 2003, at 03:53 Europe/London, Michel > | Py wrote: > | > | > A site would renumber twice a year? > | > > | > Sean, go back to sleep. You are a disgrace to this ML. > | > | Why? Because I meet in the market place enterprises > | which deploy NATs explicitly to facilitate exactly this? > | > | Prices are falling. People want short-term contracts with > | few strings. > | > | I apologize for uttering this horrifically disgraceful statement, > | and will comply with your wish, if there is rough consensus from > | the rest of the WG. > | > | Sean. From owner-multi6@ops.ietf.org Wed Apr 16 10:24:23 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03250 for ; Wed, 16 Apr 2003 10:24:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 195nqc-000OpP-00 for multi6-data@psg.com; Wed, 16 Apr 2003 14:25:14 +0000 Received: from mailout.zma.compaq.com ([161.114.64.104] helo=zmamail04.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 195nqF-000Onv-00 for multi6@ops.ietf.org; Wed, 16 Apr 2003 14:24:51 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 88017732A; Wed, 16 Apr 2003 10:24:50 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 16 Apr 2003 10:24:50 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: old GSE idea Date: Wed, 16 Apr 2003 10:24:49 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03ABD295@tayexc13.americas.cpqcorp.net> Thread-Topic: old GSE idea Thread-Index: AcMEIxFcMOOGMkiYSteQMR8PyJHwtAAANkcg From: "Bound, Jim" To: "Brian E Carpenter" , "Multi6 Working Group" X-OriginalArrivalTime: 16 Apr 2003 14:24:50.0250 (UTC) FILETIME=[F08ACAA0:01C30423] X-Spam-Status: No, hits=-9.8 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA03250 Sounds like good exercise to me. /jim > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: Wednesday, April 16, 2003 9:40 AM > To: Multi6 Working Group > Subject: Re: old GSE idea > > > I think we should fly up one level and discuss a hypothetical > world in which addresses in A000::/3 are deemed to be mutable > in flight between bits 3 and 47 inclusive. See what it does > to TCP, SCTP and IPSEC for example. Then fly down again and look > at the idea of doing GSE within A000::/3. > > Brian > > Sean Doran wrote: > > > > On Thursday, Apr 10, 2003, at 06:41 Europe/London, Peter > Tattam wrote: > > > > > I wonder if some of it may be relevant to recent > discussions. (you > > > might want to ignore the junk about ARPing for routing > id's - that > > > probably won't > > > fly) > > > The relevant bit is the break up of the address bits. > Apologies if > > > it resembles other drafts. > > > > No need to apologize. > > > > In general, the idea is that there is a bit of space that > is free for > > the network to rewrite at will because it is not an > end-to-end value. > > One way of looking at it is that it is a way of cooperating with NAT > > by way of a trade-off: sacrifice a part of the address for > the network > > to adjust, and constrain the amount of work host developers > need to do > > to accomodate their existence. There is probably a more p.c. way > > of putting this, but I am not the department of warm and > fuzzy feelings. > > > > Personally, I like this approach because it's obviously workable > > today. However, I prefer at this point to consider the option of > > unifying the v4 and v6 Internet routing tables for operational > > reasons, at least for now. Perry Metzger and I had a friendly > > (well...) exchange about this on a public list some time > ago (3-4 Dec > > 1999). The general idea is that leveraging off v4 experience and > > expertise is attractive to large operators > > and other in-the-core supporting organizations, and is acceptable > > to host-side and other at-the-edge folks because it needn't > get in the > > way > > thanks to tunneling, 6to4 and the like. > > > > So, rather than maintain a routing system specific to GSE, > as in your > > GSE+, > > why not just stuff a v4 address into the v6 one, such that the v4 > > address (for example) describes the decapsulation point of an > > IPv6-in-IPv4 tunnel? > > > > This doesn't seem to be prima facie at variance with your old idea, > > which correctly identifies an effective requirement for an > "AFI"-like > > subfield in the > > higher-order bits of the v6 address in order to experiment with > > different > > routing and addressing semantics within the existing v6 address and > > header syntax. > > > > Sean. > > -- > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > - - Brian E Carpenter > Distinguished Engineer, Internet Standards & Technology, IBM > On assignment at the IBM Zurich Laboratory, Switzerland > > From owner-multi6@ops.ietf.org Wed Apr 16 10:52:56 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04459 for ; Wed, 16 Apr 2003 10:52:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 195oJE-000Pj4-00 for multi6-data@psg.com; Wed, 16 Apr 2003 14:54:48 +0000 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 195oIs-000Pia-00 for multi6@ops.ietf.org; Wed, 16 Apr 2003 14:54:26 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h3GErHE61773; Wed, 16 Apr 2003 16:53:17 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Wed, 16 Apr 2003 16:53:08 +0200 Subject: Re: old GSE idea Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Multi6 Working Group To: Brian E Carpenter From: Iljitsch van Beijnum In-Reply-To: <3E9D5D38.A6711638@hursley.ibm.com> Message-Id: <22EB296A-701B-11D7-B238-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On woensdag, apr 16, 2003, at 15:40 Europe/Amsterdam, Brian E Carpenter wrote: > I think we should fly up one level and discuss a hypothetical > world in which addresses in A000::/3 are deemed to be mutable > in flight between bits 3 and 47 inclusive. See what it does > to TCP, SCTP and IPSEC for example. Well, break them... The TCP/UDP checksum should be easy enough to fix, IPsec AH not much harder. The real problem is that if I have a session with a001::1 and suddenly packets start coming in from a002::1, how do I know these belong to the same session? This can be fixed by making the bottom 64/80 bits should be globally unique, or by informing the other side of all possible values that may appear in those 45 bits beforehand. As long as we're flying up levels, why not go up one more and compare different multiple-PA approaches? From owner-multi6@ops.ietf.org Wed Apr 16 10:53:24 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04482 for ; Wed, 16 Apr 2003 10:53:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 195oJc-000PlP-00 for multi6-data@psg.com; Wed, 16 Apr 2003 14:55:12 +0000 Received: from d12lmsgate-2.de.ibm.com ([194.196.100.235]) by psg.com with esmtp (Exim 3.36 #1) id 195oJ0-000Pik-00 for multi6@ops.ietf.org; Wed, 16 Apr 2003 14:54:34 +0000 Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (8.12.9/8.12.8) with ESMTP id h3GEsRUm058892; Wed, 16 Apr 2003 16:54:29 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.de.ibm.com (8.12.8/NCO/VER6.5) with SMTP id h3GEsOMM267280; Wed, 16 Apr 2003 16:54:26 +0200 Received: from dhcp21-82.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA35654 from ; Wed, 16 Apr 2003 16:54:23 +0200 Message-Id: <3E9D6EC8.FD2C6051@hursley.ibm.com> Date: Wed, 16 Apr 2003 16:55:04 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Joe Abley Cc: multi6@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-multi6-multihoming-requirements-04.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-16.3 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Joe Abley wrote: ... > >> > >> 4. Security Considerations > >> > >> A multihomed site should not be more vulnerable to security > >> breaches > >> than a traditionally IPv4-multihomed site. > > > > Should we add "or a single-homed IPv6 site"? > > Is that reasonable? Or does the addition of an entry-point to a > single-homed site make it inherently more vulnerable, in some small way? > > In response to some other private feedback, I also added the following > sentence to the security section: > > Any changes to routing practices made to accommodate multihomed > sites should not cause non-multihomed sites to become more > vulnerable to security breaches. > > Comments on that would be appreciated. I think that is good. I'll certainly concede to you and Sean on my own suggestion, but I fear we will get pushback from the IESG if we produce a solution that does weaken security. Brian From owner-multi6@ops.ietf.org Wed Apr 16 11:03:20 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04889 for ; Wed, 16 Apr 2003 11:03:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 195oTA-00004Q-00 for multi6-data@psg.com; Wed, 16 Apr 2003 15:05:04 +0000 Received: from d12lmsgate.de.ibm.com ([194.196.100.234]) by psg.com with esmtp (Exim 3.36 #1) id 195oSP-00001t-00 for multi6@ops.ietf.org; Wed, 16 Apr 2003 15:04:18 +0000 Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (8.12.9/8.12.8) with ESMTP id h3GF49u9092790; Wed, 16 Apr 2003 17:04:09 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.de.ibm.com (8.12.8/NCO/VER6.5) with SMTP id h3GF47RB260968; Wed, 16 Apr 2003 17:04:08 +0200 Received: from dhcp21-82.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA44938 from ; Wed, 16 Apr 2003 17:04:04 +0200 Message-Id: <3E9D710F.50523C1D@hursley.ibm.com> Date: Wed, 16 Apr 2003 17:04:47 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Iljitsch van Beijnum Cc: Multi6 Working Group Subject: Re: old GSE idea References: <22EB296A-701B-11D7-B238-00039388672E@muada.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-29.3 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Actually the requirement isn't that the bottom 80 bits be globally unique, but that they be mutually unique among the set of hosts involved (which may of course be more than two, due to referrals). I don't know if that constraint is easier to meet. Some would say that the answer to your question is HIP. I do agree we should agree on a systematic breakdown and comparison of approaches. Brian Iljitsch van Beijnum wrote: > > On woensdag, apr 16, 2003, at 15:40 Europe/Amsterdam, Brian E Carpenter > wrote: > > > I think we should fly up one level and discuss a hypothetical > > world in which addresses in A000::/3 are deemed to be mutable > > in flight between bits 3 and 47 inclusive. See what it does > > to TCP, SCTP and IPSEC for example. > > Well, break them... The TCP/UDP checksum should be easy enough to fix, > IPsec AH not much harder. The real problem is that if I have a session > with a001::1 and suddenly packets start coming in from a002::1, how do > I know these belong to the same session? This can be fixed by making > the bottom 64/80 bits should be globally unique, or by informing the > other side of all possible values that may appear in those 45 bits > beforehand. > > As long as we're flying up levels, why not go up one more and compare > different multiple-PA approaches? From owner-multi6@ops.ietf.org Wed Apr 16 11:09:12 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05146 for ; Wed, 16 Apr 2003 11:09:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 195oYl-0000Gj-00 for multi6-data@psg.com; Wed, 16 Apr 2003 15:10:51 +0000 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 195oYH-0000Ft-00; Wed, 16 Apr 2003 15:10:21 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h3GF9CE61831; Wed, 16 Apr 2003 17:09:12 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Wed, 16 Apr 2003 17:09:04 +0200 Subject: Re: geo short vs long term? [Re: Geo pros and cons] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Randy Bush , Joe Abley , multi6@ops.ietf.org To: Sean Doran From: Iljitsch van Beijnum In-Reply-To: Message-Id: <5C9A2F90-701D-11D7-B238-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On woensdag, apr 16, 2003, at 15:10 Europe/Amsterdam, Sean Doran wrote: >> I am asking you here and now to step back and let someone else, who >> can take all of this seriously, take over. > I would seriously appreciate it if someone would volunteer himself or > herself to the ADs so that I am freer to address (apologies for the > pun) many of the discussions here in a much more me-like fashion. Sounds good to me. If nobody wants the job, maybe the ADs can find someone with no previous multi6 experience? A fresh point of view certainly wouldn't hurt. Now that we have that out of the way... >> Constrained L4 architecture, anyone? Multiaddressing needs a huge >> amount of work before it can catch up with the level of functionality >> provided by today's routing-based approaches. That's why we're still >> discussing the routing stuff, even though we know it has inherent >> scalability problems. > Do you think the WG could arrive at a consensus on exactly these > points? > That is: multi6 could, if there was agreement, document that the L4 > architecture as it stands now is in the way of considering solutions > which we do not at present "know ... has inherent scalability > problems". > I happen to favour such a recognition/admission of the problem. > Whether this would trigger useful reactions outside multi6 is a point > which > interests me enormously. Obviously I feel it would still be useful to pursue short term solutions in order to buy time to develop good long term solutions, but that wasn't the question... It seems to me that if there is going to be consensus about _anything_ it has to happen during a meeting, where there is much more pressure to do _something_. On the list, calls for consensus usually don't yield much result one way or the other. But to really answer your question: I think it should be doable to find consensus on the fact that layer 4 choices in the past are making our life difficult today, but I'm not sure we can agree on a plan of attack. I suspect that many people will take the position "if TCP wants a stable address, we'll implement magic in the IP layer to make this happen" rather than "let's improve TCP". Well, maybe that could be our consensus. I'd rather see it happen cleanly by changing TCP, but if we can get it to work without too big a mess in IP, I suppose I can get behind that. If we can indeed find rough consensus on that, maybe we don't even have to throw it back outside multi6. From owner-multi6@ops.ietf.org Wed Apr 16 11:13:10 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05344 for ; Wed, 16 Apr 2003 11:13:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 195od2-0000RD-00 for multi6-data@psg.com; Wed, 16 Apr 2003 15:15:16 +0000 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 195ocg-0000P2-00 for multi6@ops.ietf.org; Wed, 16 Apr 2003 15:14:55 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h3GFDkE61838; Wed, 16 Apr 2003 17:13:46 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Wed, 16 Apr 2003 17:13:36 +0200 Subject: Re: I-D ACTION:draft-ietf-multi6-multihoming-requirements-04.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: Joe Abley From: Iljitsch van Beijnum In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On woensdag, apr 16, 2003, at 15:39 Europe/Amsterdam, Joe Abley wrote: > In response to some other private feedback, I also added the following > sentence to the security section: > Any changes to routing practices made to accommodate multihomed > sites should not cause non-multihomed sites to become more > vulnerable to security breaches. > Comments on that would be appreciated. Security breach != DoS ? From owner-multi6@ops.ietf.org Wed Apr 16 11:18:05 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05467 for ; Wed, 16 Apr 2003 11:18:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 195ohk-0000ci-00 for multi6-data@psg.com; Wed, 16 Apr 2003 15:20:08 +0000 Received: from buffoon.automagic.org ([208.185.30.208]) by psg.com with smtp (Exim 3.36 #1) id 195ohO-0000ay-00 for multi6@ops.ietf.org; Wed, 16 Apr 2003 15:19:46 +0000 Received: (qmail 50004 invoked by uid 0); 16 Apr 2003 15:19:45 -0000 Received: from localhost.automagic.org (HELO isc.org) (root@127.0.0.1) by localhost.automagic.org with SMTP; 16 Apr 2003 15:19:45 -0000 Date: Wed, 16 Apr 2003 11:19:58 -0400 Subject: Re: I-D ACTION:draft-ietf-multi6-multihoming-requirements-04.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: Iljitsch van Beijnum From: Joe Abley In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wednesday, Apr 16, 2003, at 11:13 Canada/Eastern, Iljitsch van Beijnum wrote: > On woensdag, apr 16, 2003, at 15:39 Europe/Amsterdam, Joe Abley wrote: > >> In response to some other private feedback, I also added the >> following sentence to the security section: > >> Any changes to routing practices made to accommodate multihomed >> sites should not cause non-multihomed sites to become more >> vulnerable to security breaches. > >> Comments on that would be appreciated. > > Security breach != DoS ? Your point is that other non-multihomed sites are more vulnerable to DoS attacks from me because I am multi-homed? I don't think that's the case; whether or not I decide to DoS another site seems orthogonal to the number of ways I have of launching one. Joe From owner-multi6@ops.ietf.org Wed Apr 16 11:25:23 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05692 for ; Wed, 16 Apr 2003 11:25:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 195ooD-0000ok-00 for multi6-data@psg.com; Wed, 16 Apr 2003 15:26:49 +0000 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 195onb-0000nF-00 for multi6@ops.ietf.org; Wed, 16 Apr 2003 15:26:11 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h3GFP0E61895; Wed, 16 Apr 2003 17:25:00 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Wed, 16 Apr 2003 17:24:51 +0200 Subject: Re: I-D ACTION:draft-ietf-multi6-multihoming-requirements-04.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: Joe Abley From: Iljitsch van Beijnum In-Reply-To: Message-Id: <9122B11B-701F-11D7-B238-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On woensdag, apr 16, 2003, at 17:19 Europe/Amsterdam, Joe Abley wrote: >> Security breach != DoS ? > Your point is that other non-multihomed sites are more vulnerable to > DoS attacks from me because I am multi-homed? My point is that ingress filtering between ISPs may be problematic with some routing approaches. This is a problem, but not enough to forego these approaches, IMO. From owner-multi6@ops.ietf.org Wed Apr 16 11:36:04 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06027 for ; Wed, 16 Apr 2003 11:36:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 195oz5-000193-00 for multi6-data@psg.com; Wed, 16 Apr 2003 15:38:03 +0000 Received: from ginger.lcs.mit.edu ([18.26.0.82]) by psg.com with esmtp (Exim 3.36 #1) id 195oyj-00018K-00 for multi6@ops.ietf.org; Wed, 16 Apr 2003 15:37:41 +0000 Received: from ginger.lcs.mit.edu (localhost [127.0.0.1]) by ginger.lcs.mit.edu (8.12.9/8.12.9) with ESMTP id h3GFbdtU001818; Wed, 16 Apr 2003 11:37:39 -0400 Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.12.9/8.12.9/Submit) id h3GFbcsT001817; Wed, 16 Apr 2003 11:37:38 -0400 Date: Wed, 16 Apr 2003 11:37:38 -0400 From: "J. Noel Chiappa" Message-Id: <200304161537.h3GFbcsT001817@ginger.lcs.mit.edu> To: multi6@ops.ietf.org Subject: Re: geo short vs long term? [Re: Geo pros and cons] Cc: jnc@ginger.lcs.mit.edu X-Spam-Status: No, hits=-6.6 required=5.0 tests=BAYES_01 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: Iljitsch van Beijnum > Obviously I feel it would still be useful to pursue short term > solutions in order to buy time to develop good long term solutions Alas, the IETF has a way of just continuing to use the interim short-turn solutions, and never getting to the good long-term solutions. CIDR was supposed to be an interim short-turn solution, but we're still using it, and the routing protocols we had at the time. Running the routing in a global-scale network as a giant distributed computation is completely crazy, something for which you'd fail any systems architecture student who proposed it, but we're still doing it. Noel From owner-multi6@ops.ietf.org Wed Apr 16 11:39:39 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06130 for ; Wed, 16 Apr 2003 11:39:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 195p2e-0001Hf-00 for multi6-data@psg.com; Wed, 16 Apr 2003 15:41:44 +0000 Received: from jazz-1.trumpet.com.au ([203.5.119.62]) by psg.com with esmtp (Exim 3.36 #1) id 195p2G-0001Gz-00 for multi6@ops.ietf.org; Wed, 16 Apr 2003 15:41:20 +0000 Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id BAA27706; Thu, 17 Apr 2003 01:41:11 +1000 (EST) Date: Thu, 17 Apr 2003 01:41:11 +1000 (EST) From: Peter Tattam To: Brian E Carpenter cc: Iljitsch van Beijnum , Multi6 Working Group Subject: Re: old GSE idea In-Reply-To: <3E9D710F.50523C1D@hursley.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-31.7 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk You don't need to break into TCP stacks if the variable bits are zeroed at the borders and if advertised addresses (i.e. DNS, IPSEC) always have these bits zeroed. Existing Ipv6 stacks should be able to work right away if the zeroing rules are adhered to. Even so, you still have to solve the issue of binding the strongly aggregated routing gook to the site unique ID without degenerating back to what we have in IPv4. Restating my earlier observation - if the core is going to be strongly aggregated, the MH information to any particular site is absent at the core. Ti does actually still exist in the network, so it needs to be reconstituted somehow. DNS based approaches to the binding problem would not be rugged or timely enough, nor would they deal adequately with load sharing. Something akin to the connectivity cache would still be required. The question is to use a push approach (broadcast or BGP like) or a pull approach (DNS like). here's another idea (again apologies if it's already been thought of). why not apply a few more rules to the aggregated BGP tree. For example, each leaf BGP node can only be N (e.g. N=2) BGP hops from the core. If that were the case if might not be unreasonable to extend BGP so that a transient query could be made to the nearest node to determine the MH paths of the other end. This information would travel through the core, but not need not remain in the core. The choice as to whether to cache the information would a matter of policy. A core BGP router would typically only pass information but not cache it whereas an edge BGP router would be free to cache what it desired - perhaps within the contraints of its CPU and memory. Peter On Wed, 16 Apr 2003, Brian E Carpenter wrote: > Actually the requirement isn't that the bottom 80 bits be globally > unique, but that they be mutually unique among the set of hosts > involved (which may of course be more than two, due to referrals). > I don't know if that constraint is easier to meet. > > Some would say that the answer to your question is HIP. > > I do agree we should agree on a systematic breakdown and comparison > of approaches. > > Brian > > Iljitsch van Beijnum wrote: > > > > On woensdag, apr 16, 2003, at 15:40 Europe/Amsterdam, Brian E Carpenter > > wrote: > > > > > I think we should fly up one level and discuss a hypothetical > > > world in which addresses in A000::/3 are deemed to be mutable > > > in flight between bits 3 and 47 inclusive. See what it does > > > to TCP, SCTP and IPSEC for example. > > > > Well, break them... The TCP/UDP checksum should be easy enough to fix, > > IPsec AH not much harder. The real problem is that if I have a session > > with a001::1 and suddenly packets start coming in from a002::1, how do > > I know these belong to the same session? This can be fixed by making > > the bottom 64/80 bits should be globally unique, or by informing the > > other side of all possible values that may appear in those 45 bits > > beforehand. > > > > As long as we're flying up levels, why not go up one more and compare > > different multiple-PA approaches? > > -- Peter R. Tattam peter@trumpet.com Managing Director, Trumpet Software International Pty Ltd Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 From owner-multi6@ops.ietf.org Wed Apr 16 11:48:20 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06338 for ; Wed, 16 Apr 2003 11:48:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 195p9j-0001ab-00 for multi6-data@psg.com; Wed, 16 Apr 2003 15:49:03 +0000 Received: from host217-37-202-105.in-addr.btopenworld.com ([217.37.202.105] helo=ab.use.net) by psg.com with esmtp (Exim 3.36 #1) id 195p9M-0001ZT-00 for multi6@ops.ietf.org; Wed, 16 Apr 2003 15:48:40 +0000 Received: from ab.use.net (conf.use.net [217.37.202.109]) by ab.use.net (Postfix) with ESMTP id DE95B39742; Wed, 16 Apr 2003 15:48:38 +0000 (GMT) Date: Wed, 16 Apr 2003 16:48:38 +0100 Subject: Re: I-D ACTION:draft-ietf-multi6-multihoming-requirements-04.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Sean Doran , Joe Abley , multi6@ops.ietf.org To: Brian E Carpenter From: Sean Doran In-Reply-To: <3E9D6EC8.FD2C6051@hursley.ibm.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wednesday, Apr 16, 2003, at 15:55 Europe/London, Brian E Carpenter wrote: > Joe Abley wrote: >> Any changes to routing practices made to accommodate >> multihomed >> sites should not cause non-multihomed sites to become more "or the core" -- so perhaps 'other parts of the Internet, including non-multihomed sites'. > I think that is good. I'll certainly concede to you and Sean > on my own suggestion, but I fear we will get pushback from > the IESG if we produce a solution that does weaken security. There will be even more immediate pushback (i.e., well before IESG) if we can't justify any trade-offs between utility and security which favour the former. Hopefully a compelling justification will lessen any pushback, assuming any new vulnerabilities / weaknesses are known to exist in whatever work emanates from here. Sean. From owner-multi6@ops.ietf.org Wed Apr 16 11:53:05 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06475 for ; Wed, 16 Apr 2003 11:53:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 195pEd-0001mX-00 for multi6-data@psg.com; Wed, 16 Apr 2003 15:54:07 +0000 Received: from ip166.usw12.rb1.bel.nwlink.com ([209.20.253.166] helo=ran.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 195pEF-0001lq-00 for multi6@ops.ietf.org; Wed, 16 Apr 2003 15:53:44 +0000 Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.14) id 195pE8-000PJ1-8R; Wed, 16 Apr 2003 08:53:36 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 16 Apr 2003 08:53:35 -0700 To: Iljitsch van Beijnum Cc: multi6@ops.ietf.org Subject: Re: geo short vs long term? [Re: Geo pros and cons] References: <5C9A2F90-701D-11D7-B238-00039388672E@muada.com> Message-Id: X-Spam-Status: No, hits=-16.3 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > maybe the ADs can find someone with no previous multi6 experience? no one has such experience. so far, multi6 is a fantasy. randy From owner-multi6@ops.ietf.org Wed Apr 16 12:02:01 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06906 for ; Wed, 16 Apr 2003 12:02:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 195pNI-00024j-00 for multi6-data@psg.com; Wed, 16 Apr 2003 16:03:04 +0000 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 195pMw-00024Q-00; Wed, 16 Apr 2003 16:02:42 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h3GG1XE61995; Wed, 16 Apr 2003 18:01:33 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Wed, 16 Apr 2003 18:01:24 +0200 Subject: Re: geo short vs long term? [Re: Geo pros and cons] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: Randy Bush From: Iljitsch van Beijnum In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-28.9 required=5.0 tests=BAYES_00,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On woensdag, apr 16, 2003, at 17:53 Europe/Amsterdam, Randy Bush wrote: >> maybe the ADs can find someone with no previous multi6 experience? > no one has such experience. so far, multi6 is a fantasy. What I meant was: someone who isn't and/or hasn't been involved in this wg. From owner-multi6@ops.ietf.org Wed Apr 16 14:27:50 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10894 for ; Wed, 16 Apr 2003 14:27:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 195reR-0008In-00 for multi6-data@psg.com; Wed, 16 Apr 2003 18:28:55 +0000 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #1) id 195re5-0008I6-00 for multi6@ops.ietf.org; Wed, 16 Apr 2003 18:28:33 +0000 Received: from nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id D9036137F0B; Wed, 16 Apr 2003 11:28:31 -0700 (PDT) Date: Wed, 16 Apr 2003 11:28:27 -0700 Subject: Re: old GSE idea Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Brian E Carpenter , Multi6 Working Group To: Iljitsch van Beijnum From: David Conrad In-Reply-To: <22EB296A-701B-11D7-B238-00039388672E@muada.com> Message-Id: <3774DEC0-7039-11D7-8302-000393DB42B2@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-28.3 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wednesday, April 16, 2003, at 07:53 AM, Iljitsch van Beijnum wrote: > On woensdag, apr 16, 2003, at 15:40 Europe/Amsterdam, Brian E > Carpenter wrote: > >> I think we should fly up one level and discuss a hypothetical >> world in which addresses in A000::/3 are deemed to be mutable >> in flight between bits 3 and 47 inclusive. Lovely idea. >> See what it does >> to TCP, SCTP and IPSEC for example. > > Well, break them... The TCP/UDP checksum should be easy enough to fix, Right. Either change the pseudo-header checksum to incorporate only the top 3 and lower 80 or set the 45 bits of the global locator to some constant value. The latter approach allows for use of existing IPv6 code, but makes figuring out the source of a (non-malicious) DoS and/or the source of an ICMP unreachable message at the end point a bit challenging (malicious DoS would likely have a spoofed locator). > IPsec AH not much harder. The real problem is that if I have a session > with a001::1 and suddenly packets start coming in from a002::1, how do > I know these belong to the same session? This can be fixed by making > the bottom 64/80 bits should be globally unique, or by informing the > other side of all possible values that may appear in those 45 bits > beforehand. I think the simplest solution is to make the lower 64 bits globally unique. Treat the endpoint ID as a key into a distributed database of one or more locators associated with that endpoint ID. The endpoint need not (ever) know the full destination address, that is, the DNS lookup of the end point host name would only return (top 3, lower 80). The core/edge boundary packet forwarder takes the destination end point identifier of the outgoing packet, looks up (simple hash would work) the locators associated with that end point, picks one of the locators based on some administrative policy (e.g., AS hop count), rewrites the locator into the destination address and sends the packet on its way. > As long as we're flying up levels, why not go up one more and compare > different multiple-PA approaches? One reason I like the GSE concept is that it removes the topology change induced renumbering problem from end sites, providing (in addition to multi-homing), number portability, at least from the perspective of end users (yes, non-tier 1 ISPs will need to renumber their infrastructure should they decide to change upstreams, but this wouldn't affect their customers). The other approaches that do not separate locator from identifier don't address this problem (to my knowledge, pointers to documents where they do greatly appreciated). From my perspective, the "real" problems with the GSE concept, at least historically, have been dealing with the distributed endpoint ID/locator map and the fear that GSE would make insertion attacks easier. Given the state of routing security (that is, the ability to insert pretty much any prefix into the routing system) I personally do not believe the latter concern is significantly worsened by something like GSE and, in any event, this issue would be addressed by deployment of IPSEC. With respect to dealing with a distributed database, there are two broad approaches, pushing the data out (e.g., the way routiing tables are propagated) or pulling the data in (e.g., the way the DNS works). Both have advantages and disadvantages, but this given existence of solutions to this problem, this part seems solvable to me. Rgds, -drc From owner-multi6@ops.ietf.org Wed Apr 16 16:00:03 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14972 for ; Wed, 16 Apr 2003 16:00:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 195t59-000CfF-00 for multi6-data@psg.com; Wed, 16 Apr 2003 20:00:35 +0000 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 195t4e-000CbX-00 for multi6@ops.ietf.org; Wed, 16 Apr 2003 20:00:04 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h3GJwsE62322; Wed, 16 Apr 2003 21:58:55 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Wed, 16 Apr 2003 21:58:43 +0200 Subject: Re: old GSE idea Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Multi6 Working Group To: David Conrad From: Iljitsch van Beijnum In-Reply-To: <3774DEC0-7039-11D7-8302-000393DB42B2@nominum.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On woensdag, apr 16, 2003, at 20:28 Europe/Amsterdam, David Conrad wrote: > I think the simplest solution is to make the lower 64 bits globally > unique. This breaks autoconfiguration. I think we need at least 40 bits for the organization ID so that leaves just 24 bits for link-local use, which isn't enough to make it possible for hosts to select a fixed address without significant risk of address collisions. Not a fatal flaw I guess, but not great either. > Treat the endpoint ID as a key into a distributed database of one or > more locators associated with that endpoint ID. The endpoint need not > (ever) know the full destination address, that is, the DNS lookup of > the end point host name would only return (top 3, lower 80). Why not simply have the full addresses in the DNS? > The core/edge boundary packet forwarder takes the destination end > point identifier of the outgoing packet, looks up (simple hash would > work) the locators associated with that end point, picks one of the > locators based on some administrative policy (e.g., AS hop count), > rewrites the locator into the destination address and sends the packet > on its way. So what happens when a link goes down? Also we probably want this to happen either in the host or at the edge (not the core, that would be another explosion of state) as per site policy and not just at the edge. >> As long as we're flying up levels, why not go up one more and compare >> different multiple-PA approaches? > One reason I like the GSE concept is that it removes the topology > change induced renumbering problem from end sites, providing (in > addition to multi-homing), number portability, at least from the > perspective of end users Other solutions in this area provide the same benefit without breaking link local behavior, and I would (eventually) like to go even further and completely remove the addresses from the user experience: just use names. > The other approaches that do not separate locator from identifier > don't address this problem (to my knowledge, pointers to documents > where they do greatly appreciated). See Michel Py's MHAP draft. There are some difficult areas there, but the basic idea is worthwhile. One thing that is very attractive is that it moves standard IPv6 hosts behind a middlebox that handles all multihoming processing. The downside is that it requires this, but I'm confident that we can move MHAP or MHAP-like processing to hosts if desired. > From my perspective, the "real" problems with the GSE concept, at > least historically, have been dealing with the distributed endpoint > ID/locator map and the fear that GSE would make insertion attacks > easier. Given the state of routing security (that is, the ability to > insert pretty much any prefix into the routing system) I personally do > not believe the latter concern is significantly worsened by something > like GSE and, in any event, this issue would be addressed by > deployment of IPSEC. How is IPsec going to help you if the packets are rerouted over the null0 interface? > With respect to dealing with a distributed database, there are two > broad approaches, pushing the data out (e.g., the way routiing tables > are propagated) or pulling the data in (e.g., the way the DNS works). > Both have advantages and disadvantages, but this given existence of > solutions to this problem, this part seems solvable to me. Don't forget about the actual failover. Also quite solvable, but not a trivial problem. The problem I have with GSE and its derivatives is that it is self-contained and doesn't provide hooks either forward or backward. It would be great if it could be part of a bigger picture, where we can upgrade from what we have today, to something a bit better, to GSE++, to a clean architecture where we really get to drop in new protocols for each layer like the OSI guys always promised we could. From owner-multi6@ops.ietf.org Wed Apr 16 16:44:29 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16110 for ; Wed, 16 Apr 2003 16:44:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 195tnB-000EyW-00 for multi6-data@psg.com; Wed, 16 Apr 2003 20:46:05 +0000 Received: from dmz1.procket.com ([65.174.124.36]) by psg.com with esmtp (Exim 3.36 #1) id 195tmp-000Exx-00 for multi6@ops.ietf.org; Wed, 16 Apr 2003 20:45:43 +0000 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id B1A8F23C6A; Wed, 16 Apr 2003 13:35:00 -0700 (PDT) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h3GKjgYB004567; Wed, 16 Apr 2003 13:45:42 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: old GSE idea Date: Wed, 16 Apr 2003 13:45:42 -0700 Message-ID: Thread-Topic: old GSE idea Thread-Index: AcMEV3DbPZq3zXgRTRiqTHAlhOGeOAAAXHgg From: "Tony Li" To: "Iljitsch van Beijnum" , "David Conrad" Cc: "Multi6 Working Group" X-Spam-Status: No, hits=-6.6 required=5.0 tests=BAYES_01 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA16110 | The problem I have with GSE and its derivatives is that it is | self-contained and doesn't provide hooks either forward or | backward. It | would be great if it could be part of a bigger picture, | where we can | upgrade from what we have today, to something a bit | better, to GSE++, | to a clean architecture where we really get to drop in new | protocols | for each layer like the OSI guys always promised we could. Interesting. I'm afraid that I don't really understand tho. If you're suggesting that we won't be able to support a new network layer protocol, then I'm confused. If you're talking about new transports, I don't think those are even challenging. Tony From owner-multi6@ops.ietf.org Wed Apr 16 17:59:48 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18351 for ; Wed, 16 Apr 2003 17:59:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 195uxN-000JCG-00 for multi6-data@psg.com; Wed, 16 Apr 2003 22:00:41 +0000 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 195ux0-000J9S-00 for multi6@ops.ietf.org; Wed, 16 Apr 2003 22:00:19 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h3GLx7E62536; Wed, 16 Apr 2003 23:59:07 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Wed, 16 Apr 2003 23:58:56 +0200 Subject: Re: old GSE idea Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "David Conrad" , "Multi6 Working Group" To: "Tony Li" From: Iljitsch van Beijnum In-Reply-To: Message-Id: <9EDB00A6-7056-11D7-B6EB-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On woensdag, apr 16, 2003, at 22:45 Europe/Amsterdam, Tony Li wrote: > | It would be great if it could be part of a bigger picture, > | where we can upgrade from what we have today, to something a bit > | better, to GSE++, to a clean architecture where we really get to > | drop in new protocols > | for each layer like the OSI guys always promised we could. > Interesting. I'm afraid that I don't really understand tho. > If you're suggesting that we won't be able to support a new > network layer protocol, then I'm confused. Look at what had to be done to support a new version of IP: changes to transport protocols and the API. That's not good. We only had IPv4 for around 15 years before work started on IPv6. So I'm guessing most of us will see IPv7 well before we retire. > If you're talking > about new transports, I don't think those are even challenging. Want to change from TCP to SCTP? Again, new API. Ok, all of this was unavoidable. But these new APIs address only the problem at hand, and don't provide a real improvement. If you want to support both IPv4 and IPv6 in an application, you need to support IPv4 using the IPv4 socket API, IPv6 using the IPv6 socket API and then use your own logic to decide which to use when. And if IPv7 changes the address length and/or we want to support CLNS, that's another round of changes. And the really pathetic part is that the original socket API is kept general in order to support different protocols, which makes it incredibly inconvenient to program but not general enough to actually support anything else (usable) other than IPv4. So how does this apply to GSE++? We now have TCP that groks pseudo headers with IPv4 addresses in them and IPv6 addresses in them. We extend this to 83 bits out of an IPv6 address. This can go on for a while. It seems to me that we should either not care at all about the IP addresses in TCP and other transport protocols, or offload this aspect to IP. This is the kind of stuff that doesn't cost us a lot now, but saves us a great deal in the future. From owner-multi6@ops.ietf.org Wed Apr 16 18:19:25 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19837 for ; Wed, 16 Apr 2003 18:19:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 195vH8-000KQk-00 for multi6-data@psg.com; Wed, 16 Apr 2003 22:21:06 +0000 Received: from dmz1.procket.com ([65.174.124.36]) by psg.com with esmtp (Exim 3.36 #1) id 195vGl-000KQI-00 for multi6@ops.ietf.org; Wed, 16 Apr 2003 22:20:43 +0000 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id 62B6823C65; Wed, 16 Apr 2003 15:10:02 -0700 (PDT) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h3GMKhYB009006; Wed, 16 Apr 2003 15:20:43 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: old GSE idea Date: Wed, 16 Apr 2003 15:20:43 -0700 Message-ID: Thread-Topic: old GSE idea Thread-Index: AcMEY5eWuP+CG1lyQn+Wweg+RJqlWgAAhDhw From: "Tony Li" To: "Iljitsch van Beijnum" Cc: "David Conrad" , "Multi6 Working Group" X-Spam-Status: No, hits=-6.6 required=5.0 tests=BAYES_01 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA19837 | We only had IPv4 for around 15 years before work started | on IPv6. So | I'm guessing most of us will see IPv7 well before we retire. You clearly underestimate the age of many of us on the group, for which we all thank you. | | Yes, the sockets API is a bit dated and starting to show issues. I don't disagree, but that's a different working group. ;-) | So how does this apply to GSE++? | | We now have TCP that groks pseudo headers with IPv4 | addresses in them | and IPv6 addresses in them. We extend this to 83 bits out | of an IPv6 | address. This can go on for a while. It seems to me that we should | either not care at all about the IP addresses in TCP and other | transport protocols, or offload this aspect to IP. | | This is the kind of stuff that doesn't cost us a lot now, | but saves us | a great deal in the future. This is an excellent point. TCP makes use of the IP address as an identifier. If we've separated identifiers and locators, then we need to tweak TCP to just use the identifier portion. After that, we're pretty much free to change anything, as long as we maintain the identifiers, and not change the network layer protocol. If IPv7 turns out to be CLNP and we embed identifiers inside of an NSAP, that should be much much easier. [Note: this is an example, not a serious proposal. CLNP haters can re-holster their guns.] I think that this is one of the benefits that's inherent in GSE, not an issue with it. So I guess I'm still not seeing the issue. GSE has the ONE hook that is necessary to upgrade later. Tony From owner-multi6@ops.ietf.org Wed Apr 16 19:29:34 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21229 for ; Wed, 16 Apr 2003 19:29:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 195wMF-000Oed-00 for multi6-data@psg.com; Wed, 16 Apr 2003 23:30:27 +0000 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #1) id 195wLm-000OZu-00 for multi6@ops.ietf.org; Wed, 16 Apr 2003 23:29:58 +0000 Received: from nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 82A47137F0B; Wed, 16 Apr 2003 16:29:57 -0700 (PDT) Date: Wed, 16 Apr 2003 16:29:55 -0700 Subject: Re: old GSE idea Content-Type: multipart/alternative; boundary=Apple-Mail-12--785848087 Mime-Version: 1.0 (Apple Message framework v552) Cc: Multi6 Working Group To: Iljitsch van Beijnum From: David Conrad In-Reply-To: Message-Id: <54E53864-7063-11D7-8302-000393DB42B2@nominum.com> X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk --Apple-Mail-12--785848087 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Iljitsch, On Wednesday, April 16, 2003, at 12:58 PM, Iljitsch van Beijnum wrote: > On woensdag, apr 16, 2003, at 20:28 Europe/Amsterdam, David Conrad > wrote: >> I think the simplest solution is to make the lower 64 bits globally >> unique. > This breaks autoconfiguration. Only in as much as the 64 bits used in auto-configuration are not globally unique. How is this that much different than duplicate IP addresses in a WAN or duplicate MAC addresses on a LAN (both in terms of detection and remedy)? It should be treated as the error condition it is, not a normal state of affairs. > I think we need at least 40 bits for the organization ID so that > leaves just 24 bits for link-local use, Why put location back into identity? In my view, endpoint identifiers are 'names'. They are a flat, undifferentiated (from the network perspective, administratively, you may want some hierarchy) identifier space. The core/edge boundary forwarding mechanism dynamically associates a set of locators with that identifier. If you don't need to cross the core/edge boundary, normal routing via the lower 80 bits (16 bit site locator, 64 bit identifier) applies. >> Treat the endpoint ID as a key into a distributed database of one or >> more locators associated with that endpoint ID. The endpoint need >> not (ever) know the full destination address, that is, the DNS lookup >> of the end point host name would only return (top 3, lower 80). > Why not simply have the full addresses in the DNS? Because it complicates renumbering and the DNS administrator does not know what the full addresses are. The full address is synthesized as a packet crosses the core/edge boundary and depends on the service provider(s) the destination uses. Also, placing the full address in the DNS would mean the administrator of the core/edge boundary forwarding mechanism has the authorization to muck about with data about the identifier. This is probably not universally desirable. >> The core/edge boundary packet forwarder takes the destination end >> point identifier of the outgoing packet, looks up (simple hash would >> work) the locators associated with that end point, picks one of the >> locators based on some administrative policy (e.g., AS hop count), >> rewrites the locator into the destination address and sends the >> packet on its way. > So what happens when a link goes down? Assuming you are asking about the multi-homed destination case,the naive approach would be to have the source core/edge boundary forwarder notice the link is down via 'traditional' methods (BGP re-convergence, ICMP network unreachable, whatever) and choose an alternate from the set of locators that map into the endpoint identifier. For a slightly more complicated case, see below. > Also we probably want this to happen either in the host or at the edge > (not the core, that would be another explosion of state) as per site > policy and not just at the edge. I meant the term "core/edge boundary" to imply the insertion of the locator occurs at the boundary between the core (more accurately, that part of the network that only cares about the locator) and the edge (more accurately, that part of the network that cares about the end point ID). Normal CIDR provider-based addressing, painful renumbering, BGP-4+, etc. applies within the core -- it is no different than what we have today. >> One reason I like the GSE concept is that it removes the topology >> change induced renumbering problem from end sites, providing (in >> addition to multi-homing), number portability, at least from the >> perspective of end users > Other solutions in this area provide the same benefit without breaking > link local behavior, How do GSE-like solutions break link local behavior? > and I would (eventually) like to go even further and completely remove > the addresses from the user experience: just use names. Presumably by "user experience" you mean from above the network layer. You can have this if you limit names to 8 bytes. :-) >> The other approaches that do not separate locator from identifier >> don't address this problem (to my knowledge, pointers to documents >> where they do greatly appreciated). > See Michel Py's MHAP draft. There are some difficult areas there, but > the basic idea is worthwhile. One thing that is very attractive is > that it moves standard IPv6 hosts behind a middlebox that handles all > multihoming processing. The downside is that it requires this, but I'm > confident that we can move MHAP or MHAP-like processing to hosts if > desired. GSE-like solutions provide this positive/negative as well. I'll read Michel's MHAP draft. >> From my perspective, the "real" problems with the GSE concept, at >> least historically, have been dealing with the distributed endpoint >> ID/locator map and the fear that GSE would make insertion attacks >> easier. Given the state of routing security (that is, the ability to >> insert pretty much any prefix into the routing system) I personally >> do not believe the latter concern is significantly worsened by >> something like GSE and, in any event, this issue would be addressed >> by deployment of IPSEC. > How is IPsec going to help you if the packets are rerouted over the > null0 interface? Sorry, don't follow. >> With respect to dealing with a distributed database, there are two >> broad approaches, pushing the data out (e.g., the way routiing tables >> are propagated) or pulling the data in (e.g., the way the DNS works). >> Both have advantages and disadvantages, but this given existence of >> solutions to this problem, this part seems solvable to me. > Don't forget about the actual failover. Also quite solvable, but not a > trivial problem. The difficulty in failover is detecting failover is necessary at the source. One possible solution would be to have the alternative locators kept with the packet in transit as an IPv6 option. Should a router in the transit path determine the destination locator is unreachable, the next (in terms of some administrative policy) locator that is reachable is popped out of the option, a new destination address is synthesized, and the packet is redirected to the destination via the new locator. > The problem I have with GSE and its derivatives is that it is > self-contained and doesn't provide hooks either forward or backward. I don't understand this statement. > It would be great if it could be part of a bigger picture, where we > can upgrade from what we have today, to something a bit better, to > GSE++, to a clean architecture where we really get to drop in new > protocols for each layer like the OSI guys always promised we could. I believe the first step in any reasonable evolution will be to separate identifier from locator. Given realities of the market and the IETF, small steps are more likely to get forward motion than giant leaps. Rgds, -drc --Apple-Mail-12--785848087 Content-Type: text/enriched; charset=US-ASCII Content-Transfer-Encoding: 7bit Lucida GrandeIljitsch, On Wednesday, April 16, 2003, at 12:58 PM, Iljitsch van Beijnum wrote: On woensdag, apr 16, 2003, at 20:28 Europe/Amsterdam, David Conrad wrote: I think the simplest solution is to make the lower 64 bits globally unique. This breaks autoconfiguration. Only in as much as the 64 bits used in auto-configuration are not globally unique. How is this that much different than duplicate IP addresses in a WAN or duplicate MAC addresses on a LAN (both in terms of detection and remedy)? It should be treated as the error condition it is, not a normal state of affairs. I think we need at least 40 bits for the organization ID so that leaves just 24 bits for link-local use, Why put location back into identity? In my view, endpoint identifiers are 'names'. They are a flat, undifferentiated (from the network perspective, administratively, you may want some hierarchy) identifier space. The core/edge boundary forwarding mechanism dynamically associates a set of locators with that identifier. If you don't need to cross the core/edge boundary, normal routing via the lower 80 bits (16 bit site locator, 64 bit identifier) applies. Treat the endpoint ID as a key into a distributed database of one or more locators associated with that endpoint ID. The endpoint need not (ever) know the full destination address, that is, the DNS lookup of the end point host name would only return (top 3, lower 80). Why not simply have the full addresses in the DNS? Because it complicates renumbering and the DNS administrator does not know what the full addresses are. The full address is synthesized as a packet crosses the core/edge boundary and depends on the service provider(s) the destination uses. Also, placing the full address in the DNS would mean the administrator of the core/edge boundary forwarding mechanism has the authorization to muck about with data about the identifier. This is probably not universally desirable. The core/edge boundary packet forwarder takes the destination end point identifier of the outgoing packet, looks up (simple hash would work) the locators associated with that end point, picks one of the locators based on some administrative policy (e.g., AS hop count), rewrites the locator into the destination address and sends the packet on its way. So what happens when a link goes down? Assuming you are asking about the multi-homed destination case,the naive approach would be to have the source core/edge boundary forwarder notice the link is down via 'traditional' methods (BGP re-convergence, ICMP network unreachable, whatever) and choose an alternate from the set of locators that map into the endpoint identifier. For a slightly more complicated case, see below. Also we probably want this to happen either in the host or at the edge (not the core, that would be another explosion of state) as per site policy and not just at the edge. I meant the term "core/edge boundary" to imply the insertion of the locator occurs at the boundary between the core (more accurately, that part of the network that only cares about the locator) and the edge (more accurately, that part of the network that cares about the end point ID). Normal CIDR provider-based addressing, painful renumbering, BGP-4+, etc. applies within the core -- it is no different than what we have today. One reason I like the GSE concept is that it removes the topology change induced renumbering problem from end sites, providing (in addition to multi-homing), number portability, at least from the perspective of end users Other solutions in this area provide the same benefit without breaking link local behavior, How do GSE-like solutions break link local behavior? and I would (eventually) like to go even further and completely remove the addresses from the user experience: just use names. Presumably by "user experience" you mean from above the network layer. You can have this if you limit names to 8 bytes. :-) The other approaches that do not separate locator from identifier don't address this problem (to my knowledge, pointers to documents where they do greatly appreciated). See Michel Py's MHAP draft. There are some difficult areas there, but the basic idea is worthwhile. One thing that is very attractive is that it moves standard IPv6 hosts behind a middlebox that handles all multihoming processing. The downside is that it requires this, but I'm confident that we can move MHAP or MHAP-like processing to hosts if desired. GSE-like solutions provide this positive/negative as well. I'll read Michel's MHAP draft. From my perspective, the "real" problems with the GSE concept, at least historically, have been dealing with the distributed endpoint ID/locator map and the fear that GSE would make insertion attacks easier. Given the state of routing security (that is, the ability to insert pretty much any prefix into the routing system) I personally do not believe the latter concern is significantly worsened by something like GSE and, in any event, this issue would be addressed by deployment of IPSEC. How is IPsec going to help you if the packets are rerouted over the null0 interface? Sorry, don't follow. With respect to dealing with a distributed database, there are two broad approaches, pushing the data out (e.g., the way routiing tables are propagated) or pulling the data in (e.g., the way the DNS works). Both have advantages and disadvantages, but this given existence of solutions to this problem, this part seems solvable to me. Don't forget about the actual failover. Also quite solvable, but not a trivial problem. The difficulty in failover is detecting failover is necessary at the source. One possible solution would be to have the alternative locators kept with the packet in transit as an IPv6 option. Should a router in the transit path determine the destination locator is unreachable, the next (in terms of some administrative policy) locator that is reachable is popped out of the option, a new destination address is synthesized, and the packet is redirected to the destination via the new locator. The problem I have with GSE and its derivatives is that it is self-contained and doesn't provide hooks either forward or backward. I don't understand this statement. It would be great if it could be part of a bigger picture, where we can upgrade from what we have today, to something a bit better, to GSE++, to a clean architecture where we really get to drop in new protocols for each layer like the OSI guys always promised we could. I believe the first step in any reasonable evolution will be to separate identifier from locator. Given realities of the market and the IETF, small steps are more likely to get forward motion than giant leaps. Rgds, -drc --Apple-Mail-12--785848087-- From owner-multi6@ops.ietf.org Thu Apr 17 03:34:02 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11440 for ; Thu, 17 Apr 2003 03:34:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 1963su-000AwJ-00 for multi6-data@psg.com; Thu, 17 Apr 2003 07:32:40 +0000 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by psg.com with esmtp (Exim 3.36 #1) id 1963sY-000Ava-00 for multi6@ops.ietf.org; Thu, 17 Apr 2003 07:32:18 +0000 Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id IAA10839 for ; Thu, 17 Apr 2003 08:32:16 +0100 (BST) Received: from login.ecs.soton.ac.uk (login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3p2/8.9.3) with ESMTP id IAA10017 for ; Thu, 17 Apr 2003 08:32:16 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h3H7WG403773 for multi6@ops.ietf.org; Thu, 17 Apr 2003 08:32:16 +0100 Date: Thu, 17 Apr 2003 08:32:16 +0100 From: Tim Chown To: multi6@ops.ietf.org Subject: Re: Resolving geo discussions Message-ID: <20030417073216.GC3579@login.ecs.soton.ac.uk> Mail-Followup-To: multi6@ops.ietf.org References: <3E9D5F6A.85F93206@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E9D5F6A.85F93206@hursley.ibm.com> User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-38.8 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MUTT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, Apr 16, 2003 at 03:49:30PM +0200, Brian E Carpenter wrote: > I agree. Actually I am hoping to see more from the co-chairs, > not less. Absolutely, and it's just 3 months to Vienna and the restoration of the multi6 sessions at the meetings. We should have some idea soon of what will be on the table there and Sean and Kurtis' input here to shape that is very important. Tim From owner-multi6@ops.ietf.org Thu Apr 17 05:34:42 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13584 for ; Thu, 17 Apr 2003 05:34:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 1965mO-000Drt-00 for multi6-data@psg.com; Thu, 17 Apr 2003 09:34:04 +0000 Received: from tele2-1-1-dialup-245.freesurf.ch ([194.230.196.245] helo=dhcp1.se.kurtis.pp.se) by psg.com with esmtp (Exim 3.36 #1) id 1965m1-000DrU-00; Thu, 17 Apr 2003 09:33:42 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp1.se.kurtis.pp.se (8.12.9/8.10.2) with ESMTP id h3H9XlBQ001945; Thu, 17 Apr 2003 11:33:48 +0200 (CEST) Date: Thu, 17 Apr 2003 10:29:05 +0200 Subject: Re: geo short vs long term? [Re: Geo pros and cons] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Sean Doran , Randy Bush , Joe Abley , multi6@ops.ietf.org To: Iljitsch van Beijnum From: Kurt Erik Lindqvist In-Reply-To: <5C9A2F90-701D-11D7-B238-00039388672E@muada.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.7 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On onsdag, apr 16, 2003, at 17:09 Europe/Stockholm, Iljitsch van Beijnum wrote: > > But to really answer your question: I think it should be doable to > find consensus on the fact that layer 4 choices in the past are making > our life difficult today, but I'm not sure we can agree on a plan of > attack. I suspect that many people will take the position "if TCP > wants a stable address, we'll implement magic in the IP layer to make > this happen" rather than "let's improve TCP". Well, maybe that could > be our consensus. I'd rather see it happen cleanly by changing TCP, > but if we can get it to work without too big a mess in IP, I suppose I > can get behind that. > > If we can indeed find rough consensus on that, maybe we don't even > have to throw it back outside multi6. I think the first step still is to define what the options are. Then we can start worry about consensus. But I agree that we need to start at a meeting. - kurtis - From owner-multi6@ops.ietf.org Thu Apr 17 05:35:06 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13603 for ; Thu, 17 Apr 2003 05:35:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 1965nM-000Duo-00 for multi6-data@psg.com; Thu, 17 Apr 2003 09:35:04 +0000 Received: from tele2-1-1-dialup-245.freesurf.ch ([194.230.196.245] helo=dhcp1.se.kurtis.pp.se) by psg.com with esmtp (Exim 3.36 #1) id 1965mj-000DsG-00 for multi6@ops.ietf.org; Thu, 17 Apr 2003 09:34:27 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp1.se.kurtis.pp.se (8.12.9/8.10.2) with ESMTP id h3H9a2BQ001950 for ; Thu, 17 Apr 2003 11:36:05 +0200 (CEST) Date: Thu, 17 Apr 2003 10:36:58 +0200 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: Discussions From: Kurt Erik Lindqvist To: multi6@ops.ietf.org Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-9.7 required=5.0 tests=BAYES_01,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit (I have been walking around 2800m mountains with skis trapped to by back-pack, so I am trying to catch up) I first thought I would not bother to say anything on this issue, but changed my mind. I really feel the discussions on the list after SF have been constructive and a number of views have been brought up. I think we are getting a basis for a number of discussions in Vienna. However, for the past few days the level of the debate have sunk quite drastically. I want to remind everyone that personal attacks or insults won't help any of us move forward. Discussions on who is suitable as co-chair is most likely best discussed with the two ADs. Now back to the regular programming.... Best regards, - kurtis - From owner-multi6@ops.ietf.org Thu Apr 17 08:00:26 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17969 for ; Thu, 17 Apr 2003 08:00:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19684N-000J48-00 for multi6-data@psg.com; Thu, 17 Apr 2003 12:00:47 +0000 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 19683z-000J22-00 for multi6@ops.ietf.org; Thu, 17 Apr 2003 12:00:24 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h3HBxDE64150; Thu, 17 Apr 2003 13:59:13 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Thu, 17 Apr 2003 13:59:05 +0200 Subject: Re: old GSE idea Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Multi6 Working Group To: David Conrad From: Iljitsch van Beijnum In-Reply-To: <54E53864-7063-11D7-8302-000393DB42B2@nominum.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On donderdag, apr 17, 2003, at 01:29 Europe/Amsterdam, David Conrad wrote: >>> I think the simplest solution is to make the lower 64 bits globally >>> unique. >> This breaks autoconfiguration. > Only in as much as the 64 bits used in auto-configuration are not > globally unique. How is this that much different than duplicate IP > addresses in a WAN or duplicate MAC addresses on a LAN (both in terms > of detection and remedy)? It should be treated as the error condition > it is, not a normal state of affairs. MAC address collisions are not uncommon. Some time NIC vendors screw up, and some times people who should know better don't do the right thing. Just yesterday I had a problem with a layer 3 switch that uses the same MAC address for all of the virtual (VLAN) IP interfaces. And then there is stuff like privacy protection by randomly selecting the lower 64 bits. The problem is that on a LAN, you can do DAD, but doing that world wide each time you connect to the network is no fun. >> I think we need at least 40 bits for the organization ID so that >> leaves just 24 bits for link-local use, > Why put location back into identity? In my view, endpoint identifiers > are 'names'. They are a flat, undifferentiated (from the network > perspective, administratively, you may want some hierarchy) identifier > space. This is going to be a problem if you want to look these up in a distributed database. We really need a hierarchy for something like this. >> So what happens when a link goes down? > Assuming you are asking about the multi-homed destination case,the > naive approach would be to have the source core/edge boundary > forwarder notice the link is down via 'traditional' methods (BGP > re-convergence, ICMP network unreachable, whatever) Obviously this stuff isn't going to be in BGP. :-) A large percentage of network problems don't generate unreachables. So we don't get to be naive here. >> Other solutions in this area provide the same benefit without >> breaking link local behavior, > How do GSE-like solutions break link local behavior? I mean autoconfiguration and similar stuff that escapes me at the moment... >>> Given the state of routing security (that is, the ability to insert >>> pretty much any prefix into the routing system) I personally do not >>> believe the latter concern is significantly worsened by something >>> like GSE and, in any event, this issue would be addressed by >>> deployment of IPSEC. >> How is IPsec going to help you if the packets are rerouted over the >> null0 interface? > Sorry, don't follow. If an attacker gets to reroute your traffic, then they presumably also get to route in into oblivion. So IPsec doesn't solve problems in the routing system. >> Don't forget about the actual failover. Also quite solvable, but not >> a trivial problem. > The difficulty in failover is detecting failover is necessary at the > source. One possible solution would be to have the alternative > locators kept with the packet in transit as an IPv6 option. Yes, Marcelo Bagnulo has a draft out on this, if I remember correctly. This helps but doesn't really solve the problem of dead layer 2 networks where the IP-speaking boxes at both ends don't see there is something wrong. >> The problem I have with GSE and its derivatives is that it is >> self-contained and doesn't provide hooks either forward or backward. > I don't understand this statement. What I mean is that you need to implement GSE on both ends before it will do you any good. 15 second explanation of MHAP: hosts use PI addresses, but these addresses are replaced with PA addresses in transit. With MHAP or something similar, you don't have to upgrade all hosts, which is better, none of the routers, which is much better, and you can also start using the PI space immediately and then move in the MHAP boxes later. That's what I mean by hooks backward. I think hooks forward are possible by not hardcoding the exact 83 bits we look at into the modified stacks but by making this more generic so we can support 160 bits or 64 bits out of 128 or whatever at some later date. >> It would be great if it could be part of a bigger picture, where we >> can upgrade from what we have today, to something a bit better, to >> GSE++, to a clean architecture where we really get to drop in new >> protocols for each layer like the OSI guys always promised we could. > I believe the first step in any reasonable evolution will be to > separate identifier from locator. Given realities of the market and > the IETF, small steps are more likely to get forward motion than giant > leaps. I'm not saying we should implement huge steps, but it would be good if the small steps we implement get us closer to a long term goal. From owner-multi6@ops.ietf.org Thu Apr 17 09:00:11 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19781 for ; Thu, 17 Apr 2003 09:00:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 196919-000M4D-00 for multi6-data@psg.com; Thu, 17 Apr 2003 13:01:31 +0000 Received: from ip166.usw12.rb1.bel.nwlink.com ([209.20.253.166] helo=ran.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 19690m-000M38-00 for multi6@ops.ietf.org; Thu, 17 Apr 2003 13:01:10 +0000 Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.14) id 19690Z-0000IR-RW; Thu, 17 Apr 2003 06:00:55 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 17 Apr 2003 06:00:55 -0700 To: Tim Chown Cc: multi6@ops.ietf.org Subject: Re: Resolving geo discussions References: <3E9D5F6A.85F93206@hursley.ibm.com> <20030417073216.GC3579@login.ecs.soton.ac.uk> Message-Id: X-Spam-Status: No, hits=-16.3 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Absolutely, and it's just 3 months to Vienna and the restoration of the > multi6 sessions at the meetings. We should have some idea soon of > what will be on the table there what are you putting on it? randy From owner-multi6@ops.ietf.org Thu Apr 17 09:34:45 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20654 for ; Thu, 17 Apr 2003 09:34:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 1969YU-000NmB-00 for multi6-data@psg.com; Thu, 17 Apr 2003 13:35:58 +0000 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 1969Y8-000NlM-00 for multi6@ops.ietf.org; Thu, 17 Apr 2003 13:35:36 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h3HDYRE64322; Thu, 17 Apr 2003 15:34:27 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Thu, 17 Apr 2003 15:34:18 +0200 Subject: Re: geo short vs long term? [Re: Geo pros and cons] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: Kurt Erik Lindqvist From: Iljitsch van Beijnum In-Reply-To: Message-Id: <4A63D015-70D9-11D7-A1F8-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On donderdag, apr 17, 2003, at 10:29 Europe/Amsterdam, Kurt Erik Lindqvist wrote: > I think the first step still is to define what the options are. Then > we can start worry about consensus. In any multiaddressing scheme, there must be a point where a single "handle", be it an address, an FQDN, a control block or what have you, is tied to two or more paths through the network. There are many ways to do this: - let the applications handle it (SMTP, DNS) - let the network layer handle it (MIP) - let the transport layer handle it (SCTP) - let a middlebox or border router handle it (MHAP) GSE isn't easily classified here as transport, network and border routers all need to play their part. I think we can agree that having the applications do it isn't good enough for many applications as sessions don't survive a rehoming event. Network layer has the advantage it is presumably easy to implement. Transport layer has the advantage that it already has the end-to-end state which makes failover easier and doesn't pollute the architecture by introducing state elsewhere. Middlebox/border router has the advantage the number of boxes that need to be upgraded is very small. These are our basic choices. The problem is that each of the advantages and disadvantages will be appreciated differently by different users. Enterprise users want central policy control, home users and mobile users want flexibility no no reliance on provider cooperation. Some people need multihoming in IPv6 yesterday, others haven't even heard of IPv6 in the first place. If possible, I think the best choice is not to choose at all, but make the mechanism generic enough that it can work anywhere. From owner-multi6@ops.ietf.org Thu Apr 17 10:01:20 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21300 for ; Thu, 17 Apr 2003 10:01:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 1969yC-000PGt-00 for multi6-data@psg.com; Thu, 17 Apr 2003 14:02:32 +0000 Received: from pop-ls-09-1-dialup-247.freesurf.ch ([194.230.235.247] helo=dhcp1.se.kurtis.pp.se) by psg.com with esmtp (Exim 3.36 #1) id 1969xp-000PFE-00 for multi6@ops.ietf.org; Thu, 17 Apr 2003 14:02:09 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp1.se.kurtis.pp.se (8.12.9/8.10.2) with ESMTP id h3HE3hBQ002210; Thu, 17 Apr 2003 16:03:44 +0200 (CEST) Date: Thu, 17 Apr 2003 13:23:02 +0200 Subject: Re: Resolving geo discussions Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: Tim Chown From: Kurt Erik Lindqvist In-Reply-To: <20030417073216.GC3579@login.ecs.soton.ac.uk> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On torsdag, apr 17, 2003, at 09:32 Europe/Stockholm, Tim Chown wrote: > On Wed, Apr 16, 2003 at 03:49:30PM +0200, Brian E Carpenter wrote: >> I agree. Actually I am hoping to see more from the co-chairs, >> not less. > > Absolutely, and it's just 3 months to Vienna and the restoration of the > multi6 sessions at the meetings. We should have some idea soon of > what will be on the table there and Sean and Kurtis' input here to > shape that is very important. > Me and Sean are privately discussing what we thing will be the best way to organize the meeting in Vienna - stay tuned. - kurtis - From owner-multi6@ops.ietf.org Thu Apr 17 13:09:36 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28969 for ; Thu, 17 Apr 2003 13:09:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 196Csq-00090p-00 for multi6-data@psg.com; Thu, 17 Apr 2003 17:09:12 +0000 Received: from tele2-1-1-dialup-244.freesurf.ch ([194.230.196.244] helo=dhcp1.se.kurtis.pp.se) by psg.com with esmtp (Exim 3.36 #1) id 196CsC-0008yI-00 for multi6@ops.ietf.org; Thu, 17 Apr 2003 17:08:33 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp1.se.kurtis.pp.se (8.12.9/8.10.2) with ESMTP id h3HE1tBQ002149; Thu, 17 Apr 2003 16:01:57 +0200 (CEST) Date: Thu, 17 Apr 2003 13:23:02 +0200 Subject: Re: Resolving geo discussions Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: Tim Chown From: Kurt Erik Lindqvist In-Reply-To: <20030417073216.GC3579@login.ecs.soton.ac.uk> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On torsdag, apr 17, 2003, at 09:32 Europe/Stockholm, Tim Chown wrote: > On Wed, Apr 16, 2003 at 03:49:30PM +0200, Brian E Carpenter wrote: >> I agree. Actually I am hoping to see more from the co-chairs, >> not less. > > Absolutely, and it's just 3 months to Vienna and the restoration of the > multi6 sessions at the meetings. We should have some idea soon of > what will be on the table there and Sean and Kurtis' input here to > shape that is very important. > Me and Sean are privately discussing what we thing will be the best way to organize the meeting in Vienna - stay tuned. - kurtis - From owner-multi6@ops.ietf.org Thu Apr 17 13:25:38 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29369 for ; Thu, 17 Apr 2003 13:25:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 196DAQ-0009Zv-00 for multi6-data@psg.com; Thu, 17 Apr 2003 17:27:22 +0000 Received: from dmz2.procket.com ([65.174.124.37]) by psg.com with esmtp (Exim 3.36 #1) id 196DA4-0009Zb-00 for multi6@ops.ietf.org; Thu, 17 Apr 2003 17:27:00 +0000 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id E76343444A; Thu, 17 Apr 2003 09:40:46 -0700 (PDT) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h3HHQxYB023670; Thu, 17 Apr 2003 10:26:59 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: geo short vs long term? [Re: Geo pros and cons] Date: Thu, 17 Apr 2003 10:26:58 -0700 Message-ID: Thread-Topic: geo short vs long term? [Re: Geo pros and cons] Thread-Index: AcME6M8Hp6Bw8FDGQbGCjOIcXo4q7wAHXV+w From: "Tony Li" To: "Iljitsch van Beijnum" , "Kurt Erik Lindqvist" Cc: X-Spam-Status: No, hits=-6.6 required=5.0 tests=BAYES_01 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA29369 | In any multiaddressing scheme, there must be a point where | a single | "handle", be it an address, an FQDN, a control block or | what have you, | is tied to two or more paths through the network. There | are many ways | to do this: | | - let the applications handle it (SMTP, DNS) | - let the network layer handle it (MIP) | - let the transport layer handle it (SCTP) | - let a middlebox or border router handle it (MHAP) | | GSE isn't easily classified here as transport, network and border | routers all need to play their part. ? GSE would require the middlebox to handle it, plus changes to DNS and modifications to transport protocols to use only the identifier as part of the pseudoheader. Tony From owner-multi6@ops.ietf.org Thu Apr 17 13:45:21 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29951 for ; Thu, 17 Apr 2003 13:45:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 196DTg-000ARj-00 for multi6-data@psg.com; Thu, 17 Apr 2003 17:47:16 +0000 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 196DTK-000AQx-00 for multi6@ops.ietf.org; Thu, 17 Apr 2003 17:46:54 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h3HHjjE64795; Thu, 17 Apr 2003 19:45:45 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Thu, 17 Apr 2003 19:45:36 +0200 Subject: Re: geo short vs long term? [Re: Geo pros and cons] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: To: "Tony Li" From: Iljitsch van Beijnum In-Reply-To: Message-Id: <6558D45A-70FC-11D7-A1F8-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On donderdag, apr 17, 2003, at 19:26 Europe/Amsterdam, Tony Li wrote: > | GSE isn't easily classified here as transport, network and border > | routers all need to play their part. > ? GSE would require the middlebox to handle it, plus changes to DNS > and modifications to transport protocols to use only the identifier > as part of the pseudoheader. Ignoring the DNS for a moment... I think the original GSE called for the border routers to rewrite packets, but this could nearly as easily happen in a middlebox, or even in the host itself. I guess it would be possible to do this without changing the network layer but I wouldn't bet on it. From owner-multi6@ops.ietf.org Thu Apr 17 13:57:18 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00350 for ; Thu, 17 Apr 2003 13:57:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 196Df7-000B14-00 for multi6-data@psg.com; Thu, 17 Apr 2003 17:59:05 +0000 Received: from mail5.microsoft.com ([131.107.3.121]) by psg.com with esmtp (Exim 3.36 #1) id 196Dem-000B0N-00 for multi6@ops.ietf.org; Thu, 17 Apr 2003 17:58:44 +0000 Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Thu, 17 Apr 2003 10:58:40 -0700 Received: from 157.54.6.150 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 17 Apr 2003 10:58:40 -0700 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3789.0); Thu, 17 Apr 2003 10:58:40 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 17 Apr 2003 10:58:39 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3788.0); Thu, 17 Apr 2003 10:58:38 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6851.8 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: old GSE idea Date: Thu, 17 Apr 2003 10:58:38 -0700 Message-ID: Thread-Topic: old GSE idea Thread-Index: AcME2h38XOY9LWpxS1exY+AwboxoDwAMG/Jg From: "Christian Huitema" To: "Iljitsch van Beijnum" , "David Conrad" Cc: "Multi6 Working Group" X-OriginalArrivalTime: 17 Apr 2003 17:58:39.0204 (UTC) FILETIME=[F99B9240:01C3050A] X-Spam-Status: No, hits=-6.6 required=5.0 tests=BAYES_01 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA00350 Even if we solved MAC address collision on a single link, you have to remember that a host can be multi-homed to several interfaces. Whatever we do to support the survival of TCP connections should also work when the traffic moves from interface A to interface B, e.g. from 802.11 to GPRS. In such cases, the two interfaces are likely to belong to different sites, and are like to use different interface identifiers (since they indeed are different interfaces). The solution of "just using 64 bits" will not work there. -- Christian Huitema From owner-multi6@ops.ietf.org Thu Apr 17 13:57:40 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00413 for ; Thu, 17 Apr 2003 13:57:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 196Dfs-000B2T-00 for multi6-data@psg.com; Thu, 17 Apr 2003 17:59:52 +0000 Received: from dmz2.procket.com ([65.174.124.37]) by psg.com with esmtp (Exim 3.36 #1) id 196DfW-000B1c-00 for multi6@ops.ietf.org; Thu, 17 Apr 2003 17:59:30 +0000 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id E02713444A; Thu, 17 Apr 2003 10:13:17 -0700 (PDT) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h3HHxTYB025285; Thu, 17 Apr 2003 10:59:29 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: geo short vs long term? [Re: Geo pros and cons] Date: Thu, 17 Apr 2003 10:59:29 -0700 Message-ID: Thread-Topic: geo short vs long term? [Re: Geo pros and cons] Thread-Index: AcMFCVovEg7mXZt6Ssujvktk4A2BWAAAXGPA From: "Tony Li" To: "Iljitsch van Beijnum" Cc: X-Spam-Status: No, hits=-6.6 required=5.0 tests=BAYES_01 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA00413 | Ignoring the DNS for a moment... I think the original GSE | called for | the border routers to rewrite packets, but this could | nearly as easily | happen in a middlebox, or even in the host itself. While those locations are not impossible, the most natural place for it is in the border router or the provider edge router. | I guess it would be possible to do this without changing | the network | layer but I wouldn't bet on it. I don't believe that it's a requirement to change the syntax of the network layer header. The semantics, of course, must change. IMHO, this is a good thing. Tony From owner-multi6@ops.ietf.org Thu Apr 17 14:19:21 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00934 for ; Thu, 17 Apr 2003 14:19:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 196E07-000C6i-00 for multi6-data@psg.com; Thu, 17 Apr 2003 18:20:47 +0000 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 196Dzk-000C4t-00 for multi6@ops.ietf.org; Thu, 17 Apr 2003 18:20:25 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h3HIJFE64903; Thu, 17 Apr 2003 20:19:15 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Thu, 17 Apr 2003 20:19:06 +0200 Subject: Re: geo short vs long term? [Re: Geo pros and cons] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: To: "Tony Li" From: Iljitsch van Beijnum In-Reply-To: Message-Id: <13A98462-7101-11D7-A1F8-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On donderdag, apr 17, 2003, at 19:59 Europe/Amsterdam, Tony Li wrote: > | Ignoring the DNS for a moment... I think the original GSE > | called for > | the border routers to rewrite packets, but this could > | nearly as easily > | happen in a middlebox, or even in the host itself. > While those locations are not impossible, the most natural place > for it is in the border router or the provider edge router. So how would intra-site routing work? By clearing the 45 routing bits when the packet arrives at the edge? > | I guess it would be possible to do this without changing > | the network layer but I wouldn't bet on it. > I don't believe that it's a requirement to change the syntax > of the network layer header. The semantics, of course, must > change. IMHO, this is a good thing. Why is this good? In earlier discussions, I think we (that is, at least some of us) reached the conclusion that a 16+16 mechanism, where we have something that looks enough like a regular IPv6 unicast address to be forwarded by existing routers, would be similar in nature, but easier to deploy than 8+8 and presumably also 5.625+6.375. From owner-multi6@ops.ietf.org Thu Apr 17 15:17:49 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04032 for ; Thu, 17 Apr 2003 15:17:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 196EuS-000Efq-00 for multi6-data@psg.com; Thu, 17 Apr 2003 19:19:00 +0000 Received: from dmz1.procket.com ([65.174.124.36]) by psg.com with esmtp (Exim 3.36 #1) id 196Eu6-000EfL-00 for multi6@ops.ietf.org; Thu, 17 Apr 2003 19:18:38 +0000 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id 20A5723C6E; Thu, 17 Apr 2003 12:07:55 -0700 (PDT) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h3HJIbYB028386; Thu, 17 Apr 2003 12:18:37 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: geo short vs long term? [Re: Geo pros and cons] Date: Thu, 17 Apr 2003 12:18:37 -0700 Message-ID: Thread-Topic: geo short vs long term? [Re: Geo pros and cons] Thread-Index: AcMFDgmIP4pmMDozRPOcaWOz5xsEoAABzRkw From: "Tony Li" To: "Iljitsch van Beijnum" Cc: X-Spam-Status: No, hits=-6.6 required=5.0 tests=BAYES_01 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA04032 | So how would intra-site routing work? By clearing the 45 | routing bits | when the packet arrives at the edge? That would be one way. Note that you can also salt the routing bits (however many we choose) with any other constant and that will work too. This can be used to make it easier to migrate. Suppose that you have a site that is initially singly homed and already has a fixed address. By simply swapping the routing bits at the border router, you can now renumber the entire site trivially. You can also multihome, again by only tweaking the border routers. All local configuration can remain the same. | > | I guess it would be possible to do this without changing | > | the network layer but I wouldn't bet on it. | | > I don't believe that it's a requirement to change the syntax | > of the network layer header. The semantics, of course, must | > change. IMHO, this is a good thing. | | Why is this good? Because today's semantics are "locator === identifier" | In earlier discussions, I think we (that is, at least some of us) | reached the conclusion that a 16+16 mechanism, where we | have something | that looks enough like a regular IPv6 unicast address to | be forwarded | by existing routers, would be similar in nature, but | easier to deploy | than 8+8 and presumably also 5.625+6.375. Yes, but given the above argument about swapping all of the routing bits, I'm not sure I agree. It seems to me that a border router that swaps just routing bits or swaps all 128 bits isn't that big a difference. Tony From owner-multi6@ops.ietf.org Thu Apr 17 15:29:01 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04355 for ; Thu, 17 Apr 2003 15:29:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 196F5F-000FDt-00 for multi6-data@psg.com; Thu, 17 Apr 2003 19:30:09 +0000 Received: from host217-37-202-105.in-addr.btopenworld.com ([217.37.202.105] helo=ab.use.net) by psg.com with esmtp (Exim 3.36 #1) id 196F4r-000FCH-00 for multi6@ops.ietf.org; Thu, 17 Apr 2003 19:29:45 +0000 Received: from ab.use.net (conf.use.net [217.37.202.109]) by ab.use.net (Postfix) with ESMTP id E95E839741; Thu, 17 Apr 2003 19:29:42 +0000 (GMT) Date: Thu, 17 Apr 2003 20:29:42 +0100 Subject: Re: old GSE idea Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Multi6 Working Group To: "Christian Huitema" From: Sean Doran In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Thursday, Apr 17, 2003, at 18:58 Europe/London, Christian Huitema wrote: > Even if we solved MAC address collision on a single link, you have to > remember that a host can be multi-homed to several interfaces. Or virtual/pseudo-interfaces, for that matter. Hosts can do tunnels, VLANs, you name it. > Whatever > we do to support the survival of TCP connections should also work when > the traffic moves from interface A to interface B, e.g. from 802.11 to > GPRS The case of moving traffic from a single working interface to a different single working interface is in many ways easier than moving traffic across multiple working interfaces simultaneously. We need to support hosts which are multiply connected within the same local network infrastructure concurrently (and deal with failures of some/all of those connections), as well as those which are simultaneously connected to entirely different networks with entirely separate and possibly mutually hostile administration (and deal with failures of some/all of those connections), and just for fun a mix of the two. It would be interesting to see if we could be more ambitious and try to deal with movement/multihoming of things with finer granularity. The multiported host model is amenable to virtualization, but do we want to/can we have an identifier bound to a particular *service* that may migrate around a network independently of other services which are, at any given moment, sharing a host (virtual or real) with it? Can we/do we want to aggregate several services (or clients thereof) and have that aggregate be mobile/multihomed? Yes, because that's fundamentally what a host is, but can we/do we want several *independent* aggregates of things within a given host? Sure: that's an interesting way of doing virtualization of hosts. But what about with granularity at a level other than a host or virtual host? That is, (assuming process migration is feasible) can I move my voice over ip service, AIM, ssh sessions, X server, and so forth from one part of the network to another without moving the host these are sharing with an IMAP service, ntpd, and so on? Most of these questions go to the semantics of the lower-order bits, how they bind with one or more sets of higher-order bits, and how they are acquired initially. Sean. From owner-multi6@ops.ietf.org Thu Apr 17 15:34:10 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04652 for ; Thu, 17 Apr 2003 15:34:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 196FB4-000FWx-00 for multi6-data@psg.com; Thu, 17 Apr 2003 19:36:10 +0000 Received: from mail1.microsoft.com ([131.107.3.125]) by psg.com with esmtp (Exim 3.36 #1) id 196FAj-000FWZ-00 for multi6@ops.ietf.org; Thu, 17 Apr 2003 19:35:49 +0000 Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.6659); Thu, 17 Apr 2003 12:35:48 -0700 Received: from 157.54.6.150 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 17 Apr 2003 12:35:48 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3789.0); Thu, 17 Apr 2003 12:35:48 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 17 Apr 2003 12:35:47 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.82]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3788.0); Thu, 17 Apr 2003 12:35:47 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6851.8 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: old GSE idea Date: Thu, 17 Apr 2003 12:35:46 -0700 Message-ID: Thread-Topic: old GSE idea Thread-Index: AcMFF7jSiGIWm5rnS5+MgBu5/YczAwAAHcnw From: "Christian Huitema" To: "Sean Doran" Cc: "Multi6 Working Group" X-OriginalArrivalTime: 17 Apr 2003 19:35:47.0645 (UTC) FILETIME=[8BA116D0:01C30518] X-Spam-Status: No, hits=-9.8 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA04652 > Most of these questions go to the semantics of the lower-order bits, > how they bind with one or more sets of higher-order bits, and how > they are acquired initially. Sure. Another issue is privacy. I don't necessarily want different ISP to be able to correlate that two traffic flows do in fact originate from the same hosts. In fact, privacy advocates would go ballistic if we mandated that. -- Christian Huitema From owner-multi6@ops.ietf.org Thu Apr 17 17:29:32 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08901 for ; Thu, 17 Apr 2003 17:29:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 196GwF-000LVf-00 for multi6-data@psg.com; Thu, 17 Apr 2003 21:28:59 +0000 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by psg.com with esmtp (Exim 3.36 #1) id 196Gvt-000LV0-00 for multi6@ops.ietf.org; Thu, 17 Apr 2003 21:28:37 +0000 Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id WAA23582 for ; Thu, 17 Apr 2003 22:28:36 +0100 (BST) Received: from login.ecs.soton.ac.uk (login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3p2/8.9.3) with ESMTP id WAA28617 for ; Thu, 17 Apr 2003 22:28:35 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h3HLSZm14240 for multi6@ops.ietf.org; Thu, 17 Apr 2003 22:28:35 +0100 Date: Thu, 17 Apr 2003 22:28:35 +0100 From: Tim Chown To: multi6@ops.ietf.org Subject: Re: Resolving geo discussions Message-ID: <20030417212835.GH12026@login.ecs.soton.ac.uk> Mail-Followup-To: multi6@ops.ietf.org References: <3E9D5F6A.85F93206@hursley.ibm.com> <20030417073216.GC3579@login.ecs.soton.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-38.8 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MUTT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk On Thu, Apr 17, 2003 at 06:00:55AM -0700, Randy Bush wrote: > > Absolutely, and it's just 3 months to Vienna and the restoration of the > > multi6 sessions at the meetings. We should have some idea soon of > > what will be on the table there > > what are you putting on it? I predict a bottle of water, glasses and a microphone or two. First we need to decide what to do about the current (only) multi6 I-D. It needs to be either signed off or removed and replaced with a less restrictive (perhaps more open minded) set of requirements. I like Christian's proposal. It offers what appears to be a sane path to at least solve some useful classes of scenario. And we have this as a good proposal in spite of no agreed requirements document, so I think we can also put forward other potential solutions too. I think if we can set an agenda now, and decide what is on that table, we can maybe have some fruitful, focused discussion before Vienna. Is MHAP on the table? GSE? HIP? ....? Some solutions may not fly, but we should at least ensure they get a good airing in an official IETF session rather than just in the ipv6mh meetings, as (very) good as they are. At least let's make sure there is a meeting in Vienna. It seems a lot of people just assumed there would be a San Francisco multi6, given it seen as the last Big Issue for IPv6 by a fair few people. Let's even consider getting some possible solutions on board as WG items in July. Tim From owner-multi6@ops.ietf.org Thu Apr 17 18:04:37 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10305 for ; Thu, 17 Apr 2003 18:04:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 196HWb-000Nik-00 for multi6-data@psg.com; Thu, 17 Apr 2003 22:06:33 +0000 Received: from ip166.usw12.rb1.bel.nwlink.com ([209.20.253.166] helo=ran.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 196HVV-000Nb2-00 for multi6@ops.ietf.org; Thu, 17 Apr 2003 22:05:26 +0000 Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.14) id 196HVM-0000oW-Sz; Thu, 17 Apr 2003 15:05:16 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 17 Apr 2003 15:05:16 -0700 To: Tim Chown Cc: multi6@ops.ietf.org Subject: Re: Resolving geo discussions References: <3E9D5F6A.85F93206@hursley.ibm.com> <20030417073216.GC3579@login.ecs.soton.ac.uk> <20030417212835.GH12026@login.ecs.soton.ac.uk> Message-Id: X-Spam-Status: No, hits=-16.3 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > At least let's make sure there is a meeting in Vienna. It seems a lot > of people just assumed there would be a San Francisco multi6, given it > seen as the last Big Issue for IPv6 by a fair few people. no solid content, no agenda. no agenda, no meeting. randy From owner-multi6@ops.ietf.org Thu Apr 17 18:45:58 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13047 for ; Thu, 17 Apr 2003 18:45:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 196I97-0000EQ-00 for multi6-data@psg.com; Thu, 17 Apr 2003 22:46:21 +0000 Received: from dmz2.procket.com ([65.174.124.37]) by psg.com with esmtp (Exim 3.36 #1) id 196I8l-0000Ds-00 for multi6@ops.ietf.org; Thu, 17 Apr 2003 22:45:59 +0000 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id CE9A53445D; Thu, 17 Apr 2003 14:59:45 -0700 (PDT) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h3HMjwYB007565; Thu, 17 Apr 2003 15:45:59 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Resolving geo discussions Date: Thu, 17 Apr 2003 15:45:58 -0700 Message-ID: Thread-Topic: Resolving geo discussions Thread-Index: AcMFL2hGI3A4V8ShQGetFPxeSkTTigAA389w From: "Tony Li" To: "Randy Bush" , "Tim Chown" Cc: X-Spam-Status: No, hits=-6.6 required=5.0 tests=BAYES_01 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA13047 I'm sorry but this is a crock Randy, and you know it. The IETF should be about discussion and collaboration, not about marketing presentations. Or at least that's what you used to say... Tony | -----Original Message----- | From: Randy Bush [mailto:randy@psg.com] | Sent: Thursday, April 17, 2003 3:05 PM | To: Tim Chown | Cc: multi6@ops.ietf.org | Subject: Re: Resolving geo discussions | | | > At least let's make sure there is a meeting in Vienna. | It seems a lot | > of people just assumed there would be a San Francisco | multi6, given it | > seen as the last Big Issue for IPv6 by a fair few people. | | no solid content, no agenda. no agenda, no meeting. | | randy | | | From owner-multi6@ops.ietf.org Thu Apr 17 19:59:45 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14628 for ; Thu, 17 Apr 2003 19:59:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 196JIx-0004t0-00 for multi6-data@psg.com; Fri, 18 Apr 2003 00:00:35 +0000 Received: from ip166.usw12.rb1.bel.nwlink.com ([209.20.253.166] helo=ran.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 196JIZ-0004sH-00 for multi6@ops.ietf.org; Fri, 18 Apr 2003 00:00:13 +0000 Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.14) id 196JIQ-0000t2-BM; Thu, 17 Apr 2003 17:00:02 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 17 Apr 2003 17:00:01 -0700 To: "Tony Li" Cc: "Tim Chown" , Subject: RE: Resolving geo discussions References: Message-Id: X-Spam-Status: No, hits=-13.1 required=5.0 tests=BAYES_01,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> no solid content, no agenda. no agenda, no meeting. > I'm sorry but this is a crock Randy, and you know it. > > The IETF should be about discussion and collaboration, > not about marketing presentations. Or at least that's > what you used to say... i guess, being in a startup, you might think that 'solid' means marketing presentations. i still don't. randy From owner-multi6@ops.ietf.org Thu Apr 17 20:01:12 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14678 for ; Thu, 17 Apr 2003 20:01:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 196JLc-00053W-00 for multi6-data@psg.com; Fri, 18 Apr 2003 00:03:20 +0000 Received: from dmz1.procket.com ([65.174.124.36]) by psg.com with esmtp (Exim 3.36 #1) id 196JLG-00050S-00 for multi6@ops.ietf.org; Fri, 18 Apr 2003 00:02:58 +0000 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id 9154F23C41; Thu, 17 Apr 2003 16:52:14 -0700 (PDT) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h3I02vYB011104; Thu, 17 Apr 2003 17:02:57 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Resolving geo discussions Date: Thu, 17 Apr 2003 17:02:57 -0700 Message-ID: Thread-Topic: Resolving geo discussions Thread-Index: AcMFPYMY4MGc4GDmQRGCCbmu8+T2egAACYng From: "Tony Li" To: "Randy Bush" Cc: "Tim Chown" , X-Spam-Status: No, hits=-6.6 required=5.0 tests=BAYES_01 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id UAA14678 You were expecting a polished RFC? Look, we need to have an architectural discussion. We need to sit, BS together and draw lots of pictures on white boards. Can we do that, or do we have to submit an Internet Draft first? Tony | -----Original Message----- | From: Randy Bush [mailto:randy@psg.com] | Sent: Thursday, April 17, 2003 5:00 PM | To: Tony Li | Cc: Tim Chown; multi6@ops.ietf.org | Subject: RE: Resolving geo discussions | | | >> no solid content, no agenda. no agenda, no meeting. | | > I'm sorry but this is a crock Randy, and you know it. | > | > The IETF should be about discussion and collaboration, | > not about marketing presentations. Or at least that's | > what you used to say... | | i guess, being in a startup, you might think that 'solid' | means marketing presentations. i still don't. | | | | randy | | From owner-multi6@ops.ietf.org Thu Apr 17 20:55:30 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15694 for ; Thu, 17 Apr 2003 20:55:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 196KBV-00094f-00 for multi6-data@psg.com; Fri, 18 Apr 2003 00:56:57 +0000 Received: from ip166.usw12.rb1.bel.nwlink.com ([209.20.253.166] helo=ran.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 196KB7-00090g-00 for multi6@ops.ietf.org; Fri, 18 Apr 2003 00:56:35 +0000 Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.14) id 196KB3-0000vW-Ra; Thu, 17 Apr 2003 17:56:29 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 17 Apr 2003 17:56:29 -0700 To: Tony Li Cc: multi6@ops.ietf.org Subject: RE: Resolving geo discussions References: Message-Id: X-Spam-Status: No, hits=-15.5 required=5.0 tests=BAYES_10,QUOTED_EMAIL_TEXT,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Look, we need to have an architectural discussion. We need > to sit, BS together and draw lots of pictures on white > boards. Can we do that, or do we have to submit an Internet > Draft first? i agree that this is one activity this wg strongly needs. but is a meeting at an ietf general meeting the right place for this? i do not remember white (or black or green) boards in an ietf general meeting. not that i don't think our meetings might benefit from such, but i am the one who the secretariat will tell to put the request where the sun don't shine. one kind of interesting plan might be to see if i/we can find some venue with white-boards for sunday, and have a wg meeting during the week to widen the audience for the result thereof. current ietf culture is to call this a design team meeting, and use of that phrase may help grease the administrivia. i also suspect that this working group might get more done if the filibustering by folk riding lame or long-dead hobby horses would dismount, take a break, go into the saloon for a beer, and let others talk too. randy From owner-multi6@ops.ietf.org Thu Apr 17 21:20:43 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16060 for ; Thu, 17 Apr 2003 21:20:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 196KZt-000AOI-00 for multi6-data@psg.com; Fri, 18 Apr 2003 01:22:09 +0000 Received: from dmz2.procket.com ([65.174.124.37]) by psg.com with esmtp (Exim 3.36 #1) id 196KZX-000ANj-00 for multi6@ops.ietf.org; Fri, 18 Apr 2003 01:21:47 +0000 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id D824B3445D; Thu, 17 Apr 2003 17:35:34 -0700 (PDT) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h3I1LlYB013744; Thu, 17 Apr 2003 18:21:47 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Resolving geo discussions Date: Thu, 17 Apr 2003 18:21:46 -0700 Message-ID: Thread-Topic: Resolving geo discussions Thread-Index: AcMFRV82Z5LnwinlTIO1wFq5YPFN1QAA1oEw From: "Tony Li" To: "Randy Bush" Cc: X-Spam-Status: No, hits=-6.6 required=5.0 tests=BAYES_01 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id VAA16060 No different technology is necessary. A laptop, projector and appropriate drawing software can be had. Just call the meeting. I'll take your last paragraph as a directive to shut the hell up. Tony | -----Original Message----- | From: Randy Bush [mailto:randy@psg.com] | Sent: Thursday, April 17, 2003 5:56 PM | To: Tony Li | Cc: multi6@ops.ietf.org | Subject: RE: Resolving geo discussions | | | > Look, we need to have an architectural discussion. We need | > to sit, BS together and draw lots of pictures on white | > boards. Can we do that, or do we have to submit an Internet | > Draft first? | | i agree that this is one activity this wg strongly needs. but is a | meeting at an ietf general meeting the right place for this? i do | not remember white (or black or green) boards in an ietf general | meeting. not that i don't think our meetings might benefit from | such, but i am the one who the secretariat will tell to put the | request where the sun don't shine. | | one kind of interesting plan might be to see if i/we can find | some venue with white-boards for sunday, and have a wg meeting | during the week to widen the audience for the result thereof. | current ietf culture is to call this a design team meeting, and use | of that phrase may help grease the administrivia. | | i also suspect that this working group might get more done if the | filibustering by folk riding lame or long-dead hobby horses would | dismount, take a break, go into the saloon for a beer, and let | others talk too. | | randy | | From owner-multi6@ops.ietf.org Thu Apr 17 21:47:15 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16479 for ; Thu, 17 Apr 2003 21:47:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 196Kzs-000BXp-00 for multi6-data@psg.com; Fri, 18 Apr 2003 01:49:00 +0000 Received: from ip166.usw12.rb1.bel.nwlink.com ([209.20.253.166] helo=ran.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 196KzV-000BWC-00 for multi6@ops.ietf.org; Fri, 18 Apr 2003 01:48:38 +0000 Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.14) id 196KzN-00012b-4E; Thu, 17 Apr 2003 18:48:29 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 17 Apr 2003 18:48:28 -0700 To: "Tony Li" Cc: Subject: RE: Resolving geo discussions References: Message-Id: X-Spam-Status: No, hits=-16.3 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > No different technology is necessary. A laptop, projector and > appropriate drawing software can be had. Just call the meeting. i don't find that good for multiple pepole to 'argue over' something. you californians may better know how to share a laptop. :-) > I'll take your last paragraph as a directive to shut the hell up. it was not at all aimed at you. you, sean, kurtis, and others have been trying very hard to focus this chaos. it is appreciated. it is the lack of focus i am not inclined to go out of my way to support. randy From owner-multi6@ops.ietf.org Thu Apr 17 22:26:54 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17168 for ; Thu, 17 Apr 2003 22:26:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 196Lbf-000Cvn-00 for multi6-data@psg.com; Fri, 18 Apr 2003 02:28:03 +0000 Received: from zmamail05.zma.compaq.com ([161.114.64.105]) by psg.com with esmtp (Exim 3.36 #1) id 196LbI-000Cv7-00 for multi6@ops.ietf.org; Fri, 18 Apr 2003 02:27:40 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id DCD235DCC; Thu, 17 Apr 2003 22:27:39 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 17 Apr 2003 22:27:39 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Resolving geo discussions Date: Thu, 17 Apr 2003 22:27:39 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03241135@tayexc13.americas.cpqcorp.net> Thread-Topic: Resolving geo discussions Thread-Index: AcMFRV82Z5LnwinlTIO1wFq5YPFN1QAA1oEwAAIztPA= From: "Bound, Jim" To: "Tony Li" , "Randy Bush" Cc: X-OriginalArrivalTime: 18 Apr 2003 02:27:39.0812 (UTC) FILETIME=[153A8640:01C30552] X-Spam-Status: No, hits=-9.8 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id WAA17168 Well don't do that Tony that would be bogus your asking the right questions. Why can't we develop an agenda with content and use that as discussion content and request an agenda. If that don't work then we have a problem with the IETF process. Also if this becomes to painful in the IETF here we go to ITU or other standards body to look at our work. /jim > -----Original Message----- > From: Tony Li [mailto:Tony.Li@procket.com] > Sent: Thursday, April 17, 2003 9:22 PM > To: Randy Bush > Cc: multi6@ops.ietf.org > Subject: RE: Resolving geo discussions > > > > > No different technology is necessary. A laptop, projector > and appropriate drawing software can be had. Just call the meeting. > > I'll take your last paragraph as a directive to shut the hell up. > > Tony > > > | -----Original Message----- > | From: Randy Bush [mailto:randy@psg.com] > | Sent: Thursday, April 17, 2003 5:56 PM > | To: Tony Li > | Cc: multi6@ops.ietf.org > | Subject: RE: Resolving geo discussions > | > | > | > Look, we need to have an architectural discussion. We need > | > to sit, BS together and draw lots of pictures on white > | > boards. Can we do that, or do we have to submit an Internet > | > Draft first? > | > | i agree that this is one activity this wg strongly > needs. but is a > | meeting at an ietf general meeting the right place for > this? i do > | not remember white (or black or green) boards in an ietf general > | meeting. not that i don't think our meetings might benefit from > | such, but i am the one who the secretariat will tell to put the > | request where the sun don't shine. > | > | one kind of interesting plan might be to see if i/we can find > | some venue with white-boards for sunday, and have a wg meeting > | during the week to widen the audience for the result thereof. > | current ietf culture is to call this a design team > meeting, and use > | of that phrase may help grease the administrivia. > | > | i also suspect that this working group might get more done if the > | filibustering by folk riding lame or long-dead hobby horses would > | dismount, take a break, go into the saloon for a beer, and let > | others talk too. > | > | randy > | > | > > From owner-multi6@ops.ietf.org Thu Apr 17 22:52:53 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17676 for ; Thu, 17 Apr 2003 22:52:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 196M1b-000ECI-00 for multi6-data@psg.com; Fri, 18 Apr 2003 02:54:51 +0000 Received: from ip166.usw12.rb1.bel.nwlink.com ([209.20.253.166] helo=ran.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 196M0a-000EAG-00 for multi6@ops.ietf.org; Fri, 18 Apr 2003 02:53:49 +0000 Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.14) id 196M0F-00018Y-5K; Thu, 17 Apr 2003 19:53:27 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 17 Apr 2003 19:53:26 -0700 To: "Bound, Jim" Cc: "Tony Li" , Subject: RE: Resolving geo discussions References: <9C422444DE99BC46B3AD3C6EAFC9711B03241135@tayexc13.americas.cpqcorp.net> Message-Id: X-Spam-Status: No, hits=-16.3 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why can't we develop an agenda with content and use that as discussion > content and request an agenda. good question. that is THE question, and the lack thereof is why there have been no meetings. randy From owner-multi6@ops.ietf.org Fri Apr 18 00:13:35 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19069 for ; Fri, 18 Apr 2003 00:13:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 196NGa-000HFI-00 for multi6-data@psg.com; Fri, 18 Apr 2003 04:14:24 +0000 Received: from zmamail03.zma.compaq.com ([161.114.64.103]) by psg.com with esmtp (Exim 3.36 #1) id 196NG5-000HD6-00 for multi6@ops.ietf.org; Fri, 18 Apr 2003 04:13:53 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id B6EA81388; Fri, 18 Apr 2003 00:13:52 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Fri, 18 Apr 2003 00:13:52 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Resolving geo discussions Date: Fri, 18 Apr 2003 00:13:52 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03241138@tayexc13.americas.cpqcorp.net> Thread-Topic: Resolving geo discussions Thread-Index: AcMFRV82Z5LnwinlTIO1wFq5YPFN1QAA1oEwAAIztPAAA5aEEA== From: "Bound, Jim" To: "Tony Li" , "Randy Bush" Cc: X-OriginalArrivalTime: 18 Apr 2003 04:13:52.0640 (UTC) FILETIME=[EBBAE800:01C30560] X-Spam-Status: No, hits=-9.8 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id AAA19069 Also I speak out of turn as I most likely will not be at the July IETF as I intend to ride my Harley Davidson across the U.S. all of July and not even take my laptop, and might not even come back and go be a logger and live on a diet of very red meat (no carbs) and rock n roll :--) But not 100% yet but I will always recall multi6 and wonder if it got figured out :---) /jim > -----Original Message----- > From: Bound, Jim > Sent: Thursday, April 17, 2003 10:28 PM > To: Tony Li; Randy Bush > Cc: multi6@ops.ietf.org > Subject: RE: Resolving geo discussions > > > Well don't do that Tony that would be bogus your asking the > right questions. > > Why can't we develop an agenda with content and use that as > discussion content and request an agenda. If that don't work > then we have a problem with the IETF process. > > Also if this becomes to painful in the IETF here we go to ITU > or other standards body to look at our work. > > /jim > > > -----Original Message----- > > From: Tony Li [mailto:Tony.Li@procket.com] > > Sent: Thursday, April 17, 2003 9:22 PM > > To: Randy Bush > > Cc: multi6@ops.ietf.org > > Subject: RE: Resolving geo discussions > > > > > > > > > > No different technology is necessary. A laptop, projector > > and appropriate drawing software can be had. Just call the meeting. > > > > I'll take your last paragraph as a directive to shut the hell up. > > > > Tony > > > > > > | -----Original Message----- > > | From: Randy Bush [mailto:randy@psg.com] > > | Sent: Thursday, April 17, 2003 5:56 PM > > | To: Tony Li > > | Cc: multi6@ops.ietf.org > > | Subject: RE: Resolving geo discussions > > | > > | > > | > Look, we need to have an architectural discussion. We need > > | > to sit, BS together and draw lots of pictures on white > > | > boards. Can we do that, or do we have to submit an Internet > > | > Draft first? > > | > > | i agree that this is one activity this wg strongly > > needs. but is a > > | meeting at an ietf general meeting the right place for > > this? i do > > | not remember white (or black or green) boards in an > ietf general > > | meeting. not that i don't think our meetings might > benefit from > > | such, but i am the one who the secretariat will tell to put the > > | request where the sun don't shine. > > | > > | one kind of interesting plan might be to see if i/we can find > > | some venue with white-boards for sunday, and have a wg meeting > > | during the week to widen the audience for the result thereof. > > | current ietf culture is to call this a design team > > meeting, and use > > | of that phrase may help grease the administrivia. > > | > > | i also suspect that this working group might get more > done if the > > | filibustering by folk riding lame or long-dead hobby > horses would > > | dismount, take a break, go into the saloon for a beer, and let > > | others talk too. > > | > > | randy > > | > > | > > > > > > From owner-multi6@ops.ietf.org Fri Apr 18 00:30:07 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19463 for ; Fri, 18 Apr 2003 00:30:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 196NXK-000HqY-00 for multi6-data@psg.com; Fri, 18 Apr 2003 04:31:42 +0000 Received: from zmamail04.zma.compaq.com ([161.114.64.104]) by psg.com with esmtp (Exim 3.36 #1) id 196NWx-000Hpa-00 for multi6@ops.ietf.org; Fri, 18 Apr 2003 04:31:19 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id D4FE7D96; Fri, 18 Apr 2003 00:31:18 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Fri, 18 Apr 2003 00:31:18 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Resolving geo discussions Date: Fri, 18 Apr 2003 00:31:18 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03241139@tayexc13.americas.cpqcorp.net> Thread-Topic: Resolving geo discussions Thread-Index: AcMFVcH627DjR53QROuLleJZgK70ogACzclg From: "Bound, Jim" To: "Randy Bush" Cc: "Tony Li" , X-OriginalArrivalTime: 18 Apr 2003 04:31:18.0781 (UTC) FILETIME=[5B475AD0:01C30563] X-Spam-Status: No, hits=-9.8 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id AAA19463 That is a very fair question. If we cannot do that we should not use up IETF finances for brainstorming with no agenda. Times are not good the IETF must use their resources wisely for sure. If we build content and agenda and force some agreement and compromise we may be able to move forward. As far as brainstorming I did it one night with Michel, Christian, and a few others I think we want to do that not in formal meeting whenever possible. Suggestion: Work on content and agenda so we can have meeting. Realize folks will show up who are not here too and so that will, as always, be variable to the processes so the chairs have to try to focus the meeting. I know this is normal but wanted to state it. Agenda: Requirements state - Chairs Location and Identification Architecture (can we agree on some base principles before the IETF and then present them at IETF) - ??? Routing Problem and Complexity and where the fix has to be (same if we can agree on base that would be useful to IETF attendees) - ???? Existing work that has input to the above loc/id and route complexity issues: 1) MAP (michel) (send in IDs) 2) Mobile IPv6 idea (christian) (send in IDs) 3) HIP (pekka N.) (send in IDs) Working Group Next Plans - Chairs. NOTE - Not sure if we agree to put out base GEO doc stuff but that INFO/BCP could be agenda item too but I did not see consensus on the mail list from my view ???? Post IETF - I can look into hosting mutli6 offline whatever meeting in New Hampshire late September before fall IETF meeting for brainstorm part II as we need to do what Tony stated before that and this can be part II. Times are tough for vendors but I will go ask for support of an offsite if folks want. Good to schedule so folks can check out fall colors up here too if possible :---) Given that I am alive and well after my Harley adventure and come back to the system :---) Regards, /jim > -----Original Message----- > From: Randy Bush [mailto:randy@psg.com] > Sent: Thursday, April 17, 2003 10:53 PM > To: Bound, Jim > Cc: Tony Li; multi6@ops.ietf.org > Subject: RE: Resolving geo discussions > > > > Why can't we develop an agenda with content and use that as > discussion > > content and request an agenda. > > good question. that is THE question, and the lack thereof is > why there have been no meetings. > > randy > > From owner-multi6@ops.ietf.org Fri Apr 18 07:18:15 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08576 for ; Fri, 18 Apr 2003 07:18:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 196Ttm-00065v-00 for multi6-data@psg.com; Fri, 18 Apr 2003 11:19:18 +0000 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 196TtP-00064y-00 for multi6@ops.ietf.org; Fri, 18 Apr 2003 11:18:56 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08534; Fri, 18 Apr 2003 07:16:14 -0400 (EDT) Message-Id: <200304181116.HAA08534@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: multi6@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-multi6-multihoming-requirements-05.txt Date: Fri, 18 Apr 2003 07:16:13 -0400 X-Spam-Status: No, hits=-3.5 required=5.0 tests=BAYES_01,MIME_BOUND_NEXTPART,NO_REAL_NAME,TO_MALFORMED version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Site Multihoming in IPv6 Working Group of the IETF. Title : Goals for IPv6 Site-Multihoming Architectures Author(s) : J. Abley, B. Black, V. Gill Filename : draft-ietf-multi6-multihoming-requirements-05.txt Pages : 9 Date : 2003-4-17 Site-multihoming, i.e. connecting to more than one IP service provider, is an essential component of service for many sites which are part of the Internet. This document outlines a set of goals for proposed new IPv6 site-multihoming architectures. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-multi6-multihoming-requirements-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-multi6-multihoming-requirements-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-multi6-multihoming-requirements-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-4-17132242.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-multi6-multihoming-requirements-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-multi6-multihoming-requirements-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-4-17132243.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-multi6@ops.ietf.org Fri Apr 18 12:33:50 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18992 for ; Fri, 18 Apr 2003 12:33:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 196YoY-00059b-00 for multi6-data@psg.com; Fri, 18 Apr 2003 16:34:14 +0000 Received: from buffoon.automagic.org ([208.185.30.208]) by psg.com with smtp (Exim 3.36 #1) id 196YoB-00057f-00 for multi6@ops.ietf.org; Fri, 18 Apr 2003 16:33:51 +0000 Received: (qmail 49271 invoked by uid 0); 18 Apr 2003 16:33:50 -0000 Received: from localhost.automagic.org (HELO isc.org) (root@127.0.0.1) by localhost.automagic.org with SMTP; 18 Apr 2003 16:33:50 -0000 Date: Fri, 18 Apr 2003 12:34:06 -0400 Subject: Re: I-D ACTION:draft-ietf-multi6-multihoming-requirements-05.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) From: Joe Abley To: multi6@ops.ietf.org Content-Transfer-Encoding: 7bit In-Reply-To: <200304181116.HAA08534@ietf.org> Message-Id: <92FA996D-71BB-11D7-A6E0-00039312C852@isc.org> X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-34.4 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,HTML_10_20,IN_REP_TO, PATCH_UNIFIED_DIFF,QUOTED_EMAIL_TEXT,REPLY_WITH_QUOTES, USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Friday, Apr 18, 2003, at 07:16 Canada/Eastern, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Site Multihoming in IPv6 Working > Group of the IETF. > > Title : Goals for IPv6 Site-Multihoming Architectures > Author(s) : J. Abley, B. Black, V. Gill > Filename : draft-ietf-multi6-multihoming-requirements-05.txt > Pages : 9 > Date : 2003-4-17 These are Brian's changes, plus Marcelo's changes, plus that extra sentence in the security considerations section. Source diff follows. Index: draft-ietf-multi6-multihoming-requirements.xml =================================================================== RCS file: /home/cvs/doc/ietf/draft-ietf-multi6-multihoming-requirements.xml,v retrieving revision 1.3 retrieving revision 1.5 diff -u -r1.3 -r1.5 --- draft-ietf-multi6-multihoming-requirements.xml 4 Apr 2003 00:55:37 -0000 1.3 +++ draft-ietf-multi6-multihoming-requirements.xml 16 Apr 2003 13:40:47 -0000 1.5 @@ -5,7 +5,7 @@ - + Goals for IPv6 Site-Multihoming Architectures @@ -48,12 +48,7 @@ <abstract> <t>Site-multihoming, i.e. connecting to more than one IP service provider, is an essential component of service for many sites - which are part of the Internet. Existing IPv4 site-multihoming - practices provide a set of capabilities that it would ideally - be accommodated - by the adopted site-multihoming architecture in IPv6, and a - set of limitations that must be overcome, relating in particular - to scalability.</t> + which are part of the Internet.</t> <t>This document outlines a set of goals for proposed new IPv6 site-multihoming architectures.</t> @@ -246,25 +241,25 @@ <section anchor="routerImpact" title="Impact on Routers"> <t>The solution may require changes to IPv6 router implementations, - but these changes must be either minor, or in the form of logically + but these changes should be either minor, or in the form of logically separate functions added to existing functions.</t> <t>Such changes should not prevent normal single-homed operation, and - routers implementing these changes must be able to interoperate + routers implementing these changes should be able to interoperate fully with hosts and routers not implementing them.</t> </section> <section anchor="hostImpact" title="Impact on Hosts"> <t>The solution should not destroy IPv6 connectivity for a legacy host - implementing RFC 2373 <xref target="refs.RFC2373" />, + implementing RFC 3513 <xref target="refs.RFC3513" />, RFC 2460 <xref target="refs.RFC2460" />, RFC 2553 <xref target="refs.RFC2553" /> and other basic IPv6 - specifications current in November 2001. That is to say, if a host + specifications current in April 2003. That is to say, if a host can work - in a single-homed site, it must still be able to work in a + in a single-homed site, it should still be able to work in a multihomed site, even if it cannot benefit from site-multihoming.</t> - <t>It would be compatible with this requirement for such a host to + <t>It would be compatible with this goal for such a host to lose connectivity if a site lost connectivity to one transit provider, despite the fact that other transit provider connections were still operational.</t> @@ -305,11 +300,11 @@ <section anchor="multipleSolutions" title="Multiple Solutions"> <t>There may be more than one approach to multihoming, provided - all approaches are orthogonal (e.g. each approach addresses + all approaches are orthogonal (i.e. each approach addresses a distinct segment or category within the site multihoming - problem. Multiple solutions will incur a greater management + problem). Multiple solutions will incur a greater management overhead, however, and the adopted solutions - SHOULD attempt to cover as many multihoming scenarios + should attempt to cover as many multihoming scenarios and goals as possible.</t> </section> @@ -319,6 +314,10 @@ <section anchor="security" title="Security Considerations"> <t>A multihomed site should not be more vulnerable to security breaches than a traditionally IPv4-multihomed site.</t> + + <t>Any changes to routing practices made to accommodate multihomed + sites should not cause non-multihomed sites to become more + vulnerable to security breaches.</t> </section> </middle> @@ -368,18 +367,18 @@ <seriesInfo name="RFC" value="1918" /> </reference> - <reference anchor="refs.RFC2373"> + <reference anchor="refs.RFC3513"> <front> - <title>IP Version 6 Addressing Architecture + Internet Protocol Version 6 (IPv6) Addressing Architecture Nokia - Cisco + Cisco Systems - + - + From owner-multi6@ops.ietf.org Fri Apr 18 20:42:03 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02860 for ; Fri, 18 Apr 2003 20:42:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 196gQ1-000Mgm-00 for multi6-data@psg.com; Sat, 19 Apr 2003 00:41:25 +0000 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 196gPe-000MWb-00 for multi6@ops.ietf.org; Sat, 19 Apr 2003 00:41:02 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h3J0dpE67478; Sat, 19 Apr 2003 02:39:51 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Sat, 19 Apr 2003 02:39:43 +0200 Subject: Re: old GSE idea Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Multi6 Working Group To: Sean Doran From: Iljitsch van Beijnum In-Reply-To: Message-Id: <6981A92A-71FF-11D7-A7F7-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On donderdag, apr 17, 2003, at 21:29 Europe/Amsterdam, Sean Doran wrote: > It would be interesting to see if we could be more ambitious and > try to deal with movement/multihoming of things with finer granularity. > The multiported host model is amenable to virtualization, but do we > want to/can we have an identifier bound to a particular *service* > that may migrate around a network independently of other services > which are, at any given moment, sharing a host (virtual or real) with > it? Of course we want this. Why is it that when I email someone sitting in the same room at (for instance) an IETF meeting, the message has to travel halfway across the globe? I want my mail service to be as close to me as possible. Sometimes that means that it has to run back home because I'm not connected, but at other times the service should run on my laptop. > Can we/do we want to aggregate several services (or clients thereof) > and have that aggregate be mobile/multihomed? Do we need to aggregate services? I'm thinking more the other way around: each service should live on its own address(es). > That is, (assuming process migration is feasible) can I move my > voice over ip service, AIM, ssh sessions, X server, and so forth > from one part of the network to another without moving the host > these are sharing with an IMAP service, ntpd, and so on? Obviously you can reroute your voice calls or instant messaging to another box. But SSH sessions...? I guess this is what happens when I disconnect and log in again from another box and reconnect to my screen session. Doing this at the network level means that TCP sessions are no longer tied to a host, but to a person. Unfortunately, people are a bad platform for implementing network protocols. > Most of these questions go to the semantics of the lower-order bits, > how they bind with one or more sets of higher-order bits, and how > they are acquired initially. I think the question of the bits will be solved soon enough once we get the right design team together. The question of the acquiring is more fundamental. How do you find something hidden behind an arbitrary topology, without depending on a central directory or on the help of strangers? We could start by evaluating which part of the information should be pushed out and which part should be pulled in, and which part is static enough to be cached for a considerable amount of time and which part must be refreshed pretty much before every use. From owner-multi6@ops.ietf.org Fri Apr 18 20:42:30 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02878 for ; Fri, 18 Apr 2003 20:42:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 196gSE-000N8a-00 for multi6-data@psg.com; Sat, 19 Apr 2003 00:43:42 +0000 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 196gRs-000N8A-00 for multi6@ops.ietf.org; Sat, 19 Apr 2003 00:43:21 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h3J0gBE67485; Sat, 19 Apr 2003 02:42:11 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Sat, 19 Apr 2003 02:42:03 +0200 Subject: Re: old GSE idea Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: "Christian Huitema" From: Iljitsch van Beijnum In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On donderdag, apr 17, 2003, at 21:35 Europe/Amsterdam, Christian Huitema wrote: > I don't necessarily want different ISP > to be able to correlate that two traffic flows do in fact originate > from > the same hosts. In fact, privacy advocates would go ballistic if we > mandated that. This is standard behavior with PI. Why would this be a problem? From owner-multi6@ops.ietf.org Fri Apr 18 20:53:32 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03019 for ; Fri, 18 Apr 2003 20:53:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 196gct-000PII-00 for multi6-data@psg.com; Sat, 19 Apr 2003 00:54:43 +0000 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 196gcX-000PES-00; Sat, 19 Apr 2003 00:54:21 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h3J0rBE67505; Sat, 19 Apr 2003 02:53:11 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Sat, 19 Apr 2003 02:53:03 +0200 Subject: Re: Resolving geo discussions Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: Randy Bush From: Iljitsch van Beijnum In-Reply-To: Message-Id: <46B794C6-7201-11D7-A7F7-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On vrijdag, apr 18, 2003, at 02:56 Europe/Amsterdam, Randy Bush wrote: > one kind of interesting plan might be to see if i/we can find > some venue with white-boards for sunday, and have a wg meeting > during the week to widen the audience for the result thereof. Sounds good. > i also suspect that this working group might get more done if the > filibustering by folk riding lame or long-dead hobby horses would > dismount, take a break, go into the saloon for a beer, and let > others talk too. Silly me for thinking that writing drafts and providing feedback on those written by other people might help. From owner-multi6@ops.ietf.org Fri Apr 18 21:06:28 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03268 for ; Fri, 18 Apr 2003 21:06:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 196gqA-0001Xn-00 for multi6-data@psg.com; Sat, 19 Apr 2003 01:08:26 +0000 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 196gpp-0001S3-00 for multi6@ops.ietf.org; Sat, 19 Apr 2003 01:08:05 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h3J16sE67973; Sat, 19 Apr 2003 03:06:55 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Sat, 19 Apr 2003 03:06:42 +0200 Subject: Re: Resolving geo discussions Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: "Bound, Jim" From: Iljitsch van Beijnum In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B03241139@tayexc13.americas.cpqcorp.net> Message-Id: <2EA5ED83-7203-11D7-A7F7-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On vrijdag, apr 18, 2003, at 06:31 Europe/Amsterdam, Bound, Jim wrote: > That is a very fair question. If we cannot do that we should not use up > IETF finances for brainstorming with no agenda. How does this cost the IETF money? Do they pay for the rooms by the hour? > If we build content and agenda and force some agreement and compromise > we may be able to move forward. Yes, let's focus on what we can agree upon. I'll be happy do defend geo aggregation for years to come (and don't think I won't) but I'd be equally happy to shelf the geo stuff and support something that has more long-term potential and if and when this wg starts to work on something like this. > Post IETF - I can look into hosting mutli6 offline whatever meeting in > New Hampshire late September before fall IETF meeting for brainstorm > part II Maybe you can move this to mid october just before the NANOG meeting? From owner-multi6@ops.ietf.org Fri Apr 18 21:23:06 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03501 for ; Fri, 18 Apr 2003 21:23:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 196h6E-0004KS-00 for multi6-data@psg.com; Sat, 19 Apr 2003 01:25:02 +0000 Received: from host217-37-202-105.in-addr.btopenworld.com ([217.37.202.105] helo=ab.use.net) by psg.com with esmtp (Exim 3.36 #1) id 196h5r-0004Jj-00 for multi6@ops.ietf.org; Sat, 19 Apr 2003 01:24:39 +0000 Received: from ab.use.net (conf.use.net [217.37.202.109]) by ab.use.net (Postfix) with ESMTP id 87F6639682; Sat, 19 Apr 2003 01:24:37 +0000 (GMT) Date: Sat, 19 Apr 2003 02:24:36 +0100 Subject: Re: old GSE idea Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Sean Doran To: multi6@ops.ietf.org From: Sean Doran In-Reply-To: <6981A92A-71FF-11D7-A7F7-00039388672E@muada.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Saturday, Apr 19, 2003, at 01:39 Europe/London, Iljitsch van Beijnum wrote: > Obviously you can reroute your voice calls or instant messaging to > another box. But SSH sessions...? I guess this is what happens when I > disconnect and log in again from another box and reconnect to my > screen session. Doing this at the network level means that TCP > sessions are no longer tied to a host, but to a person. No, they're tied to a stack of software that may migrate around, and just happens (usually, but not always) to be presented to a live user sitting in front of some sort of virtual or actual terminal. Some folks use ssh for computer-to-computer communication, such as when doing mirroring, backups or whatnot. If I fire up NetBSD in a Virtual PC on my Macintoy, and have it DHCP up an address on LAN A, fire up an ssh session, do a Save-All-State-and-Quit, copy the image to another Macintoy and resume the VirtualPC, as long as the ssh and sshd can still communicate with one another, the session survives. The "session layer" in OSIspeak, is the VirtualPC itself. (iPods make great VPC image transport mechanisms.) The trick, naturally, is at least two things: (a) the moved sender must be able to convince the stationary receiver that it is the same speaker in a new place and (b) the moved receiver must be able to receive datagrams from the stationary sender. Right now, this can only be accomplished by remaining on the same LIS, or by fiddling with the routing system (and possibly tunneling). However, some protocols simply don't need a session layer in the presence of a decoupling of "speaker/recipient-identity" and network location, 8+8-style. Others, naturally, could benefit from something a little more lightweight than a large virtual machine, reducing the problem to 'can still communicate with one another', i.e., the same as already movement-friendly/renumbering-friendly stacks of software. Since movement/renumbering can be seen in the light of either or both of fail_A-unfail_B or unfail_B-fail_A when doing multihoming, a generalization of renumbering-survival/mobility which handles a long gap between the two events in the second case, may also solve the host multihoming problem. Is this a good mechanism for solving site multihoming? That is, is multihoming or moving a site merely a question of multihoming or moving each of the hosts in the site? (A site may be *large*...) > Unfortunately, people are a bad platform for implementing network > protocols. Sean. From owner-multi6@ops.ietf.org Sat Apr 19 07:03:25 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23056 for ; Sat, 19 Apr 2003 07:03:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 196q8y-000Mem-00 for multi6-data@psg.com; Sat, 19 Apr 2003 11:04:28 +0000 Received: from pop-ls-09-1-dialup-203.freesurf.ch ([194.230.235.203] helo=dhcp1.se.kurtis.pp.se) by psg.com with esmtp (Exim 3.36 #1) id 196q8b-000MeO-00 for multi6@ops.ietf.org; Sat, 19 Apr 2003 11:04:05 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp1.se.kurtis.pp.se (8.12.9/8.10.2) with ESMTP id h3JB5eBQ002759; Sat, 19 Apr 2003 13:05:41 +0200 (CEST) Date: Sat, 19 Apr 2003 11:28:51 +0200 Subject: Re: Resolving geo discussions Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: Tim Chown From: Kurt Erik Lindqvist In-Reply-To: <20030417212835.GH12026@login.ecs.soton.ac.uk> Message-Id: <54BCC442-7249-11D7-BC5F-000393AB1404@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-16.7 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1, USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >>> Absolutely, and it's just 3 months to Vienna and the restoration of >>> the >>> multi6 sessions at the meetings. We should have some idea soon of >>> what will be on the table there >> >> what are you putting on it? > > I predict a bottle of water, glasses and a microphone or two. > > First we need to decide what to do about the current (only) multi6 > I-D. It > needs to be either signed off or removed and replaced with a less > restrictive > (perhaps more open minded) set of requirements. It will be last-called. If I am not mistaken my initial two weeks ends next week and we will then do last-call. The new drafts have some comments included. > > I like Christian's proposal. It offers what appears to be a sane path > to at least solve some useful classes of scenario. And we have this > as > a good proposal in spite of no agreed requirements document, so I think > we can also put forward other potential solutions too. > > I think if we can set an agenda now, and decide what is on that table, > we > can maybe have some fruitful, focused discussion before Vienna. Is > MHAP > on the table? GSE? HIP? ....? Some solutions may not fly, but we > should at least ensure they get a good airing in an official IETF > session > rather than just in the ipv6mh meetings, as (very) good as they are. > > At least let's make sure there is a meeting in Vienna. It seems a lot > of people just assumed there would be a San Francisco multi6, given it > seen as the last Big Issue for IPv6 by a fair few people. Let's even > consider getting some possible solutions on board as WG items in July. > There will be a meeting. Me and Sean are working out the agenda and how we should get one together. As for what should be included, well we (IMHO) need to change the charter, or at least look at doing so and update the milestones. There are a number or proposals floating around, of which not all even have made it as IDs. Having presentations of all in Vienna, at a depth that gives justice to all proposals, might be a bit time consuming, but perhaps we need to. - kurtis - From owner-multi6@ops.ietf.org Sat Apr 19 07:03:59 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23072 for ; Sat, 19 Apr 2003 07:03:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 196qAc-000Mr4-00 for multi6-data@psg.com; Sat, 19 Apr 2003 11:06:10 +0000 Received: from pop-ls-09-1-dialup-203.freesurf.ch ([194.230.235.203] helo=dhcp1.se.kurtis.pp.se) by psg.com with esmtp (Exim 3.36 #1) id 196qAG-000Mo6-00 for multi6@ops.ietf.org; Sat, 19 Apr 2003 11:05:48 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp1.se.kurtis.pp.se (8.12.9/8.10.2) with ESMTP id h3JB5hBQ002764; Sat, 19 Apr 2003 13:05:44 +0200 (CEST) Date: Sat, 19 Apr 2003 11:33:05 +0200 Subject: Re: Resolving geo discussions Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "Tony Li" , "Randy Bush" , To: "Bound, Jim" From: Kurt Erik Lindqvist In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B03241138@tayexc13.americas.cpqcorp.net> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.7 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On fredag, apr 18, 2003, at 06:13 Europe/Stockholm, Bound, Jim wrote: > > Also I speak out of turn as I most likely will not be at the July IETF > as I intend to ride my Harley Davidson across the U.S. all of July and > not even take my laptop, and might not even come back and go be a > logger > and live on a diet of very red meat (no carbs) and rock n roll :--) > But > not 100% yet but I will always recall multi6 and wonder if it got > figured out :---) > Now, don't start giving people ideas.... Looking at the sun shining on the Grand Combin.....why did I want to go back to Stockholm...? To quote a colleague "See you in the bar". - kurtis - From owner-multi6@ops.ietf.org Sat Apr 19 07:04:24 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23087 for ; Sat, 19 Apr 2003 07:04:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 196qB3-000Mrb-00 for multi6-data@psg.com; Sat, 19 Apr 2003 11:06:37 +0000 Received: from pop-ls-09-1-dialup-203.freesurf.ch ([194.230.235.203] helo=dhcp1.se.kurtis.pp.se) by psg.com with esmtp (Exim 3.36 #1) id 196qAH-000Mo7-00 for multi6@ops.ietf.org; Sat, 19 Apr 2003 11:05:49 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp1.se.kurtis.pp.se (8.12.9/8.10.2) with ESMTP id h3JB5kBQ002767; Sat, 19 Apr 2003 13:05:47 +0200 (CEST) Date: Sat, 19 Apr 2003 11:40:51 +0200 Subject: Re: Resolving geo discussions Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "Randy Bush" , "Tony Li" , To: "Bound, Jim" From: Kurt Erik Lindqvist In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B03241139@tayexc13.americas.cpqcorp.net> Message-Id: <0273D327-724B-11D7-BC5F-000393AB1404@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-16.7 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1, USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > That is a very fair question. If we cannot do that we should not use up > IETF finances for brainstorming with no agenda. Times are not good the > IETF must use their resources wisely for sure. Valid point. > If we build content and agenda and force some agreement and compromise > we may be able to move forward. Actually, I tend to have a somewhat different opinion than Randy. I agree that we need a solid agenda, but I also think that we need a meeting to get people more engaged and meeting face to face also always helps. > Suggestion: > > Work on content and agenda so we can have meeting. Realize folks will > show up who are not here too and so that will, as always, be variable > to > the processes so the chairs have to try to focus the meeting. I know > this is normal but wanted to state it. It's a good point. Even if only people in here showed up :-) > > Agenda: > > Requirements state - Chairs Well, I think we have concluded that requirements vary. We have more of a benchmark document, that we hopefully have published by then. I think that is as good starting point as we gets. Right? > Location and Identification Architecture (can we agree on some base > principles before the IETF and then present them at IETF) - ??? This would be good. > Routing Problem and Complexity and where the fix has to be (same if we > can agree on base that would be useful to IETF attendees) - ???? Do you really think that this is worth it? This will depend on the outcome of your first point. > > Existing work that has input to the above loc/id and route complexity > issues: > > 1) MAP (michel) (send in IDs) > 2) Mobile IPv6 idea (christian) (send in IDs) > 3) HIP (pekka N.) (send in IDs) Having these suggestions presented (with associated IDs) might give some picture of the problems of each type of solution. > NOTE - Not sure if we agree to put out base GEO doc stuff but that > INFO/BCP could be agenda item too but I did not see consensus on the > mail list from my view ???? Agreed. > Post IETF - I can look into hosting mutli6 offline whatever meeting in > New Hampshire late September before fall IETF meeting for brainstorm > part II as we need to do what Tony stated before that and this can be > part II. Times are tough for vendors but I will go ask for support of > an offsite if folks want. Good to schedule so folks can check out fall > colors up here too if possible :---) Given that I am alive and well > after my Harley adventure and come back to the system :---) > I have been playing with this idea as well. Let's keep this option open for a while and see where we end up. If this is to be useful we need something with a lot more substance than what we have now. - kurtis - From owner-multi6@ops.ietf.org Sat Apr 19 12:50:19 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28171 for ; Sat, 19 Apr 2003 12:50:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 196vY6-000H6h-00 for multi6-data@psg.com; Sat, 19 Apr 2003 16:50:46 +0000 Received: from mailout.zma.compaq.com ([161.114.64.104] helo=zmamail04.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 196vXj-000H20-00 for multi6@ops.ietf.org; Sat, 19 Apr 2003 16:50:23 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 2482072AE; Sat, 19 Apr 2003 12:50:21 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Sat, 19 Apr 2003 12:50:20 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Resolving geo discussions Date: Sat, 19 Apr 2003 12:50:20 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03241150@tayexc13.americas.cpqcorp.net> Thread-Topic: Resolving geo discussions Thread-Index: AcMGZp0rTfVwpLftSi+qezCR1UxqCgAK7HSQ From: "Bound, Jim" To: "Kurt Erik Lindqvist" Cc: "Randy Bush" , "Tony Li" , X-OriginalArrivalTime: 19 Apr 2003 16:50:20.0562 (UTC) FILETIME=[C373EF20:01C30693] X-Spam-Status: No, hits=-9.8 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA28171 Agree with your response. The reason I suggested the routing topic below (and yes it is dependent on location and identifier) was that who presents the loc+ID slides feed those to who would present the route topic and then the route topic would present say multiple views to work with the loc+ID part even if it is just strawman for WG thought. This permits some of what Tony requested for brainstorm and it can be presented that way and then people come to the microphone and talk about what they think. But as randy stated we don't have white boards or the setting for true brainstorm roll up your sleeves and produce an architecture idea set. I think that would be hard in a 2.5 hour meeting (if we can justify to AD) at an IETF setting. Hmmmmmmmm that being said in the old days I recall room where we had tables and flip charts etc. but that was before 200 people showed up for a meeting (I have been in meetings like that with Tony, Randy, Christian, and others here years back and they were very good productive sessions [with some hate and swearing at times :--)]. Folks can let me know about New Hampshire for Sept I would probably need to begin lobbying to host say by beginning of August so you folks could decide in Vienna as I am highly confident I cannot make this meeting [only second meeting I have missed since 1993 and that was because I had an emergency operation on my stomach and they cut me up pretty bad so I could not fly to Norway as best I recall and I used up one of my lives on that one too). But if we decided by June that would be even better because then I could start poking the system before I leave on my adventure :--) Why am I talking to you folks its 65 degrees here in New England talk with you Monday :--) And it was a horrible winter. Thanks /jim > -----Original Message----- > From: Kurt Erik Lindqvist [mailto:kurtis@kurtis.pp.se] > Sent: Saturday, April 19, 2003 5:41 AM > To: Bound, Jim > Cc: Randy Bush; Tony Li; multi6@ops.ietf.org > Subject: Re: Resolving geo discussions > > > > That is a very fair question. If we cannot do that we > should not use > > up IETF finances for brainstorming with no agenda. Times > are not good > > the IETF must use their resources wisely for sure. > > Valid point. > > > If we build content and agenda and force some agreement and > compromise > > we may be able to move forward. > > Actually, I tend to have a somewhat different opinion than Randy. I > agree that we need a solid agenda, but I also think that we need a > meeting to get people more engaged and meeting face to face > also always > helps. > > > Suggestion: > > > > Work on content and agenda so we can have meeting. Realize > folks will > > show up who are not here too and so that will, as always, > be variable > > to the processes so the chairs have to try to focus the meeting. I > > know this is normal but wanted to state it. > > It's a good point. Even if only people in here showed up :-) > > > > > Agenda: > > > > Requirements state - Chairs > > Well, I think we have concluded that requirements vary. We > have more of > a benchmark document, that we hopefully have published by > then. I think > that is as good starting point as we gets. Right? > > > Location and Identification Architecture (can we agree on some base > > principles before the IETF and then present them at IETF) - ??? > > This would be good. > > > Routing Problem and Complexity and where the fix has to be > (same if we > > can agree on base that would be useful to IETF attendees) - ???? > > Do you really think that this is worth it? This will depend on the > outcome of your first point. > > > > > Existing work that has input to the above loc/id and route > complexity > > issues: > > > > 1) MAP (michel) (send in IDs) > > 2) Mobile IPv6 idea (christian) (send in IDs) > > 3) HIP (pekka N.) (send in IDs) > > Having these suggestions presented (with associated IDs) might give > some picture of the problems of each type of solution. > > > NOTE - Not sure if we agree to put out base GEO doc stuff but that > > INFO/BCP could be agenda item too but I did not see > consensus on the > > mail list from my view ???? > > Agreed. > > > Post IETF - I can look into hosting mutli6 offline whatever > meeting in > > New Hampshire late September before fall IETF meeting for > brainstorm > > part II as we need to do what Tony stated before that and > this can be > > part II. Times are tough for vendors but I will go ask for > support of > > an offsite if folks want. Good to schedule so folks can check out > > fall colors up here too if possible :---) Given that I am > alive and > > well after my Harley adventure and come back to the system :---) > > > > I have been playing with this idea as well. Let's keep this > option open > for a while and see where we end up. If this is to be useful we need > something with a lot more substance than what we have now. > > - kurtis - > > > From owner-multi6@ops.ietf.org Sun Apr 20 10:07:30 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05571 for ; Sun, 20 Apr 2003 10:07:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 197FSJ-000LcX-00 for multi6-data@psg.com; Sun, 20 Apr 2003 14:06:07 +0000 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 197FRw-000Lbi-00 for multi6@ops.ietf.org; Sun, 20 Apr 2003 14:05:44 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h3KE4WE72708 for ; Sun, 20 Apr 2003 16:04:33 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Sun, 20 Apr 2003 16:04:24 +0200 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: Differentiating multihoming in IPv6 requirements From: Iljitsch van Beijnum To: multi6@ops.ietf.org Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-9.7 required=5.0 tests=BAYES_01,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Over the course of a private discussion we (Harold Grovesteen and Iljitsch van Beijnum) have come to the conclusion the way both multi6 and ipv6mh handle the "requirements problem" is unsatisfactory. Multi6 is still set on delivering a requirements document, but it is generally recognized that it is impossible for a single solution to meet all the requirements in the current document. Ipv6mh on the other hand, rejects any requirements in order to avoid getting stuck. This means multi6 fails to develop any solutions, while ipv6mh develops too many, and quite possibly ones that fail to meet user expectations. (Anyone who has ever owned a V2000 or Betamax VCR knows that too many solutions for a single problem isn't good.) We believe we can find middle ground here by not pursuing single solutions that meet all requirements, but recognizing that there are three classes of solutions that each require different requirements: short, intermediate and long term solutions. This way, we can have both a solution that can be deployed in the near future, and a solution that provides near-unlimited scalability and a clean architecture, rather than something that takes too long to develop and still doesn't provide everything we want. The most important requirement for short term solutions is that they can indeed be deployed in the short term. That means either doing something in routing using current protocols, or doing something in hosts that works if only one side of the connection is a modified host. Short term solutions don't have to scale to more than a few million multihomers (although it wouldn't hurt if they could), as long as any "pollution" (of the global routing table, for instance) can be cleaned up at some point. There can be several short term solutions. The requirements for long term solutions are very different. Here scalability is key. This, and the end-to-end principe suggest that long term solutions be implemented in individual hosts. Long term solutions also need a clean architecture, preferably one where we know we can support future developments at the transport and lower layers without another round of changes to applications. For long term solutions, it isn't much of a problem that both ends of a connection must be modified for it to work. (Although a smoother upgrade path than just sit out the whole chicken/egg thing would be good.) More than a single long term solution would be undesirable. Intermediate solutions should bridge the gap. For an intermediate solution, it's still not acceptable to have to change all hosts, but changing all sites or all ISPs (by putting in proxy multihoming processing boxes) should be acceptable. Intermediate solutions should be very scalable and have a decent (but presumably not perfect) architecture because the life time of intermediate term solutions could be longer than expected as it might be a very long time before a long term solution is widely implemented. An important feature for intermediate solutions is that they work well with both short term solutions and with long term solutions. This probably means explicit support for all short term solutions in all intermediate implementations, and some kind of meta-solution that makes it possible for intermediate and long term solutions to work together. Some comments on the requirements document in this light: By multihoming, a site must be able to distribute both inbound and outbound traffic between multiple transit providers. This requirement is for concurrent use of the multiple transit providers, not just the usage of one provider over one interval of time and another provider over a different interval. Short: since we can do this for inbound with multiple A records and for outbound with some (static) routes, at solution doesn't really have to support this Intermediate: highly desired / required Long: required, preferably even load balance a single session over multiple paths By multihoming, a site must be able to protect itself from performance difficulties directly between the site's transit providers. This is a good example of something we could easily drop for short term solutions. Multihoming solutions must provide re-homing transparency for transport-layer sessions; i.e. exchange of data between devices on the multihomed site and devices elsewhere on the Internet may proceed with no greater interruption than that associated with the transient packet loss during the re-homing event. Again, something that would definitely be a requirement for intermediate or long term solutions, but if we can have the ability to set up new sessions for a short term solution, that's better than nothing. A new IPv6 multihoming architecture must scale to accommodate orders of magnitude more multihomed sites without imposing unreasonable requirements on the routing system. Short: has to be much better than simple PI, but a billion or more isn't necessary Intermediate: required, as there may not be a long term solution after all Long: required The solution may require changes to IPv6 router implementations, but these changes must be either minor, or in the form of logically separate functions added to existing functions. Short: required Intermediate: required Long: desired: forklift upgrades are bad, but if we then get the perfect solution it may be worth it and/or we can wait out the natural economic life span of existing equipment The solution must not destroy IPv6 connectivity for a legacy host implementing RFC 2373 [5], RFC 2460 [7], RFC 2553 [8] and other basic IPv6 specifications current in November 2002. That is to say, if a host can work in a single-homed site, it must still be able to work multihoming. Short: required Intermediate: required Long: interoperability should remain but we can expect people to upgrade at some point, so just "desired" A multihoming strategy may require cooperation between a site and its transit providers, but must not require cooperation (relating specifically to the multihomed site) directly between the transit providers. Short: required (not all ISPs will upgrade immediately) Intermediate: highly desired (if this is the only downside, we can live with it, for a while anyway) Long: required Harold Grovesteen Iljitsch van Beijnum From owner-multi6@ops.ietf.org Sun Apr 20 15:18:58 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12902 for ; Sun, 20 Apr 2003 15:18:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 197KKT-000KTv-00 for multi6-data@psg.com; Sun, 20 Apr 2003 19:18:21 +0000 Received: from tomts22-srv.bellnexxia.net ([209.226.175.184]) by psg.com with esmtp (Exim 3.36 #1) id 197KK7-000KMg-00 for multi6@ops.ietf.org; Sun, 20 Apr 2003 19:17:59 +0000 Received: from yahoo.com ([65.93.189.11]) by tomts22-srv.bellnexxia.net (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with ESMTP id <20030420191758.NJUZ26395.tomts22-srv.bellnexxia.net@yahoo.com> for ; Sun, 20 Apr 2003 15:17:58 -0400 Date: Sun, 20 Apr 2003 15:17:58 -0400 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: Re: Resolving geo discussions From: S Woodside To: multi6@ops.ietf.org Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-12.3 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,FORGED_YAHOO_RCVD, QUOTED_EMAIL_TEXT,RCVD_FAKE_HELO_DOTCOM, USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi I just joined this list but I'm going to be bold and jump right in. I've been searching for a good home for my thoughts and questions about community wireless networking; mesh networking; geographic routing; and the IETF. Perhaps this is the right place? > Iljitsch van Beijnum wrote: > > If it's just "if you're going to do geo, beware of ..." I'll be happy > > to include something like that in the upcoming rewrite of my draft. As someone who is working in the CWN community to try to develop (or at least conceptualize) a good mesh routing solution (with a non-mobile network...), we are looking at geographic routing. I am aware of http://www.ietf.org/internet-drafts/draft-hain-ipv6-pi-addr-04.txt what is the address for your draft / other drafts on the topic? Brian E Carpenter wrote: > I think it needs to build on the observation that there is no > congruence > between network topology and geography to show that we have no way to > make > geo addresses aggregate in practice. Yes, this is where the key aspect of CWN differes from the regular wired internet. The community wireless nets are building out using Wi-fi so there are some statements that can be made about the maximum range of any given point-to-point link. One is simply curvature of the earth, a maximum line of sight range is IIRC about 50km given a reasonably high tower at each end barring mountain tops etc. (and even then there are limits). simon From owner-multi6@ops.ietf.org Mon Apr 21 05:08:38 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08181 for ; Mon, 21 Apr 2003 05:08:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 197XI5-00087H-00 for multi6-data@psg.com; Mon, 21 Apr 2003 09:08:45 +0000 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 197XHj-000871-00 for multi6@ops.ietf.org; Mon, 21 Apr 2003 09:08:23 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h3L97BE74206; Mon, 21 Apr 2003 11:07:12 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Mon, 21 Apr 2003 11:07:05 +0200 Subject: Re: Resolving geo discussions Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: S Woodside From: Iljitsch van Beijnum In-Reply-To: Message-Id: <9F8C6936-73D8-11D7-A279-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On zondag, apr 20, 2003, at 21:17 Europe/Amsterdam, S Woodside wrote: > Hi I just joined this list but I'm going to be bold and jump right in. > I've been searching for a good home for my thoughts and questions > about community wireless networking; mesh networking; geographic > routing; and the IETF. Perhaps this is the right place? Probably not... You may want to check out the IETF mobile ad-hoc networking working group, that one focusses on IP over complex radio networks. See http://protean.itd.nrl.navy.mil/manet/manet_home.html > As someone who is working in the CWN community to try to develop (or > at least conceptualize) a good mesh routing solution (with a > non-mobile network...), we are looking at geographic routing. I am > aware of > http://www.ietf.org/internet-drafts/draft-hain-ipv6-pi-addr-04.txt > what is the address for your draft / other drafts on the topic? My draft is about to expire or has already expired, but you can find it at http://www.muada.com/drafts/ along with the GAPI addressing draft. I never quite envisioned general deployment of Tony Hain's geographic addressing, but it has one potentially useful property: it should be possible to aim antennas based on the addresses you communicate with. With the advent of "software" directional antennas this could be very interesting. Do you guys do IPv6 on the community network yet? Contact me off-list if you want to talk some more about this or the more mundane details of community wireless routing (I've always wondered how this is done in practice). Iljitsch van Beijnum From owner-multi6@ops.ietf.org Tue Apr 22 11:01:40 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12722 for ; Tue, 22 Apr 2003 11:01:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 197zGY-0004X1-00 for multi6-data@psg.com; Tue, 22 Apr 2003 15:01:02 +0000 Received: from d12lmsgate-2.de.ibm.com ([194.196.100.235]) by psg.com with esmtp (Exim 3.36 #1) id 197zFv-0004Sk-00 for multi6@ops.ietf.org; Tue, 22 Apr 2003 15:00:23 +0000 Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (8.12.9/8.12.8) with ESMTP id h3MF0EUm061140; Tue, 22 Apr 2003 17:00:15 +0200 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay01.de.ibm.com (8.12.8/NCO/VER6.5) with SMTP id h3MF097W264430; Tue, 22 Apr 2003 17:00:09 +0200 Received: from gsine06.us.sine.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA18474 from ; Tue, 22 Apr 2003 17:00:04 +0200 Message-Id: <3EA5591A.17AF1725@hursley.ibm.com> Date: Tue, 22 Apr 2003 17:00:42 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Iljitsch van Beijnum Cc: multi6@ops.ietf.org Subject: Re: Differentiating multihoming in IPv6 requirements References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-29.3 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Actually, if you look at the text, multi6 is *not* doing a requirements document any more. The draft is a list of goals which are all qualified by "should". I think we understand that satisfying all of the goals simultaneously is impossible. Brian Iljitsch van Beijnum wrote: > > Over the course of a private discussion we (Harold Grovesteen and > Iljitsch van Beijnum) have come to the conclusion the way both multi6 > and ipv6mh handle the "requirements problem" is unsatisfactory. Multi6 > is still set on delivering a requirements document, but it is generally > recognized that it is impossible for a single solution to meet all the > requirements in the current document. Ipv6mh on the other hand, rejects > any requirements in order to avoid getting stuck. This means multi6 > fails to develop any solutions, while ipv6mh develops too many, and > quite possibly ones that fail to meet user expectations. (Anyone who > has ever owned a V2000 or Betamax VCR knows that too many solutions for > a single problem isn't good.) > > We believe we can find middle ground here by not pursuing single > solutions that meet all requirements, but recognizing that there are > three classes of solutions that each require different requirements: > short, intermediate and long term solutions. This way, we can have both > a solution that can be deployed in the near future, and a solution that > provides near-unlimited scalability and a clean architecture, rather > than something that takes too long to develop and still doesn't provide > everything we want. > > The most important requirement for short term solutions is that they > can indeed be deployed in the short term. That means either doing > something in routing using current protocols, or doing something in > hosts that works if only one side of the connection is a modified host. > Short term solutions don't have to scale to more than a few million > multihomers (although it wouldn't hurt if they could), as long as any > "pollution" (of the global routing table, for instance) can be cleaned > up at some point. There can be several short term solutions. > > The requirements for long term solutions are very different. Here > scalability is key. This, and the end-to-end principe suggest that long > term solutions be implemented in individual hosts. Long term solutions > also need a clean architecture, preferably one where we know we can > support future developments at the transport and lower layers without > another round of changes to applications. For long term solutions, it > isn't much of a problem that both ends of a connection must be modified > for it to work. (Although a smoother upgrade path than just sit out the > whole chicken/egg thing would be good.) More than a single long term > solution would be undesirable. > > Intermediate solutions should bridge the gap. For an intermediate > solution, it's still not acceptable to have to change all hosts, but > changing all sites or all ISPs (by putting in proxy multihoming > processing boxes) should be acceptable. Intermediate solutions should > be very scalable and have a decent (but presumably not perfect) > architecture because the life time of intermediate term solutions could > be longer than expected as it might be a very long time before a long > term solution is widely implemented. An important feature for > intermediate solutions is that they work well with both short term > solutions and with long term solutions. This probably means explicit > support for all short term solutions in all intermediate > implementations, and some kind of meta-solution that makes it possible > for intermediate and long term solutions to work together. > > Some comments on the requirements document in this light: > > By multihoming, a site must be able to distribute both inbound and > outbound traffic between multiple transit providers. This > requirement is for concurrent use of the multiple transit > providers, > not just the usage of one provider over one interval of time and > another provider over a different interval. > > Short: since we can do this for inbound with multiple A records and for > outbound with some (static) routes, at solution doesn't really have to > support this > Intermediate: highly desired / required > Long: required, preferably even load balance a single session over > multiple paths > > By multihoming, a site must be able to protect itself from > performance difficulties directly between the site's transit > providers. > > This is a good example of something we could easily drop for short term > solutions. > > Multihoming solutions must provide re-homing transparency for > transport-layer sessions; i.e. exchange of data between devices on > the multihomed site and devices elsewhere on the Internet may > proceed > with no greater interruption than that associated with the > transient > packet loss during the re-homing event. > > Again, something that would definitely be a requirement for > intermediate or long term solutions, but if we can have the ability to > set up new sessions for a short term solution, that's better than > nothing. > > A new IPv6 multihoming architecture must scale to accommodate > orders > of magnitude more multihomed sites without imposing unreasonable > requirements on the routing system. > > Short: has to be much better than simple PI, but a billion or more > isn't necessary > Intermediate: required, as there may not be a long term solution after > all > Long: required > > The solution may require changes to IPv6 router implementations, > but > these changes must be either minor, or in the form of logically > separate functions added to existing functions. > > Short: required > Intermediate: required > Long: desired: forklift upgrades are bad, but if we then get the > perfect solution it may be worth it and/or we can wait out the natural > economic life span of existing equipment > > The solution must not destroy IPv6 connectivity for a legacy host > implementing RFC 2373 [5], RFC 2460 [7], RFC 2553 [8] and other > basic > IPv6 specifications current in November 2002. That is to say, if a > host can work in a single-homed site, it must still be able to work > multihoming. > > Short: required > Intermediate: required > Long: interoperability should remain but we can expect people to > upgrade at some point, so just "desired" > > A multihoming strategy may require cooperation between a site and > its > transit providers, but must not require cooperation (relating > specifically to the multihomed site) directly between the transit > providers. > > Short: required (not all ISPs will upgrade immediately) > Intermediate: highly desired (if this is the only downside, we can live > with it, for a while anyway) > Long: required > > Harold Grovesteen > Iljitsch van Beijnum From owner-multi6@ops.ietf.org Tue Apr 22 20:02:07 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02153 for ; Tue, 22 Apr 2003 20:02:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 1987et-0004C0-00 for multi6-data@psg.com; Tue, 22 Apr 2003 23:58:43 +0000 Received: from pheriche.sun.com ([192.18.98.34]) by psg.com with esmtp (Exim 3.36 #1) id 1987er-0004Bm-00 for multi6@ops.ietf.org; Tue, 22 Apr 2003 23:58:41 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by pheriche.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id RAA18169; Tue, 22 Apr 2003 17:58:39 -0600 (MDT) Received: from localhost (sml-mtv29-dhcp-33-135.Eng.Sun.COM [152.70.33.135]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h3MNwaL10842; Wed, 23 Apr 2003 01:58:36 +0200 (MEST) Date: Wed, 23 Apr 2003 01:58:22 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Resolving geo discussions To: Kurt Erik Lindqvist Cc: Tim Chown , multi6@ops.ietf.org In-Reply-To: "Your message with ID" <54BCC442-7249-11D7-BC5F-000393AB1404@kurtis.pp.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-13.0 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk > As for what should be included, well we (IMHO) need to change the > charter, or at least look at doing so and update the milestones. There > are a number or proposals floating around, of which not all even have > made it as IDs. Having presentations of all in Vienna, at a depth that > gives justice to all proposals, might be a bit time consuming, but > perhaps we need to. Instead of reviewing proposals in depth it might make more sense to task somebody with doing a compare and contrast between the different proposals and use such a presentation as the focus for discussion. That approach tends to lead to more focus on the problem and the possible approaches with less of "my proposal is better than yours" type of discussion. Erik From owner-multi6@ops.ietf.org Wed Apr 23 01:34:00 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08319 for ; Wed, 23 Apr 2003 01:34:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 198Cu0-000Jun-00 for multi6-data@psg.com; Wed, 23 Apr 2003 05:34:40 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 198Cty-000Jua-00 for multi6@ops.ietf.org; Wed, 23 Apr 2003 05:34:38 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h3N5Y0A17446; Wed, 23 Apr 2003 08:34:00 +0300 Date: Wed, 23 Apr 2003 08:33:59 +0300 (EEST) From: Pekka Savola To: Erik Nordmark cc: Kurt Erik Lindqvist , Tim Chown , Subject: Re: Resolving geo discussions In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-31.7 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 23 Apr 2003, Erik Nordmark wrote: > > As for what should be included, well we (IMHO) need to change the > > charter, or at least look at doing so and update the milestones. There > > are a number or proposals floating around, of which not all even have > > made it as IDs. Having presentations of all in Vienna, at a depth that > > gives justice to all proposals, might be a bit time consuming, but > > perhaps we need to. > > Instead of reviewing proposals in depth it might make more sense > to task somebody with doing a compare and contrast between the different > proposals and use such a presentation as the focus for discussion. > > That approach tends to lead to more focus on the problem and the possible > approaches with less of "my proposal is better than yours" type of discussion. Totally agree here. We shouldn't discuss proposals, but rather talk in some "meta" multihoming level. We need to have better picture what we want and can do before getting down to business and digging holes... -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Fri Apr 25 06:04:05 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01903 for ; Fri, 25 Apr 2003 06:04:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19903k-0007IF-00 for multi6-data@psg.com; Fri, 25 Apr 2003 10:04:00 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 19903h-0007I1-00 for multi6@ops.ietf.org; Fri, 25 Apr 2003 10:03:58 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h3PA3tk09470 for ; Fri, 25 Apr 2003 13:03:55 +0300 Date: Fri, 25 Apr 2003 13:03:55 +0300 (EEST) From: Pekka Savola To: multi6@ops.ietf.org Subject: New draft: Now What? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-12.3 required=5.0 tests=BAYES_01,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Hi, As promised, here's a new draft which has been partially extracted from my MSc (also plugged in here earlier): http://www.netcore.fi/pekkas/ietf/draft-savola-multi6-nowwhat-00.txt (It has also been submitted to the I-D repository, and will probably appear next week -- but I know you guys like spending time reading drafts during the weekend, so here we go.. :-) In particular the goal is to make us able to focus our thoughts a bit and try to break the site multihoming into a bit smaller pieces. It's 15 pages; the abstract is below. Have fun. Abstract ROUTING ARCHITECT'S WARNING: flagrant IPv4 site multihoming practices cause a significant increase the routing table size, change rates and instability, the tragedy of the commons by encouraging selfish routing practices, the exhaustion of the 16-bit AS number space, and may collapse the Internet interdomain routing architecture. As there has been a desire to avoid similar problems as seen with IPv4, the use of similar techniques to achieve site multihoming has been prevented operationally in IPv6. However, the long effort to proceed with other IPv6 multihoming mechanisms has produced lots of heat but little light. This memo tries to list available techniques, split the organizations to different types to separately examine their multihoming needs, to look at the immediate and short-term solutions for these organization types, and to list a few immediate action items on how to proceed with IPv6 site multihoming. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Sat Apr 26 08:57:43 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19775 for ; Sat, 26 Apr 2003 08:57:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 199PFr-0002Ke-00 for multi6-data@psg.com; Sat, 26 Apr 2003 12:58:11 +0000 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 199PFp-0002KM-00 for multi6@ops.ietf.org; Sat, 26 Apr 2003 12:58:09 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h3QCusE87175 for ; Sat, 26 Apr 2003 14:56:55 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Sat, 26 Apr 2003 14:56:53 +0200 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: IETF multihoming powder: just add IPv6 and stir From: Iljitsch van Beijnum To: multi6@ops.ietf.org Content-Transfer-Encoding: 7bit Message-Id: <8DBCD09F-77E6-11D7-9B9F-00039388672E@muada.com> X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-9.7 required=5.0 tests=BAYES_01,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit That's not going to happen. If we want to make progress at the Vienna meeting something has to give. I agree with Erik that a detailed discussion of all proposals (or even all drafts) isn't going to do much good. Not that we could fit that into a reasonable timeslot anyway. But I don't think asking one person to go over all the proposals is the solution, as the current proposals are typically so complex it's impossible to do them justice in a significantly shorter form than their drafts. It seems to me the problem is that everyone brings different assumptions and requirements to the table. For instance, the HIP people are mainly interested in security and mobility, and solving multihoming is secondary to those goals. Christian Huitema's proposals are built around the idea that we can only make baby steps and should work as much as possible with existing mechanisms. Michel Py doesn't mind much that both ends must be changed in order to support MHAP; in my geo stuff I don't worry about the fact that this will impose limits on the network topology; and the GSE++ people aren't all that concerned with the fact that GSE needs changes to not just one, but many aspects of IP: routers, hosts, DNS. As long as this is the case I don't think it's possible to reach consensus on protocols. You can't ask people to agree on the best way to do something if they feel that something shouldn't be done in the first place. (And as long as they think it's still possible to prevent the "something" from happening.) So we should use Vienna to decide WHAT we want to do, the HOW is then only a question of engineering, which we're supposed to know how to do here in the IETF. It looks like the type of solution that most people like / the least people hate is a GSE++/8+8/6+2+10/16+16 type of solution. Such a solution is probably the least ambitious that can still be expected to work well in the long term and probably the most ambitious we can expect to be deployed before we run out of IPv6^H^H^H^HIPv4 address space. If we can't reach rough consensus on this as a general approach it is extremely unlikely we can reach it on something else. Note that agreeing on this approach doesn't mean all other proposals should be off the table immediately: if they provide additional benefits (for instance, they can be deployed before the "official" solution is ready) they should be viable so individual authors can keep working on them as they see fit. From owner-multi6@ops.ietf.org Sat Apr 26 14:53:24 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25718 for ; Sat, 26 Apr 2003 14:53:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 199UoW-000LAQ-00 for multi6-data@psg.com; Sat, 26 Apr 2003 18:54:20 +0000 Received: from ip166.usw12.rb1.bel.nwlink.com ([209.20.253.166] helo=ran.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 199UoR-000LA6-00 for multi6@ops.ietf.org; Sat, 26 Apr 2003 18:54:15 +0000 Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.14) id 199UoQ-000AV8-6l; Sat, 26 Apr 2003 11:54:14 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sat, 26 Apr 2003 11:54:13 -0700 To: Iljitsch van Beijnum Cc: multi6@ops.ietf.org Subject: Re: Resolving geo discussions References: <46B794C6-7201-11D7-A7F7-00039388672E@muada.com> Message-Id: X-Spam-Status: No, hits=-16.3 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> i also suspect that this working group might get more done if the >> filibustering by folk riding lame or long-dead hobby horses would >> dismount, take a break, go into the saloon for a beer, and let >> others talk too. > Silly me for thinking that writing drafts and providing feedback on > those written by other people might help. endless repition != feedback From owner-multi6@ops.ietf.org Mon Apr 28 07:29:31 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27139 for ; Mon, 28 Apr 2003 07:29:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19A6pH-0008KY-00 for multi6-data@psg.com; Mon, 28 Apr 2003 11:29:39 +0000 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 19A6pE-0008KM-00 for multi6@ops.ietf.org; Mon, 28 Apr 2003 11:29:36 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27025; Mon, 28 Apr 2003 07:26:45 -0400 (EDT) Message-Id: <200304281126.HAA27025@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: multi6@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-savola-multi6-nowwhat-00.txt Date: Mon, 28 Apr 2003 07:26:45 -0400 X-Spam-Status: No, hits=-2.7 required=5.0 tests=BAYES_10,MIME_BOUND_NEXTPART,NO_REAL_NAME,TO_MALFORMED version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IPv6 Site Multihoming: Now What? Author(s) : P. Savola Filename : draft-savola-multi6-nowwhat-00.txt Pages : 15 Date : 2003-4-25 ROUTING ARCHITECT'S WARNING: flagrant IPv4 site multihoming practices cause a significant increase the routing table size, change rates and instability, the tragedy of the commons by encouraging selfish routing practices, the exhaustion of the 16-bit AS number space, and may collapse the Internet interdomain routing architecture. As there has been a desire to avoid similar problems as seen with IPv4, the use of similar techniques to achieve site multihoming has been prevented operationally in IPv6. However, the long effort to proceed with other IPv6 multihoming mechanisms has produced lots of heat but little light. This memo tries to list available techniques, split the organizations to different types to separately examine their multihoming needs, to look at the immediate and short-term solutions for these organization types, and to list a few immediate action items on how to proceed with IPv6 site multihoming. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-savola-multi6-nowwhat-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-savola-multi6-nowwhat-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-savola-multi6-nowwhat-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-4-25120841.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-savola-multi6-nowwhat-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-savola-multi6-nowwhat-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-4-25120841.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-multi6@ops.ietf.org Wed Apr 30 10:19:59 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05729 for ; Wed, 30 Apr 2003 10:19:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19AsS1-000Pie-00 for multi6-data@psg.com; Wed, 30 Apr 2003 14:20:49 +0000 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 19AsRx-000PiP-00 for multi6@ops.ietf.org; Wed, 30 Apr 2003 14:20:46 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h3UEJUE97244 for ; Wed, 30 Apr 2003 16:19:30 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Wed, 30 Apr 2003 16:19:31 +0200 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: updating GSE for the new millennium From: Iljitsch van Beijnum To: multi6@ops.ietf.org Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-9.7 required=5.0 tests=BAYES_01,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit We've been talking about GSE earlier this month before we got side-tracked. I think it's time to see what a descendent of the GSE family would look like in the third millennium, so I want to write a draft. Hopefully this will give us something useful to talk about in Vienna. What I'd like to do is take input from everyone and incorporate this as much as possible in this draft. That probably means more options and more complexity that we'd like to see in an actual protocol, but for now that's fine: we can always prune later. If there is reasonable consensus on something, I'll use it. If there are several ways to do something that aren't mutually exclusive, I'll use all of them. If there is no feedback, I'll use my own judgement... The first order of business is the address rewriting. It seems to me that the different options here (GSE-like one-way rewriting upper bits with globally unique lower bits, MHAP double rewriting) can be accommodated by doing the following: When transmitting, for both the source and destination address: take a globally unique N bit label and map to one of several possible IPv6 address suitable for routing associated with this label. When receiving, map the addresses back to labels. For the source when transmitting or the destination when receiving, the rewriter can presumably easily find the additional information needed to compelete the mapping in its configuration, but for the destination when transmitting or the source when receiving it must first discover the mapping. Is this workable? Two additional questions: - Is adding options or tunnel headers an option, or would this make this scheme too unattractive over IPv4-style multihoming? - Can packets only be rewritten once, or can this happen several times? From owner-multi6@ops.ietf.org Wed Apr 30 20:45:04 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01643 for ; Wed, 30 Apr 2003 20:45:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19B2Ca-000GZy-00 for multi6-data@psg.com; Thu, 01 May 2003 00:45:32 +0000 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #1) id 19B2CL-000GWc-00 for multi6@ops.ietf.org; Thu, 01 May 2003 00:45:17 +0000 Received: from nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 03D0B137F18; Wed, 30 Apr 2003 17:45:13 -0700 (PDT) Date: Wed, 30 Apr 2003 17:45:14 -0700 Subject: Re: updating GSE for the new millennium Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: Iljitsch van Beijnum From: David Conrad In-Reply-To: Message-Id: <2BB75AB3-7B6E-11D7-B0B2-000393DB42B2@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Iljitsch, On Wednesday, April 30, 2003, at 07:19 AM, Iljitsch van Beijnum wrote: > We've been talking about GSE earlier this month before we got > side-tracked. I think it's time to see what a descendent of the GSE > family would look like in the third millennium, so I want to write a > draft. Hopefully this will give us something useful to talk about in > Vienna. Hmm. I am doing the same thing (although I'm not planning on being in Vienna). > What I'd like to do is take input from everyone and incorporate this > as much as possible in this draft. That probably means more options > and more complexity that we'd like to see in an actual protocol, but > for now that's fine: we can always prune later. I would suggest starting the other direction -- the IETF already has way too many drafts that try to be all things to all people. Start with a simple, easily understood base and see how far that gets you. > The first order of business is the address rewriting. It seems to me > that the different options here (GSE-like one-way rewriting upper bits > with globally unique lower bits, MHAP double rewriting) can be > accommodated by doing the following: > > When transmitting, for both the source and destination address: take a > globally unique N bit label and map to one of several possible IPv6 > address suitable for routing associated with this label. When > receiving, map the addresses back to labels. Depending on your approach, it may not be necessary to rewrite the source address. > For the source when transmitting or the destination when receiving, > the rewriter can presumably easily find the additional information > needed to compelete the mapping in its configuration, but for the > destination when transmitting or the source when receiving it must > first discover the mapping. Yes. I believe it'll turn out that this discovery is where the complexity (political if not technical) will lie. I do not believe it to be a difficult technical problem, however I'm sure any solution proposed will be controversial. > Is this workable? I think so. > Two additional questions: > - Is adding options or tunnel headers an option, I don't think so. Options increase complexity as they result in making it impossible to do "in-place" rewrites. You generally have to synthesize a full header then append the data of the original packet after the options. Tunnel headers get you into trouble with MTUs and fragmentation. Avoiding these if possible would be a good idea I believe. > - Can packets only be rewritten once, or can this happen several times? Address rewriting (at least as described above) would appear to me to be end-to-end transparent. As such, I'd say yes, although I'm not sure I see the point. Rgds, -drc From owner-multi6@ops.ietf.org Wed Apr 30 22:25:49 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03293 for ; Wed, 30 Apr 2003 22:25:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19B3nD-000Kvy-00 for multi6-data@psg.com; Thu, 01 May 2003 02:27:27 +0000 Received: from jazz-1.trumpet.com.au ([203.5.119.62]) by psg.com with esmtp (Exim 3.36 #1) id 19B3n8-000Kvk-00 for multi6@ops.ietf.org; Thu, 01 May 2003 02:27:23 +0000 Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id MAA15522; Thu, 1 May 2003 12:27:09 +1000 (EST) Date: Thu, 1 May 2003 12:27:09 +1000 (EST) From: Peter Tattam To: David Conrad cc: Iljitsch van Beijnum , multi6@ops.ietf.org Subject: Re: updating GSE for the new millennium In-Reply-To: <2BB75AB3-7B6E-11D7-B0B2-000393DB42B2@nominum.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-31.5 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 30 Apr 2003, David Conrad wrote: > Iljitsch, > > On Wednesday, April 30, 2003, at 07:19 AM, Iljitsch van Beijnum wrote: > > We've been talking about GSE earlier this month before we got > > side-tracked. I think it's time to see what a descendent of the GSE > > family would look like in the third millennium, so I want to write a > > draft. Hopefully this will give us something useful to talk about in > > Vienna. > > Hmm. I am doing the same thing (although I'm not planning on being in > Vienna). > > > What I'd like to do is take input from everyone and incorporate this > > as much as possible in this draft. That probably means more options > > and more complexity that we'd like to see in an actual protocol, but > > for now that's fine: we can always prune later. > > I would suggest starting the other direction -- the IETF already has > way too many drafts that try to be all things to all people. Start > with a simple, easily understood base and see how far that gets you. > > > The first order of business is the address rewriting. It seems to me > > that the different options here (GSE-like one-way rewriting upper bits > > with globally unique lower bits, MHAP double rewriting) can be > > accommodated by doing the following: > > > > When transmitting, for both the source and destination address: take a > > globally unique N bit label and map to one of several possible IPv6 > > address suitable for routing associated with this label. When > > receiving, map the addresses back to labels. > > Depending on your approach, it may not be necessary to rewrite the > source address. I don't think it's necessary. The less changes to the packet, the better in my opinion. Just map the N bit label at whatever point a decision has to be made to forward the packet outside the site. I think only one relabelling should be allowed and the decision to relabel be based on on the pre-labelled address. I would presume that a MH address be identifiable by just looking at the address (i.e. the top M (where M < N) bits represent a particular class of MH addresses). Once the labelling is done, it can be sent all the way to the end host. If one retains the prelabelled source address, this is an additional tag to the end point that the packet can have it's label removed. > > > For the source when transmitting or the destination when receiving, > > the rewriter can presumably easily find the additional information > > needed to compelete the mapping in its configuration, but for the > > destination when transmitting or the source when receiving it must > > first discover the mapping. > > Yes. I believe it'll turn out that this discovery is where the > complexity (political if not technical) will lie. I do not believe it > to be a difficult technical problem, however I'm sure any solution > proposed will be controversial. > The main issues I can see behind restoring the original packet would be TCP/UDP checksums and IPSec. If the two end points are labelling aware, measures can be taken to ignore the label from the checksums or replace it for IPsec, otherwise it would be up to labelling boxen (border routers or other) to do this on behalf of the hosts which are unaware of the labelling possibility. A site should also know the full permutations of labelled packets and could check for each of them, however checking the source address would save all this checking. One issue I just thought of is what happens if a physical site represents multiple logical MH sites. Much of this discussion centres on a physical site only having one logical MH site prefix (we are talking about prelabelled addresses here, not live transit addresses). When there are several possible MH site addresses, one would have to match the post labelled transit addresses to the MH site prefix that they pertain to. If one did not need to rewrite the packets and just let the end host sort out the mess (it presumably would be fully aware of the multiple logical sites), that would be ultimately a lot more workable. > > Is this workable? > > I think so. > > > Two additional questions: > > - Is adding options or tunnel headers an option, > > I don't think so. Options increase complexity as they result in making > it impossible to do "in-place" rewrites. You generally have to > synthesize a full header then append the data of the original packet > after the options. Tunnel headers get you into trouble with MTUs and > fragmentation. Avoiding these if possible would be a good idea I > believe. > > > - Can packets only be rewritten once, or can this happen several times? > > Address rewriting (at least as described above) would appear to me to > be end-to-end transparent. As such, I'd say yes, although I'm not sure > I see the point. I think if you apply the rule that a prelabelled packet can only be labelled once (at entry to the global part of the network), the only possibility of extra rewriting would be if the packet was restored to it's original prelabelled state (I can't see when this would happen inside the global transit network, but it might). I wonder if these ideas might receive more support if the terminology of labelling were used instead of GSE. We'd be more likely to draw in some support from the MPLS mob. > > Rgds, > -drc > > > Peter -- Peter R. Tattam peter@trumpet.com Managing Director, Trumpet Software International Pty Ltd Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210