From owner-multi6@ops.ietf.org Thu Jan 2 07:47: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 HAA03778 for ; Thu, 2 Jan 2003 07:47:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18U4iv-000NoX-00 for multi6-data@psg.com; Thu, 02 Jan 2003 04:45:21 -0800 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 18U4is-000NoJ-00 for multi6@ops.ietf.org; Thu, 02 Jan 2003 04:45:18 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h02CjFp04129 for ; Thu, 2 Jan 2003 14:45:15 +0200 Date: Thu, 2 Jan 2003 14:45:15 +0200 (EET) From: Pekka Savola To: multi6@ops.ietf.org Subject: multi-homing vs multi-connecting Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-0.1 required=5.0 tests=SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Hello, There is one interesting issue brought up in draft-ietf-multi6-v4-multihoming-00.txt; there the terms "multi-homed" (always different ISP's) and "multi-attached" (same ISP) are separated. I don't think this terminology has been well established? At least as far as I've seen, multihoming has been used to refer to both (to some extent). But nonetheless, the separation is interesting. Multi-attaching, used with some techniques, provides a number of protections against failure modes people often want to cover when requiring multi-homing. The main thing it does not provide is the ability to switch providers at will with little effort (but then again, some other proposals like draft-kurtis-multihoming-longprefix do not provide that either). Is it necessary to require a solution to "real" multi-homing problem provided that multi-connecting mechanisms would provide a sufficient level of control and protection? -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-multi6@ops.ietf.org Thu Jan 2 09:59: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 JAA05802 for ; Thu, 2 Jan 2003 09:59:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18U6pZ-0000z8-00 for multi6-data@psg.com; Thu, 02 Jan 2003 07:00:21 -0800 Received: from ginger.lcs.mit.edu ([18.26.0.82]) by psg.com with esmtp (Exim 3.36 #2) id 18U6pV-0000yv-00 for multi6@ops.ietf.org; Thu, 02 Jan 2003 07:00:17 -0800 Received: from ginger.lcs.mit.edu (localhost [127.0.0.1]) by ginger.lcs.mit.edu (8.12.6/8.12.6) with ESMTP id h02F0EMY021852; Thu, 2 Jan 2003 10:00:14 -0500 Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.12.6/8.12.6/Submit) id h02F0D70021851; Thu, 2 Jan 2003 10:00:13 -0500 Date: Thu, 2 Jan 2003 10:00:13 -0500 From: "J. Noel Chiappa" Message-Id: <200301021500.h02F0D70021851@ginger.lcs.mit.edu> To: multi6@ops.ietf.org Subject: Re: multi-homing vs multi-connecting Cc: jnc@ginger.lcs.mit.edu X-Spam-Status: No, hits=0.8 required=5.0 tests=SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: Pekka Savola > the terms "multi-homed" (always different ISP's) and "multi-attached" > (same ISP) are separated. > I don't think this terminology has been well established? At least as > far as I've seen, multihoming has been used to refer to both (to some > extent). Another place where one term, "multi-homing", has been used to cover two fairly different things are with so-called "site multi-homing" and "host multi-homing" - the latter being a single host with multiple physical interfaces. Noel From owner-multi6@ops.ietf.org Thu Jan 2 10:23: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 KAA06398 for ; Thu, 2 Jan 2003 10:23:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18U7DV-0001mc-00 for multi6-data@psg.com; Thu, 02 Jan 2003 07:25:05 -0800 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 18U7DS-0001mB-00 for multi6@ops.ietf.org; Thu, 02 Jan 2003 07:25:02 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h02FOwM04958; Thu, 2 Jan 2003 17:24:58 +0200 Date: Thu, 2 Jan 2003 17:24:57 +0200 (EET) From: Pekka Savola To: "J. Noel Chiappa" cc: multi6@ops.ietf.org Subject: Re: multi-homing vs multi-connecting In-Reply-To: <200301021500.h02F0D70021851@ginger.lcs.mit.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Thu, 2 Jan 2003, J. Noel Chiappa wrote: > > the terms "multi-homed" (always different ISP's) and "multi-attached" > > (same ISP) are separated. > > I don't think this terminology has been well established? At least as > > far as I've seen, multihoming has been used to refer to both (to some > > extent). > > Another place where one term, "multi-homing", has been used to cover two > fairly different things are with so-called "site multi-homing" and > "host multi-homing" - the latter being a single host with multiple > physical interfaces. Hmm.. I group these differently (though I can see why the above could also be a useful classification), basically: 1) Host multi-homing (strictly speaking, "node" multihoming..) a) multiple interfaces and addresses: e.g. a mobile device with both GPRS+WLAN interface active b) one interface and more addresses: network is providing multiple prefixes (of possibly different properties). It is the _host's task_ to deal with the issues. * a special case of either a) and b) are mechanisms employing a mapping function between addresses (HIP, MIPv6 to a lesser degree of success) or parts of addresses (LIN6). 2) Site multi-homing Either something like 3) possibly restricted a bit or the framework for 1) 3) ISP multi-homing * BGP-only, trivial case .. so it would seem you'd rather place 1.b) under 2) as a network providing multiple prefixes is a already a site. From IPv4 perspective, it's definitely more in the 1), but in IPv6, perhaps a bit closer to 2). Does this make sense? Thoughts? (Actually I'm writing a thesis on the subject.. :-) -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-multi6@ops.ietf.org Thu Jan 2 10:28: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 KAA06425 for ; Thu, 2 Jan 2003 10:28:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18U7JS-0001yL-00 for multi6-data@psg.com; Thu, 02 Jan 2003 07:31:14 -0800 Received: from ebola.psc.edu ([128.182.61.124] helo=localhost) by psg.com with esmtp (Exim 3.36 #2) id 18U7JM-0001xr-00 for multi6@ops.ietf.org; Thu, 02 Jan 2003 07:31:08 -0800 Received: from ebola.psc.edu (localhost [127.0.0.1]) by localhost (8.12.2/8.12.2) with ESMTP id h02FUrpP001310; Thu, 2 Jan 2003 10:30:54 -0500 (EST) Date: Thu, 02 Jan 2003 10:30:52 -0500 From: "Michael H. Lambert" To: "J. Noel Chiappa" cc: multi6@ops.ietf.org Subject: Re: multi-homing vs multi-connecting Message-ID: <3209772.1041503452@ebola.psc.edu> In-Reply-To: <200301021500.h02F0D70021851@ginger.lcs.mit.edu> References: <200301021500.h02F0D70021851@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=-1.3 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On Thursday, 2 January 2003 10:00 -0500 "J. Noel Chiappa" wrote: > Another place where one term, "multi-homing", has been used to cover two > fairly different things are with so-called "site multi-homing" and "host > multi-homing" - the latter being a single host with multiple physical > interfaces. Is there a fundamental difference in these two "types" of multihoming? In the IPv4 world, I would argue that there is not--it's just that the site router has better knowledge with which to make an interface selection than does the host (listen to RIP?). Other than adding the non-trivial problem of source address selection to the mix, I don't see that IPv6 changes things. The distinction seems to rest primarily in the WG charter. Michael +-----------------------------------------------------------------------+ | Michael H. Lambert, Network Engineer Phone: +1 412 268-4960 | | Pittsburgh Supercomputing Center FAX: +1 412 268-8200 | | 4400 Fifth Avenue, Pittsburgh, PA 15213 lambert@psc.edu | +-----------------------------------------------------------------------+ From owner-multi6@ops.ietf.org Thu Jan 2 11:06: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 LAA07422 for ; Thu, 2 Jan 2003 11:06:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18U7ty-0003Cs-00 for multi6-data@psg.com; Thu, 02 Jan 2003 08:08:58 -0800 Received: from ginger.lcs.mit.edu ([18.26.0.82]) by psg.com with esmtp (Exim 3.36 #2) id 18U7tl-0003AW-00 for multi6@ops.ietf.org; Thu, 02 Jan 2003 08:08:45 -0800 Received: from ginger.lcs.mit.edu (localhost [127.0.0.1]) by ginger.lcs.mit.edu (8.12.6/8.12.6) with ESMTP id h02G8hMY022167; Thu, 2 Jan 2003 11:08:43 -0500 Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.12.6/8.12.6/Submit) id h02G8hEB022164; Thu, 2 Jan 2003 11:08:43 -0500 Date: Thu, 2 Jan 2003 11:08:43 -0500 From: "J. Noel Chiappa" Message-Id: <200301021608.h02G8hEB022164@ginger.lcs.mit.edu> To: multi6@ops.ietf.org Subject: Re: multi-homing vs multi-connecting Cc: jnc@ginger.lcs.mit.edu X-Spam-Status: No, hits=1.1 required=5.0 tests=SPAM_PHRASE_03_05 version=2.43 X-Spam-Level: * Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: "Michael H. Lambert" >> two fairly different things are with so-called "site multi-homing" and >> "host multi-homing" - the latter being a single host with multiple >> physical interfaces. > Is there a fundamental difference in these two "types" of multihoming? Yes, I think - although the two can have an area of overlap where blend into each other, as you scale up. If you have a host which is host multi-homed to widely different places in the topology, it's crystal clear that you can't support this in the routing. (No global host routes.) Therefore, if you want to do many of the more powerful robustness things that multi-homing gives you, you have to separate location and identity, and have that host manage multiple addresses. (Of course, if you're willing to always have a particular connection associated with a particular interface, and always use only that interface, then this is no longer true - but at that point you're doing less powerful robustness things. This may still be enough, though, in a world in which the connection is no longer so important, and things like cookies are used to keep track of the identity of the partner across multiple connections from different [usually dial-up, but the mechanism works for multiple interfaces] addresses.) At the other end of the scale, some of the more complex site multi-homing things can really only be done through the routing (e.g. if you have N local ISP's which are in turn connected to M global ISP's) - although it often needs a more powerful routing architecture than the lame one we have now. And then in the middle there's this region where it looks like the way to handle small-site multi-homing is to use multiple addresses, so the mechanism looks like host-multihoming even though no single host has multiple interfaces. > In the IPv4 world, I would argue that there is not The IPv4 world is a second-rate beginner's quick hack in many ways, including mobility, routing and multi-homing, and I suggest you delete all knowledge of if from your mind. I refuse to discuss it. > Other than adding the non-trivial problem of source address selection to > the mix, I don't see that IPv6 changes things. Classical IPv6 dosn't. That's a big part of its problems. Noel From owner-multi6@ops.ietf.org Thu Jan 2 11:25: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 LAA07729 for ; Thu, 2 Jan 2003 11:25:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18U8DI-0003q1-00 for multi6-data@psg.com; Thu, 02 Jan 2003 08:28:56 -0800 Received: from ginger.lcs.mit.edu ([18.26.0.82]) by psg.com with esmtp (Exim 3.36 #2) id 18U8DF-0003pV-00 for multi6@ops.ietf.org; Thu, 02 Jan 2003 08:28:53 -0800 Received: from ginger.lcs.mit.edu (localhost [127.0.0.1]) by ginger.lcs.mit.edu (8.12.6/8.12.6) with ESMTP id h02GSqMY022271; Thu, 2 Jan 2003 11:28:52 -0500 Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.12.6/8.12.6/Submit) id h02GSpTU022270; Thu, 2 Jan 2003 11:28:51 -0500 Date: Thu, 2 Jan 2003 11:28:51 -0500 From: "J. Noel Chiappa" Message-Id: <200301021628.h02GSpTU022270@ginger.lcs.mit.edu> To: multi6@ops.ietf.org Subject: Re: multi-homing vs multi-connecting Cc: jnc@ginger.lcs.mit.edu X-Spam-Status: No, hits=1.1 required=5.0 tests=SPAM_PHRASE_03_05 version=2.43 X-Spam-Level: * Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: Pekka Savola > I group these differently .. basically: > 1) Host multi-homing .. > a) multiple interfaces and addresses: e.g. a mobile device with both > GPRS+WLAN interface active I understand the class, but caution you not to use mobile examples because it will confuse many people... :-) > b) one interface and more addresses: network is providing multiple > prefixes (of possibly different properties). It is the _host's task_ to > deal with the issues. My reaction to this classification is that you need to be careful not to mix classifications based on the *kind of problem* one is trying to solve (which is where my host/site distinction comes from) with classifications based on the *mechanism* one is using. Your classification is also an interesting one, but on the surface, because of your mention of multiple addresses, it's a mechanism classification - not that that's bad, just different. Of course, your classification is also in some ways a problem classification, because the former is the "classical" host/node multi-homing, whereas the latter is really a subset of site multi-homing; more specifically, that subset that we've been thinking is best handled with multiple addresses. After reading Michael Lambert's message, I've been trying to work out if there's a useful division at an architectural level, which would be yet another level of classification, but I'm going to have to ponder that for a while. I mean, at some point there is an architectural division where multi-homing turns into routing - e.g. if you have two tiers of upstream providers, local ones L1-L3, and global ones G1-G3, all cross-connected, and you want to specify which pair traffic to a particular destination takes, that's really a routing problem, not a multi-homing problem. Whereas the single host with multiple interfaces is clearly multi-homing. But I need to think about it more... > so it would seem you'd rather place 1.b) under 2) as a network providing > multiple prefixes is a already a site. Yes, you only get 1.b if you have an entire network with multiple addresses, and you only get that (presumably) if that network is multi-homed, ergo it's site multi-homing. So maybe site multi-homing needs to be split up into sub-classes - whether based on the *mechanism* used to support it (multiple addresses, routing, whatever), or on some significant *situational* difference (e.g. a stub site which is multi-homed to different local ISP's, versus some more complex situation). > From IPv4 perspective ... but in IPv6 See previous message! Empty your mind of all this old junk! :-) Noel From owner-multi6@ops.ietf.org Thu Jan 2 13:37: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 NAA11124 for ; Thu, 2 Jan 2003 13:37:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18UAEg-0008U5-00 for multi6-data@psg.com; Thu, 02 Jan 2003 10:38:30 -0800 Received: from mail2.microsoft.com ([131.107.3.124]) by psg.com with esmtp (Exim 3.36 #2) id 18UAEO-0008Rb-00 for multi6@ops.ietf.org; Thu, 02 Jan 2003 10:38:12 -0800 Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 2 Jan 2003 10:37:41 -0800 Received: from 157.54.8.23 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 02 Jan 2003 10:37:41 -0800 Received: from RED-IMC-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 2 Jan 2003 10:37:41 -0800 Received: from WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 2 Jan 2003 10:37:41 -0800 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.3710.0); Thu, 2 Jan 2003 10:37:36 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: multi-homing vs multi-connecting Date: Thu, 2 Jan 2003 10:37:40 -0800 Message-ID: Thread-Topic: multi-homing vs multi-connecting Thread-Index: AcKyef/4iIj7/M6eSYSiMkbL6M8ZGQAEyS6A From: "Christian Huitema" To: "J. Noel Chiappa" , X-OriginalArrivalTime: 02 Jan 2003 18:37:36.0196 (UTC) FILETIME=[05308040:01C2B28E] X-Spam-Status: No, hits=-0.3 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA11124 > > Other than adding the non-trivial problem of source address > selection to > > the mix, I don't see that IPv6 changes things. > > Classical IPv6 dosn't. That's a big part of its problems. Depends what you call classical IPv6. If you throw in the support for "binding update", then IPv6 does a reasonable job at "host multi-homing", and I believe that we only need a limited amount of additional work to support "small site multi-homing"; essentially, you have to get around egress filtering. On the other hand, I certainly agree with your assessment of the more complexes forms of multi-homing, and the data explosion that occurs if we want to have site connected to N providers also choose the path through M upstream providers. But we must be aware that the problem here is not just graph theory; there are also economic/business issues that affect the willingness of downstream providers to let customers choose an upstream path. -- Christian Huitema From owner-multi6@ops.ietf.org Fri Jan 3 23:30: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 XAA25281 for ; Fri, 3 Jan 2003 23:30:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Ufy6-0000JV-00 for multi6-data@psg.com; Fri, 03 Jan 2003 20:31:30 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 18Ufxu-0000HH-00 for multi6@ops.ietf.org; Fri, 03 Jan 2003 20:31:18 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h03KhXb57705; Fri, 3 Jan 2003 21:43:33 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Fri, 3 Jan 2003 21:43:32 +0100 (CET) From: Iljitsch van Beijnum To: "J. Noel Chiappa" cc: Subject: Re: multi-homing vs multi-connecting In-Reply-To: <200301021608.h02G8hEB022164@ginger.lcs.mit.edu> Message-ID: <20030103213244.J53797-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Thu, 2 Jan 2003, J. Noel Chiappa wrote: > > In the IPv4 world, I would argue that there is not > The IPv4 world is a second-rate beginner's quick hack in many ways, including > mobility, routing and multi-homing, and I suggest you delete all knowledge of > if from your mind. I refuse to discuss it. This was almost the biggest laugh I had this year... Thanks for that. (The biggest was "IPv6 will not catch on for the simple reason that it sucks.", see http://www.kuro5hin.org/comments/2002/8/26/22240/1363/149) As long as I'm wasting bandwidth: does anyone know of some way to automatically tunnel IPv4 over IPv6? It seems to me that tunneling v4 over v6 is much more powerful than the other way around, as it could allow extremely dense use of IPv4 addresses which would be useful during the transition period. Iljitsch PS. Surfing the web with v6 is cool. Shame it's so hard to get a v6-enabled browser on your Mac. Installing Apache 2 on it is easier... From owner-multi6@ops.ietf.org Fri Jan 3 23:31: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 XAA25304 for ; Fri, 3 Jan 2003 23:31:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Ufxx-0000IW-00 for multi6-data@psg.com; Fri, 03 Jan 2003 20:31:21 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 18Ufxs-0000HH-00 for multi6@ops.ietf.org; Fri, 03 Jan 2003 20:31:17 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h03Lfjw57790; Fri, 3 Jan 2003 22:41:45 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Fri, 3 Jan 2003 22:41:45 +0100 (CET) From: Iljitsch van Beijnum To: "J. Noel Chiappa" cc: Subject: Re: multi-homing vs multi-connecting In-Reply-To: <200301021628.h02GSpTU022270@ginger.lcs.mit.edu> Message-ID: <20030103222038.F53797-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Thu, 2 Jan 2003, J. Noel Chiappa wrote: > I mean, at some point there is an architectural division where multi-homing > turns into routing I don't think we should try to separate these. There are ways to multihome without involving routing, but that should never be an excuse for the routing people to ignore multihoming. > - e.g. if you have two tiers of upstream providers, local > ones L1-L3, and global ones G1-G3, all cross-connected, and you want to > specify which pair traffic to a particular destination takes, that's really a > routing problem, not a multi-homing problem. Whereas the single host with > multiple interfaces is clearly multi-homing. Multihoming makes routing more complex, as it adds more possible paths. However, wanting to influence routing beyond the immediate next hop isn't something that fits with our current paradigm. If you really want this, you need source routing. Doing it partially would be easier: simply take many addresses and then select the one that has the best routing properties. For instance, you can use G1/L1, G2/L1, G1/L2 and G2/L2 addresses and then figure out which of those four address blocks works best. Obviously this doesn't scale, but it could be useful. > > From IPv4 perspective ... but in IPv6 > See previous message! Empty your mind of all this old junk! :-) "Those who do not remember the past are condemned to repeat it." :-( Iljitsch From owner-multi6@ops.ietf.org Sat Jan 4 00:20: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 AAA26046 for ; Sat, 4 Jan 2003 00:20:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18UgmP-00031f-00 for multi6-data@psg.com; Fri, 03 Jan 2003 21:23:29 -0800 Received: from teldanex.hiit.fi ([212.68.5.99] helo=n97.nomadiclab.com) by psg.com with esmtp (Exim 3.36 #2) id 18UgmN-0002yR-00 for multi6@ops.ietf.org; Fri, 03 Jan 2003 21:23:27 -0800 Received: from nomadiclab.com (polle.local.nikander.com [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id AA8C51C; Fri, 3 Jan 2003 10:20:44 +0200 (EET) Message-ID: <3E1545C8.2050404@nomadiclab.com> Date: Fri, 03 Jan 2003 10:11:52 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.3b) Gecko/20021230 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christian Huitema Cc: multi6@ops.ietf.org Subject: Re: multi-homing vs multi-connecting References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_03_05, USER_AGENT,USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Christian Huitema wrote: > Depends what you call classical IPv6. If you throw in the support for > "binding update", then IPv6 does a reasonable job at "host > multi-homing", Well, depends what you mean with reasonable. With the new security design, mandated by the desire to make MIPv6 to work without security infrastructure, MIPv6 always generates some signalling load. That is, if a host is away from home, it must keep sending signalling packets to all its active peers to maintain the mobility state. By default the state must be refreshed about every five minutes. Furthermore, I don't quite find the requirement of having a separate home agent, i.e. a piece of infrastructure, as a reasonable design for multi-homing. > and I believe that we only need a limited amount of > additional work to support "small site multi-homing"; essentially, you > have to get around egress filtering. Another difficulty is associated with the home agents, too. If a home agent is unreachable, the mobile node also becomes unreachable as soon as it needs to refresh the mobility state, i.e., in about five minutes. Thus, you can't simply put a home agent in the "small site multi-homed" network, that just doesn't work if the home agent becomes unreachable due to a link failure. Thus, IMHO, the signalling load and the requirement of having the home agent always on-line make MIPv6 not-quite-reasonable as a end-host multi-homing or "small site multi-homing" solution. But I agree that your milage may vary. Taking a few steps back, it looks like the required security *solutions* for host-multihoming and end-host mobility are different as long as the identifiers and locators are *not* separated. That is, in the case of mobility there is one primary identifier, the home address, and it must not be "stolen". The current active address (care-of address) is more ephemeral. For end-host multi-homing, on the other hand, the multiple addresses are more or less equal. Thus, the right security solution would be to make them interchangeable at the peer end, and just to create a strong association between the alternative addresses. That is, the peer must know that these addresses (identifiers) do belong to the same host. There is no requirement of "defending" one of the addresses for the case it becomes unreachable. The situation seems to change as soon as we separate identifiers and locators. It is no more so important what locators you use right now, used in the past, or will use in the future, since you are not identified by the locators. Instead, you must be able to show that you are entitled to "speak for" your identifier. Thus, end-host mobility and end-host multi-homing become more similar, at least from the security point of view. --Pekka Nikander From owner-multi6@ops.ietf.org Mon Jan 6 06:48: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 GAA01571 for ; Mon, 6 Jan 2003 06:48:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18VVkB-000DIr-00 for multi6-data@psg.com; Mon, 06 Jan 2003 03:48:35 -0800 Received: from gnat.inet.org ([63.108.254.91]) by psg.com with esmtp (Exim 3.36 #2) id 18VVk9-000DHZ-00 for multi6@ops.ietf.org; Mon, 06 Jan 2003 03:48:33 -0800 Received: from extremenetworks.com (unknown [10.0.8.101]) by gnat.inet.org (Postfix) with ESMTP id 7E2A067104; Mon, 6 Jan 2003 06:52:21 -0500 (EST) Date: Mon, 6 Jan 2003 06:47:47 -0500 Subject: Re: multi-homing vs multi-connecting Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: To: Iljitsch van Beijnum From: RJ Atkinson In-Reply-To: <20030103222038.F53797-100000@sequoia.muada.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-2.6 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01, USER_AGENT_APPLEMAIL version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Friday, Jan 3, 2003, at 16:41 America/Montreal, Iljitsch van Beijnum wrote: > Multihoming makes routing more complex, as it adds more possible paths. That is true of current IPv4 multi-homing, when talking about inter-domain routing. It is NOT necessarily true for all approaches to IPv6 multi-homing. In fact, it might be preferable to select an approach that minimises the complexity increase on inter-domain routing due to multi-homing. Ran From owner-multi6@ops.ietf.org Mon Jan 6 10:59: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 KAA06041 for ; Mon, 6 Jan 2003 10:59:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18VZgK-000Kun-00 for multi6-data@psg.com; Mon, 06 Jan 2003 08:00:52 -0800 Received: from ginger.lcs.mit.edu ([18.26.0.82]) by psg.com with esmtp (Exim 3.36 #2) id 18VZgH-000KuX-00 for multi6@ops.ietf.org; Mon, 06 Jan 2003 08:00:49 -0800 Received: from ginger.lcs.mit.edu (localhost [127.0.0.1]) by ginger.lcs.mit.edu (8.12.6/8.12.6) with ESMTP id h06G0lMY021877; Mon, 6 Jan 2003 11:00:47 -0500 Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.12.6/8.12.6/Submit) id h06G0l1i021874; Mon, 6 Jan 2003 11:00:47 -0500 Date: Mon, 6 Jan 2003 11:00:47 -0500 From: "J. Noel Chiappa" Message-Id: <200301061600.h06G0l1i021874@ginger.lcs.mit.edu> To: multi6@ops.ietf.org Subject: Re: multi-homing vs multi-connecting Cc: jnc@ginger.lcs.mit.edu X-Spam-Status: No, hits=0.8 required=5.0 tests=SPAM_PHRASE_02_03 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: RJ Atkinson >> Multihoming makes routing more complex, as it adds more possible paths. > That is true of current IPv4 multi-homing, when talking about > inter-domain routing. It is NOT necessarily true for all approaches to > IPv6 multi-homing. In fact, it might be preferable to select an approach > that minimises the complexity increase on inter-domain routing due to > multi-homing. I think we probably ought to distinguish between several different kinds of "the routing is involved in this multi-homing solution". On the one extreme, there's the "this thing has only one routing-name, and the normal path-selection algorithm is always generating routes to it through currently working links" - in other words, the current IPv4 multi-homing model. But there are numerous others, e.g. Dave Clark's old "route fragments" idea (and sorry, I don't have a citation for it), where along with the destination "address", you get back a number of source route fragments, leading from "large" topology elements your local router probably does know about (e.g. major international ISP's) to the destination via various access paths to that destination. It's important to realize that, fundamentally, multi-homing (of *all* kinds) *is* just a path-selection - i.e. routing - problem. I.e. there's more than one way to get to the destination host, and somehow everyone/thing involved has to get together to i) work them out, and ii) select one. The problem is that the straightforward ways of doing this, ones that work in a small network, don't work in something the size of the Internet because the routing overhead explodes. So then you start trying to reduce the amount of work; perhaps by offloading some of the work in various ways (some of which do not look like routing). Sure, there can be other non-routing implications, e.g. if you decide that the you're going to use is multiple "addresses", then you have to deal with the "how do I tell that address A and address B refer to the same host, the I'm talking to" (provided of course that that problem is one you care about). But basically multi-homing turns into a path-selection (i.e. routing) problem. Noel From owner-multi6@ops.ietf.org Mon Jan 6 12:33: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 MAA08229 for ; Mon, 6 Jan 2003 12:33:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Vb82-000O9c-00 for multi6-data@psg.com; Mon, 06 Jan 2003 09:33:34 -0800 Received: from mail1.microsoft.com ([131.107.3.125]) by psg.com with esmtp (Exim 3.36 #2) id 18Vb7W-000O7k-00 for multi6@ops.ietf.org; Mon, 06 Jan 2003 09:33:03 -0800 Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Mon, 6 Jan 2003 09:32:30 -0800 Received: from 157.54.5.25 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 06 Jan 2003 09:32:30 -0800 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.3710.0); Mon, 6 Jan 2003 09:32:29 -0800 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); Mon, 6 Jan 2003 09:32:30 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.82]) by WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3710.0); Mon, 6 Jan 2003 09:32:29 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: multi-homing vs multi-connecting Date: Mon, 6 Jan 2003 09:32:29 -0800 Message-ID: Thread-Topic: multi-homing vs multi-connecting Thread-Index: AcK1nn3SmVlNiieRTKyNl1QF++PamAACkzZg From: "Christian Huitema" To: "J. Noel Chiappa" , X-OriginalArrivalTime: 06 Jan 2003 17:32:29.0697 (UTC) FILETIME=[96630F10:01C2B5A9] X-Spam-Status: No, hits=0.0 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_02_03 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA08229 > Sure, there can be other non-routing implications, e.g. if you decide that > the > you're going to use is multiple "addresses", then you have to deal with > the > "how do I tell that address A and address B refer to the same host, the > I'm > talking to" (provided of course that that problem is one you care about). > > But basically multi-homing turns into a path-selection (i.e. routing) > problem. Yup. The multiple addresses vs. single address decision is really an implementation choice; the multiple addresses (or locators) solution is basically a decision to move the complexity out of the routing system and into the hosts. It does not remove the need to uniquely identify the "host", if only as the closure of the equivalence relation "address A and address B lead to the same point"; it simply removes the need to have the routing system be aware of the identity relation. Arguably, it also removes the opportunity for the routing system to do smart things, but that is precisely the trade-off. Obviously, there may be multiple paths leading to each of the multiple addresses, so the decision is not strictly binary. -- Christian Huitema From owner-multi6@ops.ietf.org Tue Jan 7 04:23: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 EAA07715 for ; Tue, 7 Jan 2003 04:23:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18VpxS-000Nxy-00 for multi6-data@psg.com; Tue, 07 Jan 2003 01:23:38 -0800 Received: from tlp1.cobweb.autonomica.se ([130.244.10.138] helo=dhcp-168-17-67.autonomica.se) by psg.com with esmtp (Exim 3.36 #2) id 18Vpwx-000Nx3-00 for multi6@ops.ietf.org; Tue, 07 Jan 2003 01:23:07 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp-168-17-67.autonomica.se (8.12.2/8.10.2) with ESMTP id h079Nn5E000567; Tue, 7 Jan 2003 10:23:49 +0100 (CET) Date: Tue, 7 Jan 2003 10:23:49 +0100 Subject: Re: draft-kurtis-multihoming-longprefix comments Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: multi6@ops.ietf.org To: Pekka Savola From: Kurt Erik Lindqvist In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-2.9 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02, USER_AGENT_APPLEMAIL version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Major comments: > > 1) Seems to give wrong impression about the effectiveness of this > mechanism. I believe (I'm collecting and analyzing some data too) > that a > significant portion of multihomers do it because they want to obtain > operator independence. They usually don't have PI addresses, but what > I'd > call "PA sold off as PI" or "PA advertised as PI". (Esp 5.3) > > There must be an applicability section or statement early on what this > tries to accomplish. Well, what I am looking for is a) Any idea of why people are doing this. We are again back to the problem that we should first understand what we are trying to solve before we start posting solutions. From the discussion in Atlanta, this was just a suggestion to at least buy us some time. > > 2) If we really need to go down with longer prefixes approach, I'd > really > want to restrict hem to peerings (and even smaller upstreams) only, > _NOT_ > DMZ. Well, you could use one of the mechanisms suggested in ptomine to limit this. Best regards, - kurtis - From owner-multi6@ops.ietf.org Tue Jan 7 10:16: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 KAA17358 for ; Tue, 7 Jan 2003 10:16:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18VvVH-0006MS-00 for multi6-data@psg.com; Tue, 07 Jan 2003 07:18:55 -0800 Received: from ginger.lcs.mit.edu ([18.26.0.82]) by psg.com with esmtp (Exim 3.36 #2) id 18VvUk-0006Lw-00 for multi6@ops.ietf.org; Tue, 07 Jan 2003 07:18:22 -0800 Received: from ginger.lcs.mit.edu (localhost [127.0.0.1]) by ginger.lcs.mit.edu (8.12.6/8.12.6) with ESMTP id h07FIIMY029151; Tue, 7 Jan 2003 10:18:18 -0500 Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.12.6/8.12.6/Submit) id h07FIHqs029150; Tue, 7 Jan 2003 10:18:17 -0500 Date: Tue, 7 Jan 2003 10:18:17 -0500 From: "J. Noel Chiappa" Message-Id: <200301071518.h07FIHqs029150@ginger.lcs.mit.edu> To: multi6@ops.ietf.org Subject: Re: draft-kurtis-multihoming-longprefix comments Cc: jnc@ginger.lcs.mit.edu X-Spam-Status: No, hits=0.8 required=5.0 tests=SPAM_PHRASE_02_03 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: Kurt Erik Lindqvist >> I believe that a significant portion of multihomers do it because they >> want to obtain operator independence. They usually don't have PI >> addresses, but what I'd call "PA sold off as PI" or "PA advertised as >> PI". First, once again, about "provider-independent addresses", AKA "connectivity- independent addresses". This is pretty much like asking for a street address that stays the same even when you move. Needless to say, try that one in the real world and see how far you get with it. In any rational discussion of addressing, the phrase "provider-independent addresses" ought to receive the same reception as "location-independent street address" - i.e. something between concern (that the person needs to be institutionalized) and racous laughter (at the ludicrousness of it). Look, if you want some sort of identifier for machines, one that stays the same even when a machine moves somewhere else, the IPv4 architecture simply does not provide it. Frankly, it wasn't even guessed at as a requirement, back when the Internet had 18 total nets in it. IPv6 adopted the IPv4 architecture lock, stock, and barrel, changing only the length of the address. This is touted as its great strength - in fact, it's its greatest weakness, and we see an example here. If you don't like the fact that IPv6 does not have identifiers for machines, ones that stays the same even when a machine moves, either i) complain to the IPv6 architect(s), or ii) work with people like Ran who are trying to add one. *Don't* come ask for "location-indepedent street addresses". > Well, what I am looking for is a) Any idea of why people are doing > this. We are again back to the problem that we should first understand > what we are trying to solve before we start posting solutions. Oh, I think it's reasonably easy to understand why people want identifiers for their machines that stay the same even if they change providers. They want to make it easy (or at least easier) to change providers, and prevent lock-in. The only possible solution *in the architecture as it stands* is to use DNS names, if people need a location-independent host identifier. Another option, again, is to work with people like Ran who are trying to add such a namespace. Too bad IPv6 didn't have one from the start. Noel From owner-multi6@ops.ietf.org Tue Jan 7 12:32: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 MAA21749 for ; Tue, 7 Jan 2003 12:32:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Vxbh-000A5n-00 for multi6-data@psg.com; Tue, 07 Jan 2003 09:33:41 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 18VxbA-000A4D-00 for multi6@ops.ietf.org; Tue, 07 Jan 2003 09:33:08 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h07HWX213961; Tue, 7 Jan 2003 18:32:34 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Tue, 7 Jan 2003 18:32:33 +0100 (CET) From: Iljitsch van Beijnum To: "J. Noel Chiappa" cc: Subject: Re: draft-kurtis-multihoming-longprefix comments In-Reply-To: <200301071518.h07FIHqs029150@ginger.lcs.mit.edu> Message-ID: <20030107183001.H11497-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.6 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, 7 Jan 2003, J. Noel Chiappa wrote: > If you don't like the fact that IPv6 does not have identifiers for machines, > ones that stays the same even when a machine moves, either i) complain to the > IPv6 architect(s), or ii) work with people like Ran who are trying to add one. Do you (or Ran) have a pointer to this work? Iljitsch From owner-multi6@ops.ietf.org Tue Jan 7 14:30: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 OAA25870 for ; Tue, 7 Jan 2003 14:30:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18VzSg-000EUz-00 for multi6-data@psg.com; Tue, 07 Jan 2003 11:32:30 -0800 Received: from evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net ([4.65.20.139] helo=tndh.net) by psg.com with esmtp (Exim 3.36 #2) id 18VzRm-000EST-00 for multi6@ops.ietf.org; Tue, 07 Jan 2003 11:31:34 -0800 Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Tue, 07 Jan 2003 11:31:35 -0800 Reply-To: From: "Tony Hain" To: "'J. Noel Chiappa'" , Subject: RE: draft-kurtis-multihoming-longprefix comments Date: Tue, 7 Jan 2003 11:31:20 -0800 Message-ID: <041901c2b683$5b679040$9f144104@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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <200301071518.h07FIHqs029150@ginger.lcs.mit.edu> X-Spam-Status: No, hits=-1.1 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA25870 J. Noel Chiappa wrote: > > From: Kurt Erik Lindqvist > > >> I believe that a significant portion of multihomers do > it because they > >> want to obtain operator independence. They usually > don't have PI > >> addresses, but what I'd call "PA sold off as PI" or > "PA advertised as > >> PI". > > First, once again, about "provider-independent addresses", > AKA "connectivity- independent addresses". > > This is pretty much like asking for a street address that > stays the same even when you move. No, it is asking for the same address to work when USPS, UPS, FedEx, the pizza guy ... service providers deliver the packets. Mixing the concept of service provider and connectivity is what makes it so hard for the average network manager to understand why his address has to change when he changes providers. In 'the real world' the connectivity (street) is separated from the service provider. > > Needless to say, try that one in the real world and see how > far you get with it. The phone system allows this (for a price), so people expect it to be possible from the 'more powerful' Internet. > > In any rational discussion of addressing, the phrase > "provider-independent addresses" ought to receive the same > reception as "location-independent street address" - i.e. > something between concern (that the person needs to be > institutionalized) and racous laughter (at the ludicrousness of it). Only by routing gurus. The average network manager looks at 'the real world' where a large number of services are available using a common street address, and the anomaly of portable numbers in the phone system, and can't figure out why the Internet is not even capable of those simple things. > > > Look, if you want some sort of identifier for machines, one > that stays the same even when a machine moves somewhere else, > the IPv4 architecture simply does not provide it. Frankly, it > wasn't even guessed at as a requirement, back when the > Internet had 18 total nets in it. > > IPv6 adopted the IPv4 architecture lock, stock, and barrel, > changing only the length of the address. This is touted as > its great strength - in fact, it's its greatest weakness, and > we see an example here. The strength is that it is a model that people understand. Where it breaks down is that the decision leading to PA-only occurred at the same time as CIDR. The zeal to clean up & prevent a new swamp resulted in a system where the multi-homing issues were pushed to the host (ie: out of the DFZ routing space). Now that end site network managers are getting a voice, they are pushing back and stating they don't want it in the host. > > If you don't like the fact that IPv6 does not have > identifiers for machines, ones that stays the same even when > a machine moves, either i) complain to the IPv6 architect(s), > or ii) work with people like Ran who are trying to add one. > > *Don't* come ask for "location-indepedent street addresses". People aren't asking for location-independent addresses, in fact they are asking for the architectural equivalent of a street address. > > > > Well, what I am looking for is a) Any idea of why > people are doing > > this. We are again back to the problem that we should > first understand > > what we are trying to solve before we start posting solutions. > > Oh, I think it's reasonably easy to understand why people > want identifiers for their machines that stay the same even > if they change providers. They want to make it easy (or at > least easier) to change providers, and prevent lock-in. > > The only possible solution *in the architecture as it stands* > is to use DNS names, if people need a location-independent > host identifier. > > Another option, again, is to work with people like Ran who > are trying to add such a namespace. There are also as set of us who are trying to define an intermediate approach that scales within the constraints of the current routing technology while we wait for the longer term additional namespace. Tony > > Too bad IPv6 didn't have one from the start. > > Noel > From owner-multi6@ops.ietf.org Tue Jan 7 14:43: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 OAA26128 for ; Tue, 7 Jan 2003 14:43:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18VzgY-000F6D-00 for multi6-data@psg.com; Tue, 07 Jan 2003 11:46:50 -0800 Received: from [65.174.124.37] (helo=dmz2.procket.com) by psg.com with esmtp (Exim 3.36 #2) id 18Vzg2-000F3r-00 for multi6@ops.ietf.org; Tue, 07 Jan 2003 11:46:18 -0800 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id 1ED753443F; Tue, 7 Jan 2003 11:56:22 -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 h07Jjjie011633; Tue, 7 Jan 2003 11:45:45 -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="iso-8859-1" Subject: RE: draft-kurtis-multihoming-longprefix comments Date: Tue, 7 Jan 2003 11:45:44 -0800 Message-ID: Thread-Topic: draft-kurtis-multihoming-longprefix comments Thread-Index: AcK2hKjmXxbD098cT9uxSbZHNMWsEAAAKTiQ From: "Tony Li" To: , "J. Noel Chiappa" , X-Spam-Status: No, hits=0.8 required=5.0 tests=SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA26128 | > Needless to say, try that one in the real world and see how | > far you get with it. | | The phone system allows this (for a price), so people | expect it to be | possible from the 'more powerful' Internet. Fine. Let's start charging for prefixes. Tony From owner-multi6@ops.ietf.org Tue Jan 7 14:46: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 OAA26159 for ; Tue, 7 Jan 2003 14:46:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Vzir-000FCR-00 for multi6-data@psg.com; Tue, 07 Jan 2003 11:49:13 -0800 Received: from [65.174.124.37] (helo=dmz2.procket.com) by psg.com with esmtp (Exim 3.36 #2) id 18VziL-000F9m-00 for multi6@ops.ietf.org; Tue, 07 Jan 2003 11:48:41 -0800 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id F09763443E; Tue, 7 Jan 2003 11:58:48 -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 h07JmAie011738; Tue, 7 Jan 2003 11:48:10 -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="iso-8859-1" Subject: RE: draft-kurtis-multihoming-longprefix comments Date: Tue, 7 Jan 2003 11:48:10 -0800 Message-ID: Thread-Topic: draft-kurtis-multihoming-longprefix comments Thread-Index: AcK2hKjmXxbD098cT9uxSbZHNMWsEAAAODeg From: "Tony Li" To: , "J. Noel Chiappa" , X-Spam-Status: No, hits=0.5 required=5.0 tests=SPAM_PHRASE_01_02 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA26159 | > Another option, again, is to work with people like Ran who | > are trying to add such a namespace. | | There are also as set of us who are trying to define an intermediate | approach that scales within the constraints of the current routing | technology while we wait for the longer term additional namespace. The current routing technology does NOT scale properly. There is not going to be any intermeidate approach based on the current technology that will scale. Tony From owner-multi6@ops.ietf.org Tue Jan 7 15:59: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 PAA28596 for ; Tue, 7 Jan 2003 15:59:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18W0r1-000IJ8-00 for multi6-data@psg.com; Tue, 07 Jan 2003 13:01:43 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 18W0qV-000IGy-00 for multi6@ops.ietf.org; Tue, 07 Jan 2003 13:01:12 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h07L0bS14219; Tue, 7 Jan 2003 22:00:41 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Tue, 7 Jan 2003 22:00:37 +0100 (CET) From: Iljitsch van Beijnum To: Tony Li cc: Subject: RE: draft-kurtis-multihoming-longprefix comments In-Reply-To: Message-ID: <20030107213525.D11497-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.7 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_01_02 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, 7 Jan 2003, Tony Li wrote: > The current routing technology does NOT scale properly. There is not > going to be any intermeidate approach based on the current technology > that will scale. Now I have to go and disagree with you there. With a reasonable level of aggregation current technology will scale just fine. Aggregation is simply a means to divide the routing information over the routers so that a single router doesn't have to hold all possible routes. Today, if routers are owned by the same owner, they hold the same routing information. Maybe it's time we try aggregating based on something else than router ownership. From owner-multi6@ops.ietf.org Tue Jan 7 16:30: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 QAA29383 for ; Tue, 7 Jan 2003 16:30:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18W1LS-000Jf1-00 for multi6-data@psg.com; Tue, 07 Jan 2003 13:33:10 -0800 Received: from ginger.lcs.mit.edu ([18.26.0.82]) by psg.com with esmtp (Exim 3.36 #2) id 18W1Kw-000Jcb-00 for multi6@ops.ietf.org; Tue, 07 Jan 2003 13:32:38 -0800 Received: from ginger.lcs.mit.edu (localhost [127.0.0.1]) by ginger.lcs.mit.edu (8.12.6/8.12.6) with ESMTP id h07LWZMY001640; Tue, 7 Jan 2003 16:32:35 -0500 Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.12.6/8.12.6/Submit) id h07LWYr3001639; Tue, 7 Jan 2003 16:32:34 -0500 Date: Tue, 7 Jan 2003 16:32:34 -0500 From: "J. Noel Chiappa" Message-Id: <200301072132.h07LWYr3001639@ginger.lcs.mit.edu> To: multi6@ops.ietf.org Subject: RE: draft-kurtis-multihoming-longprefix comments Cc: jnc@ginger.lcs.mit.edu X-Spam-Status: No, hits=0.8 required=5.0 tests=SPAM_PHRASE_02_03 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: "Tony Hain" >> about "provider-independent addresses", AKA "connectivity- independent >> addresses". >> This is pretty much like asking for a street address that stays the >> same even when you move. > No, it is asking for the same address to work when USPS, UPS, FedEx, the > pizza guy ... service providers deliver the packets. No, it's *not*, Tony - which is not to say your point above (modulo the pizza guy, who's an application, not a service) is not also true. Why you are having such a hard time with this seemingly simple concept is really starting to frustrate me (which I concede tends to make me awfully cranky), but let's try it again. When some host stops buying service from provider X and starts buying it from provider Y, you wind up running a wire from that computer to *different place* on the network - to the infrastructure of provider Y. **That host has, from the point of view of the rest of the network, moved to a new location on the network**. > Mixing the concept of service provider and connectivity is what makes it > so hard for the average network manager to understand why his address > has to change when he changes providers. It's precisely because the service provider *provides the connectivity* that the address has to change. That's the *service* they are providing - the connectivity. > In 'the real world' the connectivity (street) is separated from the > service provider. The *street* is the connectivity service - and moreover, it's one that all "resellers" (UPS, UPS, FedEx) are allowed to use *for free*. So your analogy breaks down here. You have a slightly better case for this analogy in what's happening on some cable TV systems, where you can sign up with one of multiple providers, but you keep the same cable TV hookup. Still, even in these cases, when you switch providers, from the point of view of the rest of the network you're moved somewhere else (in that you're "attached" to provider Y, not provider X as before), which is why your address has to change. We don't have any way to assign that cable TV network a single address, *and* ensure that incoming traffic to host Q goes over the network that host Q is paying money to. > The phone system allows this (for a price), so people expect it to be > possible from the 'more powerful' Internet. The way the phone system did this is they jacked up the phone system naming layers by one, and slid a new one in underneath, one which is your real "physical" phone number (I don't know the actual jargon terms the phone guys use here), and the number you give everyone is now (effectively) a "virtual" phone number. Then they maintain a big mapping database which converts from virtual phone numbers to actual phone numbers. To do the equivalent in the Internet, we'd have to allow people to emit packets with a "virtual" address in them (let's call them Effective Internet Demultiplexors, or EID's, for short), and then some router would have to do the mapping and stick on the actual address. I have in the distant past proposed doing exactly that, but people didn't like the idea. >> In any rational discussion of addressing, the phrase >> "provider-independent addresses" ought to receive the same reception as >> "location-independent street address" - i.e. something between concern >> (that the person needs to be institutionalized) and racous laughter (at >> the ludicrousness of it). > Only by routing gurus. Look, the routing gurus *aren't* the people who designed a new network architecture and put in only a single namespace. If you're pissed off, go beat up the internetwork level architects. > The average network manager looks at 'the real world' where a large > number of services are available using a common street address, and the > anomaly of portable numbers in the phone system, and can't figure out > why the Internet is not even capable of those simple things. If you persist in thinking that a tree sloth is a fish, you will of course be upset that it doesn't have scales and fins. >> IPv6 adopted the IPv4 architecture lock, stock, and barrel, changing >> only the length of the address. This is touted as its great strength - >> in fact, it's its greatest weakness, and we see an example here. > The strength is that it is a model that people understand. The model that everyone should give me a Ferrari is simple and easy to understand. That doesn't mean it's either useful or workable. > Where it breaks down is that the decision leading to PA-only occurred at > the same time as CIDR. Yes, and gravity and mass have no connection either. > a system where the multi-homing issues were pushed to the host (ie: out > of the DFZ routing space). Now that end site network managers are > getting a voice, they are pushing back and stating they don't want it in > the host. Yeah, and no doubt car owners want cars that run an infinite distance on no gas, too. I sure wouldn't mind one. >> *Don't* come ask for "location-indepedent street addresses". > People aren't asking for location-independent addresses, in fact they > are asking for the architectural equivalent of a street address. Words fail me. Noel From owner-multi6@ops.ietf.org Tue Jan 7 16:36: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 QAA29538 for ; Tue, 7 Jan 2003 16:36:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18W1RL-000Jve-00 for multi6-data@psg.com; Tue, 07 Jan 2003 13:39:15 -0800 Received: from ginger.lcs.mit.edu ([18.26.0.82]) by psg.com with esmtp (Exim 3.36 #2) id 18W1QJ-000Jsb-00 for multi6@ops.ietf.org; Tue, 07 Jan 2003 13:38:11 -0800 Received: from ginger.lcs.mit.edu (localhost [127.0.0.1]) by ginger.lcs.mit.edu (8.12.6/8.12.6) with ESMTP id h07Lc8MY001669; Tue, 7 Jan 2003 16:38:08 -0500 Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.12.6/8.12.6/Submit) id h07Lc80H001668; Tue, 7 Jan 2003 16:38:08 -0500 Date: Tue, 7 Jan 2003 16:38:08 -0500 From: "J. Noel Chiappa" Message-Id: <200301072138.h07Lc80H001668@ginger.lcs.mit.edu> To: multi6@ops.ietf.org Subject: RE: draft-kurtis-multihoming-longprefix comments Cc: jnc@ginger.lcs.mit.edu X-Spam-Status: No, hits=0.8 required=5.0 tests=SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: Iljitsch van Beijnum >> The current routing technology does NOT scale properly. There is not >> going to be any intermeidate approach based on the current technology >> that will scale. > With a reasonable level of aggregation current technology will scale > just fine. I think Tony's talking about routing protocols, not hardware. In any case, I too will disagree with Tony, and say that no possible routing technology can scale as well as some people would like it to. :-) > Today, if routers are owned by the same owner, they hold the same > routing information. Maybe it's time we try aggregating based on > something else than router ownership. Reading this, I literally had to cringe and hold my head in my hands. The *only* way to aggregate *which is useful to the routing* is based on *actual connectivity* - i.e. the actual ability send packets. Ownership of box X and box Y is basically irrelevent (although policty routing may use it for *additional* constraints), from the routing's point of view. If box X and box Y are connected by a wire - now, that's different. Noel From owner-multi6@ops.ietf.org Tue Jan 7 16:39: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 QAA29619 for ; Tue, 7 Jan 2003 16:39:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18W1UT-000K5D-00 for multi6-data@psg.com; Tue, 07 Jan 2003 13:42:29 -0800 Received: from [65.174.124.36] (helo=dmz1.procket.com) by psg.com with esmtp (Exim 3.36 #2) id 18W1Ty-000K2L-00 for multi6@ops.ietf.org; Tue, 07 Jan 2003 13:41:58 -0800 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id C171823C4E; Tue, 7 Jan 2003 13:32:14 -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 h07LfPie015396; Tue, 7 Jan 2003 13:41:25 -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="iso-8859-1" Subject: RE: draft-kurtis-multihoming-longprefix comments Date: Tue, 7 Jan 2003 13:41:25 -0800 Message-ID: Thread-Topic: draft-kurtis-multihoming-longprefix comments Thread-Index: AcK2j8GcfJxPSoJRSSS+RdonyE4usgABX4rQ From: "Tony Li" To: "Iljitsch van Beijnum" Cc: X-Spam-Status: No, hits=0.5 required=5.0 tests=SPAM_PHRASE_01_02 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA29619 | > The current routing technology does NOT scale properly. | There is not | > going to be any intermeidate approach based on the | current technology | > that will scale. | | Now I have to go and disagree with you there. | | With a reasonable level of aggregation current technology will scale | just fine. | | Aggregation is simply a means to divide the routing | information over the | routers so that a single router doesn't have to hold all possible | routes. Today, if routers are owned by the same owner, they hold the | same routing information. Maybe it's time we try | aggregating based on | something else than router ownership. The current architecture has no incentive for end user sites to want to be aggregated and without that, the architecture is bound to fail. Right now, we have two large incentives not to aggregate: multihoming and more-specifics for traffc engineering. We need to change something, moving forward. Tony From owner-multi6@ops.ietf.org Tue Jan 7 17:24: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 RAA01282 for ; Tue, 7 Jan 2003 17:24:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18W2Bt-000MBo-00 for multi6-data@psg.com; Tue, 07 Jan 2003 14:27:21 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 18W2BN-000MBC-00 for multi6@ops.ietf.org; Tue, 07 Jan 2003 14:26:49 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h07MQJq14363; Tue, 7 Jan 2003 23:26:20 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Tue, 7 Jan 2003 23:26:19 +0100 (CET) From: Iljitsch van Beijnum To: "J. Noel Chiappa" cc: Subject: RE: draft-kurtis-multihoming-longprefix comments In-Reply-To: <200301072138.h07Lc80H001668@ginger.lcs.mit.edu> Message-ID: <20030107230051.W11497-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.4 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, 7 Jan 2003, J. Noel Chiappa wrote: > > Today, if routers are owned by the same owner, they hold the same > > routing information. Maybe it's time we try aggregating based on > > something else than router ownership. > Reading this, I literally had to cringe and hold my head in my hands. :-) > The *only* way to aggregate *which is useful to the routing* is based on > *actual connectivity* - i.e. the actual ability send packets. Ownership of box > X and box Y is basically irrelevent (although policty routing may use it for > *additional* constraints), from the routing's point of view. If box X and box > Y are connected by a wire - now, that's different. Suppose ASes 1, 2, 3 and 4 are all present with one router in Chicago, NYC, Dallas and LA and they all interconnect there. Each router has 100 customer routes. So you can aggregate and have 400 internal and 3 external routes in each AS. Or you can do geo aggregation as per my draft and have 400 LA routes regardless of which ISP each route belongs to in LA, 400 Chicago routes in Chicago and so on and 3 pilot routes to other locations. So it's exactly the same thing, only in this case you can aggregate multihomers. Now obviously in the real world interconnection between regions within an ISP network is denser than between ISP networks within regions, but regional interconnection is still dense enough to make it worth the trouble. But in the mean time I'm working on a multiple address draft which is of course much cooler but upgrading all hosts in the world also has its problems... Iljitsch From owner-multi6@ops.ietf.org Tue Jan 7 17:58: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 RAA02099 for ; Tue, 7 Jan 2003 17:58:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18W2iy-000NsD-00 for multi6-data@psg.com; Tue, 07 Jan 2003 15:01:32 -0800 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 18W2iS-000Nra-00 for multi6@ops.ietf.org; Tue, 07 Jan 2003 15:01:00 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h07N0no28850; Wed, 8 Jan 2003 01:00:49 +0200 Date: Wed, 8 Jan 2003 01:00:48 +0200 (EET) From: Pekka Savola To: Iljitsch van Beijnum cc: "J. Noel Chiappa" , Subject: RE: draft-kurtis-multihoming-longprefix comments In-Reply-To: <20030107230051.W11497-100000@sequoia.muada.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, 7 Jan 2003, Iljitsch van Beijnum wrote: > > The *only* way to aggregate *which is useful to the routing* is based on > > *actual connectivity* - i.e. the actual ability send packets. Ownership of box > > X and box Y is basically irrelevent (although policty routing may use it for > > *additional* constraints), from the routing's point of view. If box X and box > > Y are connected by a wire - now, that's different. > > Suppose ASes 1, 2, 3 and 4 are all present with one router in Chicago, > NYC, Dallas and LA and they all interconnect there. Each router has 100 > customer routes. So you can aggregate and have 400 internal and 3 > external routes in each AS. [...] Is this for real? If you can assume some sane address plan which provides aggregation, each AS would have about 7 routes in each router plus 100 local routes in each. There is idea use passing the customer routes even in internal routing if you can aggregate. Ideally these kind of static routes are just a problem of a single aggregation device. Just to be sure we're not comparing apples to oranges.. -- 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 Jan 7 18:09: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 SAA02423 for ; Tue, 7 Jan 2003 18:09:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18W2tw-000OSd-00 for multi6-data@psg.com; Tue, 07 Jan 2003 15:12:52 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 18W2tQ-000OPJ-00 for multi6@ops.ietf.org; Tue, 07 Jan 2003 15:12:20 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h07NBkD14426; Wed, 8 Jan 2003 00:11:46 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Wed, 8 Jan 2003 00:11:46 +0100 (CET) From: Iljitsch van Beijnum To: Pekka Savola cc: Subject: RE: draft-kurtis-multihoming-longprefix comments In-Reply-To: Message-ID: <20030108000730.M11497-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.4 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 8 Jan 2003, Pekka Savola wrote: > > Each router has 100 > > customer routes. So you can aggregate and have 400 internal and 3 > > external routes in each AS. [...] > If you can assume some sane address plan which provides aggregation, each > AS would have about 7 routes in each router plus 100 local routes in each. In IPv4 that's not going to happen as it wastes too much address space. I'm not sure how strict the RIRs are with IPv6 space, but it looks to me they are still in the process of wrapping their minds around 128 bits. (Think about it: 64 bits is enough to give every square millimeter of earth surface an address.) From owner-multi6@ops.ietf.org Tue Jan 7 18:23: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 SAA03061 for ; Tue, 7 Jan 2003 18:23:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18W36x-000PAI-00 for multi6-data@psg.com; Tue, 07 Jan 2003 15:26:19 -0800 Received: from [65.174.124.36] (helo=dmz1.procket.com) by psg.com with esmtp (Exim 3.36 #2) id 18W36S-000P7M-00 for multi6@ops.ietf.org; Tue, 07 Jan 2003 15:25:48 -0800 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id 7688F23C4F; Tue, 7 Jan 2003 15:16:06 -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 h07NPHie022653; Tue, 7 Jan 2003 15:25:17 -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="iso-8859-1" Subject: RE: draft-kurtis-multihoming-longprefix comments Date: Tue, 7 Jan 2003 15:25:17 -0800 Message-ID: Thread-Topic: draft-kurtis-multihoming-longprefix comments Thread-Index: AcK2lhzqFqxL9WspTk6Tk8vMTHCc0wADYJXw From: "Tony Li" To: "J. Noel Chiappa" , X-Spam-Status: No, hits=0.8 required=5.0 tests=SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA03061 | I think Tony's talking about routing protocols, not hardware. I always worry about both. They are just different resources for the exact same problem. | In any case, I too will disagree with Tony, and say that no | possible routing | technology can scale as well as some people would like it to. :-) True, however, I have since lowered my standard: anything that will remain lower than Moore's law would be fine with me. If folks are not willing to compromise to this standard, I'm happy to discuss other alternatives as long as they come with an implementation strategy. Tony From owner-multi6@ops.ietf.org Tue Jan 7 18:25: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 SAA03151 for ; Tue, 7 Jan 2003 18:25:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18W395-000PFj-00 for multi6-data@psg.com; Tue, 07 Jan 2003 15:28:31 -0800 Received: from [65.174.124.37] (helo=dmz2.procket.com) by psg.com with esmtp (Exim 3.36 #2) id 18W38Z-000PDR-00 for multi6@ops.ietf.org; Tue, 07 Jan 2003 15:27:59 -0800 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id D3F163443E; Tue, 7 Jan 2003 15:38:06 -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 h07NRSie022708; Tue, 7 Jan 2003 15:27:28 -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="iso-8859-1" Subject: RE: draft-kurtis-multihoming-longprefix comments Date: Tue, 7 Jan 2003 15:27:28 -0800 Message-ID: Thread-Topic: draft-kurtis-multihoming-longprefix comments Thread-Index: AcK2nOljnoqa3+uxQ7CyHQg58OZNwQAByOAA From: "Tony Li" To: "Iljitsch van Beijnum" , "J. Noel Chiappa" Cc: X-Spam-Status: No, hits=0.8 required=5.0 tests=SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA03151 | Now obviously in the real world interconnection between | regions within | an ISP network is denser than between ISP networks within | regions, but | regional interconnection is still dense enough to make it worth the | trouble. Only if there is existing regional interconnectivity. If there is, then this is a form of topological aggregation (good). If not, then one is either forced to deaggregate (bad), force a regional interconnect (worse), or force mutual free regional transit (worst). Tony From owner-multi6@ops.ietf.org Tue Jan 7 19:32: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 TAA05346 for ; Tue, 7 Jan 2003 19:32:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18W4Av-0002pk-00 for multi6-data@psg.com; Tue, 07 Jan 2003 16:34:29 -0800 Received: from evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net ([4.65.20.139] helo=tndh.net) by psg.com with esmtp (Exim 3.36 #2) id 18W4AP-0002p0-00 for multi6@ops.ietf.org; Tue, 07 Jan 2003 16:33:57 -0800 Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Tue, 07 Jan 2003 16:33:58 -0800 Reply-To: From: "Tony Hain" To: "'J. Noel Chiappa'" , Subject: RE: draft-kurtis-multihoming-longprefix comments Date: Tue, 7 Jan 2003 16:33:35 -0800 Message-ID: <044101c2b6ad$94d61250$9f144104@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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <200301072132.h07LWYr3001639@ginger.lcs.mit.edu> X-Spam-Status: No, hits=-1.1 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA05346 J. Noel Chiappa wrote: > > No, it is asking for the same address to work when > USPS, UPS, FedEx, the > > pizza guy ... service providers deliver the packets. > > No, it's *not*, Tony - which is not to say your point above > (modulo the pizza guy, who's an application, not a service) I consider the packets delivered by the pizza guy to be a more valuable service than what usually comes from the other delivery guys ... ;) > is not also true. > > Why you are having such a hard time with this seemingly > simple concept is really starting to frustrate me (which I > concede tends to make me awfully cranky), but let's try it again. > > When some host stops buying service from provider X and > starts buying it from provider Y, you wind up running a wire This is where the analogy breaks down ... I had though more about it after sending the earlier note, and realized this would come up. The copper/fiber doesn't change from the site perspective. More below: > from that computer to *different place* on the network - to > the infrastructure of provider Y. **That host has, from the > point of view of the rest of the network, moved to a new > location on the network**. > The street analogy would express this as the choice of direction at the stop sign (end of the consistent copper/fiber loop). Using the different attachment point as a different address model, I would have a different service address when turning left, than turning right or going straight. While I might give different instructions to those coming toward me from each of those directions, the actual address doesn't change. > > > Mixing the concept of service provider and connectivity > is what makes it > > so hard for the average network manager to understand > why his address > > has to change when he changes providers. > > It's precisely because the service provider *provides the > connectivity* that the address has to change. That's the > *service* they are providing - the connectivity. In some cases, but in many the physical plant (street) comes from a different provider. > > > In 'the real world' the connectivity (street) is > separated from the > > service provider. > > The *street* is the connectivity service - and moreover, it's > one that all "resellers" (UPS, UPS, FedEx) are allowed to use > *for free*. So your analogy breaks down here. No, it is not *free*, they pay indirectly through fuel & business taxes. In the case of the copper/fiber, service providers generally pay for exclusive use. > > You have a slightly better case for this analogy in what's > happening on some cable TV systems, where you can sign up > with one of multiple providers, but you keep the same cable > TV hookup. Still, even in these cases, when you switch > providers, from the point of view of the rest of the network > you're moved somewhere else (in that you're "attached" to > provider Y, not provider X as before), which is why your > address has to change. I know why we make people change today, but that does not make it a requirement. If the cable system had a decent L2 and allowed simultanious connection to X, Y, & Z, we would get back to the analogy of a different address depending on the direction. The forced address change approach simplifies routing by moving the complexity to the endpoints. > > We don't have any way to assign that cable TV network a > single address, *and* ensure that incoming traffic to host Q > goes over the network that host Q is paying money to. Why do we care which path the packet takes? The simple answer is we don't have the mechanisms necessary to deal with real-time accounting. In a business model where the L2 provider collected from the endpoint and paid L3's based on volume, the routing system wouldn't need to ensure traffic followed a particular path. Which is easier, building a routing system that scales to several billion entries, or silicon that is good at counting? Another way to approach it would be, sender pays whoever the packets are handed to. This idea that we can remotely align the senders handling of the packet with the receivers policy (expressed through payment) is seriously broken. In the physical package world, they figured this out and charges are aligned with the holder of the package. We don't do this in the virtual world because there is no simple scheme for the originators to recover costs from the consumers of the content. Maybe we are solving the hard routing problem because it is more interesting... > > > > The phone system allows this (for a price), so people > expect it to be > > possible from the 'more powerful' Internet. > > The way the phone system did this is they jacked up the phone > system naming layers by one, and slid a new one in > underneath, one which is your real "physical" phone number (I > don't know the actual jargon terms the phone guys use here), > and the number you give everyone is now (effectively) a > "virtual" phone number. I understand how they did it (my desk phone has a Bellevue & San Jose number), the point was that is the type of service Joe Sixpack expects, yet it doesn't scale in the routing system. > > Then they maintain a big mapping database which converts from > virtual phone numbers to actual phone numbers. > > To do the equivalent in the Internet, we'd have to allow > people to emit packets with a "virtual" address in them > (let's call them Effective Internet Demultiplexors, or EID's, > for short), and then some router would have to do the mapping > and stick on the actual address. > > I have in the distant past proposed doing exactly that, but > people didn't like the idea. In an abstract sense, 8+8 (maybe 16+16) does the same thing. > > > >> In any rational discussion of addressing, the phrase > >> "provider-independent addresses" ought to receive the > same reception as > >> "location-independent street address" - i.e. > something between concern > >> (that the person needs to be institutionalized) and > racous laughter (at > >> the ludicrousness of it). > > > Only by routing gurus. > > Look, the routing gurus *aren't* the people who designed a > new network architecture and put in only a single namespace. > If you're pissed off, go beat up the internetwork level architects. I am not picking on anyone, just trying to point out that the average network manager doesn't really have a clue how complex this is, and wouldn't laugh at the concept of addresses that are consistent across provider changes. > > > The average network manager looks at 'the real world' > where a large > > number of services are available using a common street > address, and the > > anomaly of portable numbers in the phone system, and > can't figure out > > why the Internet is not even capable of those simple things. > > If you persist in thinking that a tree sloth is a fish, you > will of course be upset that it doesn't have scales and fins. True, but when all you care is that whichever it is gets delivered to the right street address as food, the only problem might be needing to choose a different wine. > > > >> IPv6 adopted the IPv4 architecture lock, stock, and > barrel, changing > >> only the length of the address. This is touted as its > great strength - > >> in fact, it's its greatest weakness, and we see an > example here. > > > The strength is that it is a model that people understand. > > The model that everyone should give me a Ferrari is simple > and easy to understand. That doesn't mean it's either useful > or workable. > > > Where it breaks down is that the decision leading to > PA-only occurred at > > the same time as CIDR. > > Yes, and gravity and mass have no connection either. > > > a system where the multi-homing issues were pushed to > the host (ie: out > > of the DFZ routing space). Now that end site network > managers are > > getting a voice, they are pushing back and stating they > don't want it in > > the host. > > Yeah, and no doubt car owners want cars that run an infinite > distance on no gas, too. I sure wouldn't mind one. Clearly it would have to be a Ferrari :) The point is we did not solve the problem, we just moved it. > > > >> *Don't* come ask for "location-indepedent street addresses". > > > People aren't asking for location-independent > addresses, in fact they > > are asking for the architectural equivalent of a street address. > > Words fail me. I understand, but don't give up. You are looking at this from the perspective of exclusivity in the attachment point, so it makes sense that differences in attachment might lead to differences in addressing. If you remove the exclusivity restriction, it doesn't make as much sense for the address to change depending on which delivery guy is coming down the street. Sure it may be simpler to tell coorespondents to send to FedEx customer 123, and led FedEx figure it out, but if the coorespondent has a good deal from Joe's Delivery, Joe's will dump it at the closest FedEx box. If the address were independent of delivery and the remote routing mechanism only dealt with cities, Joe's would have to bring it to Seattle to figure out what to do with it. Tony > > Noel > From owner-multi6@ops.ietf.org Tue Jan 7 20:27: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 UAA07432 for ; Tue, 7 Jan 2003 20:27:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18W53J-0005nR-00 for multi6-data@psg.com; Tue, 07 Jan 2003 17:30:41 -0800 Received: from [65.174.124.36] (helo=dmz1.procket.com) by psg.com with esmtp (Exim 3.36 #2) id 18W52G-0005iW-00 for multi6@ops.ietf.org; Tue, 07 Jan 2003 17:29:36 -0800 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id 9B12723C24; Tue, 7 Jan 2003 17:19:15 -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 h081Smig026226; Tue, 7 Jan 2003 17:28:57 -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="iso-8859-1" Subject: RE: draft-kurtis-multihoming-longprefix comments Date: Tue, 7 Jan 2003 17:28:53 -0800 Message-ID: Thread-Topic: draft-kurtis-multihoming-longprefix comments Thread-Index: AcK2rtyMQRGks4UpTeOpyum7uI2o7wABKvrg From: "Tony Li" To: , "J. Noel Chiappa" , X-Spam-Status: No, hits=0.5 required=5.0 tests=SPAM_PHRASE_01_02 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id UAA07432 | The | forced address | change approach simplifies routing by moving the complexity to the | endpoints. You say that like it's a bad thing. Please remember that in the world where every home has a different provider all using their unchangeable addresses, we end up with host routing. And we're NOT going there. Ya know, geographic addressing works because three space forces you into geographic connectivity. If there was a rift in three space as often as there is in cyberville, we wouldn't be doing geographic addressing there either. You just couldn't get there from here. | Which is easier, | building a | routing system that scales to several billion entries, or | silicon that | is good at counting? Anything that scales to several billion anythings is currently not in the reach of silicon. They are the same: both intractable. | I understand how they did it (my desk phone has a Bellevue | & San Jose | number), the point was that is the type of service Joe | Sixpack expects, | yet it doesn't scale in the routing system. If you understand that it doesn't scale, then why are you advocating it? | > To do the equivalent in the Internet, we'd have to allow | > people to emit packets with a "virtual" address in them | > (let's call them Effective Internet Demultiplexors, or EID's, | > for short), and then some router would have to do the mapping | > and stick on the actual address. | > | > I have in the distant past proposed doing exactly that, but | > people didn't like the idea. | | In an abstract sense, 8+8 (maybe 16+16) does the same thing. Yes, they both do. People still don't like 'em cause they're "not the IP way." | I am not picking on anyone, just trying to point out that | the average | network manager doesn't really have a clue how complex this is, and | wouldn't laugh at the concept of addresses that are | consistent across | provider changes. We are first trying to achieve consensus amongst those who should know a sensible architecture. If we can say "here's how it will be" then selling Joe sixpack on it is much easier. If we continue having to have this same discussion with you for another decade, we will not move one iota from where we are today. | The point is we did not solve the problem, we just moved it. We have no choice but to move it. Multihoming cannot be solved soley by routing without architectural change in a scalable manner. | If the address were independent of | delivery and | the remote routing mechanism only dealt with cities, Joe's | would have to | bring it to Seattle to figure out what to do with it. And that would be a fine abstraction if that had anything to do with reality. Unfortunately, geographic addressing has about as much to do with topological connectivity as common last names have to do with street addresses. Tony From owner-multi6@ops.ietf.org Tue Jan 7 21:14: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 VAA08934 for ; Tue, 7 Jan 2003 21:14:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18W5k4-0008I5-00 for multi6-data@psg.com; Tue, 07 Jan 2003 18:14:52 -0800 Received: from evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net ([4.65.20.139] helo=tndh.net) by psg.com with esmtp (Exim 3.36 #2) id 18W5jI-0008HU-00 for multi6@ops.ietf.org; Tue, 07 Jan 2003 18:14:04 -0800 Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Tue, 07 Jan 2003 18:14:01 -0800 Reply-To: From: "Tony Hain" To: "'Tony Li'" , "'J. Noel Chiappa'" , Subject: RE: draft-kurtis-multihoming-longprefix comments Date: Tue, 7 Jan 2003 18:13:38 -0800 Message-ID: <044c01c2b6bb$8ed09890$9f144104@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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: X-Spam-Status: No, hits=-1.1 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id VAA08934 Tony Li wrote: > | The > | forced address > | change approach simplifies routing by moving the complexity to the > | endpoints. > > > You say that like it's a bad thing. Not intentionally. It was just a statement that the complexity has been moved, not removed. > ... > | I understand how they did it (my desk phone has a Bellevue > | & San Jose > | number), the point was that is the type of service Joe > | Sixpack expects, > | yet it doesn't scale in the routing system. > > > If you understand that it doesn't scale, then why are you advocating > it? I bring it up because it is not significantly different than other mapping schemes that have been proposed. We know it doesn't scale, and it is only done once at call setup rather than per packet. > ... > Yes, they both do. People still don't like 'em cause they're > "not the IP way." If by 'IP way' you mean that it is a change to the expectations apps have of the underlying architecture, then I have to agree. It is not clear to me that 16+16 is visible to apps, so maybe that doesn't apply. > ... > We are first trying to achieve consensus amongst those who should > know a sensible architecture. If we can say "here's how it will be" > then selling Joe sixpack on it is much easier. If we continue > having to have this same discussion with you for another decade, > we will not move one iota from where we are today. You seem to think I am being obstructionist. I am not. > > > | The point is we did not solve the problem, we just moved it. > > > We have no choice but to move it. Multihoming cannot be solved > soley by routing without architectural change in a scalable manner. > > > | If the address were independent of > | delivery and > | the remote routing mechanism only dealt with cities, Joe's > | would have to > | bring it to Seattle to figure out what to do with it. > > > And that would be a fine abstraction if that had anything to > do with reality. Unfortunately, geographic addressing has > about as much to do with topological connectivity as common > last names have to do with street addresses. And when I am in Japan connecting to home, topological detail of Seattle has absolutely nothing to do with which service provider I hand packets to. The fact the destination is Seattle rather than San Francisco might have something to do with a trans-pacific cable choice, but the cable & dsl providers are present in both so PA doesn't really help with TE there. Once the radius is reduced to 1000km, the number of possibilities increases dramatically, but outside that range there are really very few choices. Why should all DFZ routers outside that range know the details? Tony > > Tony > From owner-multi6@ops.ietf.org Tue Jan 7 21:28: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 VAA09112 for ; Tue, 7 Jan 2003 21:27:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18W5zB-0009CA-00 for multi6-data@psg.com; Tue, 07 Jan 2003 18:30:29 -0800 Received: from [65.174.124.36] (helo=dmz1.procket.com) by psg.com with esmtp (Exim 3.36 #2) id 18W5yd-00095q-00 for multi6@ops.ietf.org; Tue, 07 Jan 2003 18:29:57 -0800 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id 30BB623C41; Tue, 7 Jan 2003 18:19:29 -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 h082TJie028335; Tue, 7 Jan 2003 18:29:20 -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="iso-8859-1" Subject: RE: draft-kurtis-multihoming-longprefix comments Date: Tue, 7 Jan 2003 18:29:19 -0800 Message-ID: Thread-Topic: draft-kurtis-multihoming-longprefix comments Thread-Index: AcK2u6M03ZIaTgB+QRqnDrpyOa99gwAAMYqQ From: "Tony Li" To: , "J. Noel Chiappa" , X-Spam-Status: No, hits=0.8 required=5.0 tests=SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id VAA09112 | I bring it up because it is not significantly different than other | mapping schemes that have been proposed. We know it doesn't | scale, and | it is only done once at call setup rather than per packet. Correct. And in some cases, it seems that folks are getting paid for the feature. | > Yes, they both do. People still don't like 'em cause they're | > "not the IP way." | | If by 'IP way' you mean that it is a change to the expectations apps | have of the underlying architecture, then I have to agree. It is not | clear to me that 16+16 is visible to apps, so maybe that | doesn't apply. 16+16 would be very visible to the apps. In fact, any change that has independent identifiers and locators would be a change to the apps. Because they are not expecting/allowing that. | You seem to think I am being obstructionist. I am not. Then please educate me on your position. What scalable, implementable solution do you advocate? | And when I am in Japan connecting to home, topological | detail of Seattle | has absolutely nothing to do with which service provider I | hand packets | to. The fact the destination is Seattle rather than San | Francisco might | have something to do with a trans-pacific cable choice, but | the cable & | dsl providers are present in both so PA doesn't really help with TE | there. Once the radius is reduced to 1000km, the number of | possibilities | increases dramatically, but outside that range there are | really very few | choices. Why should all DFZ routers outside that range know | the details? You're suggesting abstraction that grows with distance. You may recall that I proposed that we do exactly this in 1992 with continental aggregation. I was shouted down. This only works because in almost all cases, continents are internally connected and the number of exceptions is quite small. Further, over time, as we wire the planet, even these exceptions will disappear. So yes, I have no objections to continental scale aggregation. Unfortunately, that is not a technique that recurses down to the micro level. We need to work with the connectivity that is naturally in place and cannot force fit it to suit. To take your street address metaphor farther, we should not insist on building bridges across the Grand Canyon just to insure that a zip code is contiguous. Tony From owner-multi6@ops.ietf.org Tue Jan 7 22:06: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 WAA09746 for ; Tue, 7 Jan 2003 22:05:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18W6aI-000BYK-00 for multi6-data@psg.com; Tue, 07 Jan 2003 19:08:50 -0800 Received: from jazz-1.trumpet.com.au ([203.5.119.62]) by psg.com with esmtp (Exim 3.36 #2) id 18W6Yc-000BPB-00 for multi6@ops.ietf.org; Tue, 07 Jan 2003 19:07:06 -0800 Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id OAA24408; Wed, 8 Jan 2003 14:06:42 +1100 (EST) Date: Wed, 8 Jan 2003 14:06:42 +1100 (EST) From: Peter Tattam To: Tony Li cc: alh-ietf@tndh.net, "J. Noel Chiappa" , multi6@ops.ietf.org Subject: RE: draft-kurtis-multihoming-longprefix comments In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.0 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, 7 Jan 2003, Tony Li wrote: .... > > | > Yes, they both do. People still don't like 'em cause they're > | > "not the IP way." > | > | If by 'IP way' you mean that it is a change to the expectations apps > | have of the underlying architecture, then I have to agree. It is not > | clear to me that 16+16 is visible to apps, so maybe that > | doesn't apply. > > > 16+16 would be very visible to the apps. In fact, any change that has > independent identifiers and locators would be a change to the apps. Because they > are not expecting/allowing that. I have had little feedback on my recent idea. I am not sure if it is a duplicate of other work or whether it will even work. I believe if it works (i.e. scales reasonably and is reliable) then it would solve the application level locator issue as the transport addresses are insulated from the application socket structures and DNS structures. .... > > Tony > > 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 Wed Jan 8 09:52: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 JAA21504 for ; Wed, 8 Jan 2003 09:52:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18WHaR-000IMM-00 for multi6-data@psg.com; Wed, 08 Jan 2003 06:53:43 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 18WHZv-000IKW-00 for multi6@ops.ietf.org; Wed, 08 Jan 2003 06:53:11 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h08Eqgq15863 for ; Wed, 8 Jan 2003 15:52:42 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Wed, 8 Jan 2003 15:52:41 +0100 (CET) From: Iljitsch van Beijnum To: Subject: Overlapping namespaces Message-ID: <20030108154313.H11497-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.8 required=5.0 tests=SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk If we go down the identifier/locator separation path, what would be preferable: 1. Use an explicit namespace identifier 2. Accept overlapping namespaces (For instance, without further information the identifier 0x782e7476 could be interpreted as either "x.tv", a valid hostname, or "120.46.116.118", a valid IPv4 address.) From owner-multi6@ops.ietf.org Wed Jan 8 13:00: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 NAA29604 for ; Wed, 8 Jan 2003 13:00:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18WKUZ-0001XY-00 for multi6-data@psg.com; Wed, 08 Jan 2003 09:59:51 -0800 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #2) id 18WKUV-0001Wv-00 for multi6@ops.ietf.org; Wed, 08 Jan 2003 09:59:47 -0800 Received: from nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 9F96E137F0B; Wed, 8 Jan 2003 09:59:33 -0800 (PST) Date: Wed, 8 Jan 2003 09:59:30 -0800 Subject: Re: draft-kurtis-multihoming-longprefix comments 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: David Conrad In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-2.9 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02, USER_AGENT_APPLEMAIL version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Tony, On Tuesday, January 7, 2003, at 06:29 PM, Tony Li wrote: > 16+16 would be very visible to the apps. In fact, any change that has > independent identifiers and locators would be a change to the apps. Perhaps I misunderstand, but I don't see why this is the case. If you assume a border between the part of the network that cares about topological significance (that is, the core) and the part that does (that is, the end points), then doing mapping/unmapping at that border would be invisible to the applications -- the core only cares about the locator, not the end point identifier. For example, assume you throw out the current IPv6 address architecture and instead say that the lower 4 bytes of an IPv6 address is an IPv4 address. Now, assume reality in the on the non-core side of the border gateway, end users use IPv4. When a packet needs to transit the (IPv6 using) core, the border gateway does (the moral equivalent of) a (dnssec signed, of course) AAAA in-addr-style DNS lookup of the destination IPv4 address and synthesizes an IPv6 destination address composed of the destination IPv6 prefix returned by the DNS lookup (in the top half) and the destination IPv4 address (in the bottom half). When the packet hits the destination border, an IPv4 packet is synthesized from the lower 4 bytes of the IPv6 address. If you don't want to assume reality, use up to 8 bytes (or more, since we've agreed to throw out the existing IPv6 addressing architecture) for the end point identifier -- the in-addr-style lookup wouldn't care. Site multi-homing becomes trivial -- simply add additional prefixes in the RR set referenced by the in-addr-style lookup of the IPv4 host. If you want to get tricky, the border gateway could keep information about which prefix is best among the ones returned. Renumbering also becomes essentially a non-issue as it can be made transparent to the end users since end users are dealing with non-hierarchical identifiers. Mobility might also be simplified, although I think there are some issues wrt trust boundaries that need more thought. Of course, this is just an example of how one could implement a locator/identifier mapping mechanism that doesn't require apps to understand that mapping -- the key is to have a way of doing an 'unmapping'... Rgds, -drc From owner-multi6@ops.ietf.org Wed Jan 8 20:28: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 UAA16512 for ; Wed, 8 Jan 2003 20:28:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18WRTw-000Ha0-00 for multi6-data@psg.com; Wed, 08 Jan 2003 17:27:40 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #2) id 18WRTr-000HZn-00 for multi6@ops.ietf.org; Wed, 08 Jan 2003 17:27:35 -0800 Received: from localhost ([127.0.0.1] helo=rip.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 18WRTr-000NJn-00 for multi6@ops.ietf.org; Wed, 08 Jan 2003 17:27:35 -0800 Message-ID: <03f301c2b765$07e4a4c0$6401a8c0@tahoenetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit From: "Paul Francis" To: Subject: recent slowdown in routing table growth Date: Wed, 8 Jan 2003 14:26:47 -0800 X-Spam-Status: No, hits=0.3 required=5.0 tests=RESENT_TO,SPAM_PHRASE_01_02 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] I was just looking at a BGP FIB size growth chart and noticed that there was a dip followed by slowed growth around the middle of 1991. What caused that? PF From owner-multi6@ops.ietf.org Thu Jan 9 02:39: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 CAA02818 for ; Thu, 9 Jan 2003 02:39:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18WXJG-0006xe-00 for multi6-data@psg.com; Wed, 08 Jan 2003 23:41:02 -0800 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 18WXJC-0006x2-00 for multi6@ops.ietf.org; Wed, 08 Jan 2003 23:40:58 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h097epl07953; Thu, 9 Jan 2003 09:40:52 +0200 Date: Thu, 9 Jan 2003 09:40:50 +0200 (EET) From: Pekka Savola To: Paul Francis cc: multi6@ops.ietf.org Subject: Re: recent slowdown in routing table growth In-Reply-To: <03f301c2b765$07e4a4c0$6401a8c0@tahoenetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-0.9 required=5.0 tests=IN_REP_TO,SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01, USER_AGENT_PINE version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 8 Jan 2003, Paul Francis wrote: > I was just looking at a BGP FIB size growth chart and noticed that there was > a dip followed by slowed growth around the middle of 1991. ^^^^ you call that recent? :-) > What caused that? -- 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 Jan 9 09:13: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 JAA10209 for ; Thu, 9 Jan 2003 09:13:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18WdRO-000Ham-00 for multi6-data@psg.com; Thu, 09 Jan 2003 06:13:50 -0800 Received: from d12lmsgate-5.de.ibm.com ([194.196.100.238]) by psg.com with esmtp (Exim 3.36 #2) id 18WdRL-000Ha2-00 for multi6@ops.ietf.org; Thu, 09 Jan 2003 06:13:47 -0800 Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-5.de.ibm.com (8.12.3/8.12.3) with ESMTP id h09ECvqf024466; Thu, 9 Jan 2003 15:13:06 +0100 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id h09ECkTL074206; Thu, 9 Jan 2003 15:12:47 +0100 Received: from dhcp23-27.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA27236 from ; Thu, 9 Jan 2003 15:12:42 +0100 Message-Id: <3E1D8335.67179B0C@hursley.ibm.com> Date: Thu, 09 Jan 2003 15:12:05 +0100 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: Overlapping namespaces References: <20030108154313.H11497-100000@sequoia.muada.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-1.0 required=5.0 tests=NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Why would we have to make that choice, rather than simply picking a namespace? I would recommend a subset of the IPv6 address space as the namespace, with the current PA space as the locator space. (Two IPv6 addresses in one packet, one as a locator and one as an identifier. Why not?) Brian P.S. This is a solutions discussion. Where's the requirements draft at? Iljitsch van Beijnum wrote: > > If we go down the identifier/locator separation path, what would be > preferable: > > 1. Use an explicit namespace identifier > 2. Accept overlapping namespaces > > (For instance, without further information the identifier 0x782e7476 > could be interpreted as either "x.tv", a valid hostname, or > "120.46.116.118", a valid IPv4 address.) From owner-multi6@ops.ietf.org Thu Jan 9 09:27: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 JAA11168 for ; Thu, 9 Jan 2003 09:27:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Wdhk-000I2e-00 for multi6-data@psg.com; Thu, 09 Jan 2003 06:30:44 -0800 Received: from gnat.inet.org ([63.108.254.91]) by psg.com with esmtp (Exim 3.36 #2) id 18Wdhi-000I23-00 for multi6@ops.ietf.org; Thu, 09 Jan 2003 06:30:42 -0800 Received: from extremenetworks.com (unknown [10.18.3.100]) by gnat.inet.org (Postfix) with ESMTP id CE54C67103; Thu, 9 Jan 2003 09:35:13 -0500 (EST) Date: Thu, 9 Jan 2003 09:30:07 -0500 Subject: Re: Overlapping namespaces 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: RJ Atkinson In-Reply-To: <3E1D8335.67179B0C@hursley.ibm.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-2.6 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01, USER_AGENT_APPLEMAIL version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Thursday, Jan 9, 2003, at 09:12 America/Montreal, Brian E Carpenter wrote: > (Two IPv6 addresses in one packet, one as a locator and one as > an identifier. Why not?) The above is very substantially close to what the Mobile-IPv6 stuff is doing, at least in the documents I skimmed last Fall. Ran From owner-multi6@ops.ietf.org Thu Jan 9 10:29: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 KAA14562 for ; Thu, 9 Jan 2003 10:29:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Weez-000JiD-00 for multi6-data@psg.com; Thu, 09 Jan 2003 07:31:57 -0800 Received: from ginger.lcs.mit.edu ([18.26.0.82]) by psg.com with esmtp (Exim 3.36 #2) id 18Weew-000Jhu-00 for multi6@ops.ietf.org; Thu, 09 Jan 2003 07:31:55 -0800 Received: from ginger.lcs.mit.edu (localhost [127.0.0.1]) by ginger.lcs.mit.edu (8.12.6/8.12.6) with ESMTP id h09FVmMY012755; Thu, 9 Jan 2003 10:31:49 -0500 Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.12.6/8.12.6/Submit) id h09FVmcT012752; Thu, 9 Jan 2003 10:31:48 -0500 Date: Thu, 9 Jan 2003 10:31:48 -0500 From: "J. Noel Chiappa" Message-Id: <200301091531.h09FVmcT012752@ginger.lcs.mit.edu> To: multi6@ops.ietf.org Subject: Re: Overlapping namespaces Cc: jnc@ginger.lcs.mit.edu X-Spam-Status: No, hits=0.8 required=5.0 tests=SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: Brian E Carpenter > This is a solutions discussion. Where's the requirements draft at? To paraphrase an old line, "those who can, do, those who can't, write requirements documents". On a more serious note, I've really come to have a low opinion of requirements documents for what I think are several good reasons. For one, it seems that people spend inordinate amounts of time creating and arguing over them, and we don't have infinite free engineer-hours. For another, requirements documents cannot take into account the varying costs of providing each of the requirements - which often trade off against each other in ways that depend on the exact details of the various possible engineering solutions. They also usually don't examine the benefits of each requirement - which is really necessary when you start to examine the cost/benefit ratio of meeting each requirement. To give an example from the current context - when a multi-homed site loses one link, do we want to be able to keep existing connections that use that link open? Well, it sounds like a useful requirement - but how expensive (in complexity, etc) is it, versus how much benefit will we really see from it (in a world in which most interactions use the Web, and most Web transactions use short TCP connections, and depend on cookies for long-term interactions). Somehow I don't think a requirements document is going to answer that, especially since the answer depends on how much doing it costs - which you don't know until you've done the design. So requirements documents always seem to turn either into: - i) a Procrustean bed, in which all requirements have to be met no matter how poor the cost/benefit ratio - and which, moreover, delude people into thinking that if all the requirements are met, then a good outcome is guaranteed, which is almost the exact opposite of the truth (recall my aphorism that the measure of a great architecture is one which meets requirements the designers didn't know about - and that doesn't consider other issues, like a design failing because it reaches kitchen-sink levels of inclusiveness and consequently ponderousness), or - ii) documents that in the end provide only a limited amount of guidance anyway. Having said all that, it might be nice to have a short (3-4 page) document that generates some *brief* discussion (e.g. I still don't know what people think about the example above, whether it's necessary to keep connections open). However, the massive exercises we've seen too many of in the IETF recently are an almost complete waste of time, IMO. Noel From owner-multi6@ops.ietf.org Thu Jan 9 11:17: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 LAA16368 for ; Thu, 9 Jan 2003 11:17:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18WfPt-000LIP-00 for multi6-data@psg.com; Thu, 09 Jan 2003 08:20:25 -0800 Received: from d12lmsgate.de.ibm.com ([194.196.100.234]) by psg.com with esmtp (Exim 3.36 #2) id 18WfPq-000LGP-00 for multi6@ops.ietf.org; Thu, 09 Jan 2003 08:20:22 -0800 Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id h09GJehk040644; Thu, 9 Jan 2003 17:19:45 +0100 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id h09GJbYn145540; Thu, 9 Jan 2003 17:19:37 +0100 Received: from dhcp23-27.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA49254 from ; Thu, 9 Jan 2003 17:19:34 +0100 Message-Id: <3E1DA0F0.100F4C88@hursley.ibm.com> Date: Thu, 09 Jan 2003 17:18:56 +0100 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: alh-ietf@tndh.net Cc: multi6@ops.ietf.org Subject: Re: draft-kurtis-multihoming-longprefix comments References: <041901c2b683$5b679040$9f144104@eagleswings> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-1.0 required=5.0 tests=NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Tony Hain wrote: ... > People aren't asking for location-independent addresses, in fact they > are asking for the architectural equivalent of a street address. > I disagree. They are asking for the equivalent of a cell phone number, on a network that doesn't have a call setup phase. Brian From owner-multi6@ops.ietf.org Thu Jan 9 11:16: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 LAA16361 for ; Thu, 9 Jan 2003 11:16:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18WfPI-000LGM-00 for multi6-data@psg.com; Thu, 09 Jan 2003 08:19:48 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 18WfPF-000LG2-00 for multi6@ops.ietf.org; Thu, 09 Jan 2003 08:19:45 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h09GJEK18177; Thu, 9 Jan 2003 17:19:15 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Thu, 9 Jan 2003 17:19:14 +0100 (CET) From: Iljitsch van Beijnum To: Brian E Carpenter cc: Subject: Re: Overlapping namespaces In-Reply-To: <3E1D8335.67179B0C@hursley.ibm.com> Message-ID: <20030109163813.I11497-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.4 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Thu, 9 Jan 2003, Brian E Carpenter wrote: > Why would we have to make that choice, rather than simply picking a > namespace? Maybe a better one will be invented in the future. Also, something like HIP looks interesting and would be easier to support this way. > I would recommend a subset of the IPv6 address space as the namespace, > with the current PA space as the locator space. Hm, then those could also be used as the globally unique site local addresses the ipv6 wg (or was it one of the others?) is looking for. And it could lead towards Michel's MHAP. > (Two IPv6 addresses in one packet, one as a locator and one as > an identifier. Why not?) Because IPv6 packets have too much overhead as it is. With an additional 32 bytes a TCP ACK would be 92 bytes, more than twice what it is in IPv4. Also, why would the identifier have to be in each packet? Exchanging them at the start of a session should be enough. > P.S. This is a solutions discussion. Where's the requirements draft at? There was essentially zero progress for the requirements draft in 2002. From owner-multi6@ops.ietf.org Thu Jan 9 12:04: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 MAA17860 for ; Thu, 9 Jan 2003 12:04:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Wg8Q-000MLK-00 for multi6-data@psg.com; Thu, 09 Jan 2003 09:06:26 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #2) id 18Wg8N-000ML2-00 for multi6@ops.ietf.org; Thu, 09 Jan 2003 09:06:23 -0800 Received: from localhost ([127.0.0.1] helo=rip.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 18Wg8N-0000ca-00 for multi6@ops.ietf.org; Thu, 09 Jan 2003 09:06:23 -0800 Message-ID: <042501c2b7fa$5829b2f0$6401a8c0@tahoenetworks.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit From: "Paul Francis" To: "Pekka Savola" Cc: Subject: Re: recent slowdown in routing table growth Date: Thu, 9 Jan 2003 08:15:35 -0800 X-Spam-Status: No, hits=-1.0 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,RESENT_TO,SPAM_PHRASE_01_02 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] I'm sorry, I meant middle of 2001. PF ----- Original Message ----- From: "Pekka Savola" To: "Paul Francis" Cc: Sent: Wednesday, January 08, 2003 11:40 PM Subject: Re: recent slowdown in routing table growth > On Wed, 8 Jan 2003, Paul Francis wrote: > > I was just looking at a BGP FIB size growth chart and noticed that there was > > a dip followed by slowed growth around the middle of 1991. > ^^^^ > > you call that recent? :-) > > > What caused that? > > -- > 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 Jan 9 17:04: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 RAA27900 for ; Thu, 9 Jan 2003 17:04:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18WkoU-0003hS-00 for multi6-data@psg.com; Thu, 09 Jan 2003 14:06:10 -0800 Received: from [65.174.124.36] (helo=dmz1.procket.com) by psg.com with esmtp (Exim 3.36 #2) id 18WkoR-0003fz-00 for multi6@ops.ietf.org; Thu, 09 Jan 2003 14:06:07 -0800 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id 8740D23C5C; Thu, 9 Jan 2003 14:05:58 -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 h09M5aZR006919; Thu, 9 Jan 2003 14:05:36 -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="iso-8859-1" Subject: RE: recent slowdown in routing table growth Date: Thu, 9 Jan 2003 14:05:36 -0800 Message-ID: Thread-Topic: recent slowdown in routing table growth Thread-Index: AcK4AgLr5EicE7gCS0OmIbjH8FnlQQAKRYgQ From: "Tony Li" To: "Paul Francis" , "Pekka Savola" Cc: X-Spam-Status: No, hits=0.5 required=5.0 tests=SPAM_PHRASE_01_02 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA27900 I believe that coincided with another round of conciousness raising and subsequent housecleaning by several ISPs. One way to confirm this would be to dig through the discussions on the NANOG archives. Tony | -----Original Message----- | From: Paul Francis [mailto:paul@francis.com] | Sent: Thursday, January 09, 2003 8:16 AM | To: Pekka Savola | Cc: multi6@ops.ietf.org | Subject: Re: recent slowdown in routing table growth | | | [ post by non-subscriber. with the massive amount of spam, | it is easy to miss | and therefore delete posts by non-subscribers. if you | wish to regularly | post from an address that is not subscribed to this | mailing list, send a | message to -owner@ops.ietf.org and ask to have | the alternate | address added to the list of addresses from which submissions are | automatically accepted. ] | | I'm sorry, I meant middle of 2001. | | PF | | | ----- Original Message ----- | From: "Pekka Savola" | To: "Paul Francis" | Cc: | Sent: Wednesday, January 08, 2003 11:40 PM | Subject: Re: recent slowdown in routing table growth | | | > On Wed, 8 Jan 2003, Paul Francis wrote: | > > I was just looking at a BGP FIB size growth chart and | noticed that there | was | > > a dip followed by slowed growth around the middle of 1991. | > ^^^^ | > | > you call that recent? :-) | > | > > What caused that? | > | > -- | > 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 Jan 9 17:09: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 RAA28007 for ; Thu, 9 Jan 2003 17:09:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18WkuZ-0003tn-00 for multi6-data@psg.com; Thu, 09 Jan 2003 14:12:27 -0800 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 18WkuW-0003tV-00 for multi6@ops.ietf.org; Thu, 09 Jan 2003 14:12:24 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h09MC9e13857; Fri, 10 Jan 2003 00:12:09 +0200 Date: Fri, 10 Jan 2003 00:12:09 +0200 (EET) From: Pekka Savola To: Tony Li cc: Paul Francis , Subject: RE: recent slowdown in routing table growth In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.0 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_01_02,USER_AGENT_PINE version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Thu, 9 Jan 2003, Tony Li wrote: > I believe that coincided with another round of conciousness > raising and subsequent housecleaning by several ISPs. One > way to confirm this would be to dig through the discussions > on the NANOG archives. My belief is that this was caused by two factors: 1) raised awareness: this exponentially-looking growth raised some alarms, there was a presentation in IETF51 in London (Aug 2001), etc. -- (some) people fixed some of their systems. 2) the dotcom bubble bursting may have killed off a bit of multihoming etc. efforts. Mainly 1), but I'd also like to get some more concrete references. > | -----Original Message----- > | From: Paul Francis [mailto:paul@francis.com] > | Sent: Thursday, January 09, 2003 8:16 AM > | To: Pekka Savola > | Cc: multi6@ops.ietf.org > | Subject: Re: recent slowdown in routing table growth > | > | > | [ post by non-subscriber. with the massive amount of spam, > | it is easy to miss > | and therefore delete posts by non-subscribers. if you > | wish to regularly > | post from an address that is not subscribed to this > | mailing list, send a > | message to -owner@ops.ietf.org and ask to have > | the alternate > | address added to the list of addresses from which submissions are > | automatically accepted. ] > | > | I'm sorry, I meant middle of 2001. > | > | PF > | > | > | ----- Original Message ----- > | From: "Pekka Savola" > | To: "Paul Francis" > | Cc: > | Sent: Wednesday, January 08, 2003 11:40 PM > | Subject: Re: recent slowdown in routing table growth > | > | > | > On Wed, 8 Jan 2003, Paul Francis wrote: > | > > I was just looking at a BGP FIB size growth chart and > | noticed that there > | was > | > > a dip followed by slowed growth around the middle of 1991. > | > ^^^^ > | > > | > you call that recent? :-) > | > > | > > What caused that? > | > > | > -- > | > Pekka Savola "You each name yourselves > | king, yet the > | > Netcore Oy kingdom bleeds." > | > Systems. Networks. Security. -- George R.R. Martin: A > | Clash of Kings > | > > | > | > | > | > | > -- 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 Jan 9 18:20: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 SAA00140 for ; Thu, 9 Jan 2003 18:20:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Wm13-0005zq-00 for multi6-data@psg.com; Thu, 09 Jan 2003 15:23:13 -0800 Received: from kc-msxproto4.kc.umkc.edu ([134.193.143.48]) by psg.com with esmtp (Exim 3.36 #2) id 18Wm10-0005zE-00 for multi6@ops.ietf.org; Thu, 09 Jan 2003 15:23:10 -0800 Received: from KC-MAIL2.kc.umkc.edu ([134.193.143.162] RDNS failed) by kc-msxproto4.kc.umkc.edu with Microsoft SMTPSVC(5.0.2195.5329); Thu, 9 Jan 2003 17:23:09 -0600 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="iso-8859-1" Subject: RE: recent slowdown in routing table growth Date: Thu, 9 Jan 2003 17:23:08 -0600 Message-ID: Thread-Topic: recent slowdown in routing table growth Thread-Index: AcK4L1dy0ogHr8RuRPCMynBVRr54zQAAQ5oQ From: "Ayyasamy, Senthilkumar (UMKC-Student)" To: "Pekka Savola" , "Tony Li" Cc: "Paul Francis" , X-OriginalArrivalTime: 09 Jan 2003 23:23:09.0212 (UTC) FILETIME=[122785C0:01C2B836] X-Spam-Status: No, hits=0.9 required=5.0 tests=FROM_ENDS_IN_NUMS,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA00140 > 1) raised awareness: this exponentially-looking growth raised some > alarms, there was a presentation in IETF51 in London (Aug > 2001), etc. -- > (some) people fixed some of their systems. > Mainly 1), but I'd also like to get some more concrete references. http://www.potaroo.net/papers/bgp/bgp-june02.pdf http://www.packetdesign.net/docs/cengiz.pdf Major reasons for the dip in growth: - reduced number of specific entries due to awareness based on CIDR report. - Use of prefix length route-filtering But,as per geoff's presentation, multi-homing/TE will surely be a major contributor in future. Also, see slide 10-12 in cengiz's presentation on the exact break down for the contributing factors in multi-homing. It is good to hear that misconfigurations/multi-homing by means of MOAS is decreasing. Although, MOAS is an operational technique, people do engineer them purposely/accidently. One can check geoff huston BGP page for an up-to-date report. Also, compare the above presentations with the previous IETF ptomaine/plenary presentations. I think, prefix filtering contributed the most to the present reduction in growth (refer randy's presentation-51th IETF) From owner-multi6@ops.ietf.org Thu Jan 9 18:59: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 SAA00886 for ; Thu, 9 Jan 2003 18:59:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18WmcQ-0007Br-00 for multi6-data@psg.com; Thu, 09 Jan 2003 16:01:50 -0800 Received: from evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net ([4.65.20.139] helo=tndh.net) by psg.com with esmtp (Exim 3.36 #2) id 18WmcN-0007Be-00 for multi6@ops.ietf.org; Thu, 09 Jan 2003 16:01:47 -0800 Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Thu, 09 Jan 2003 16:01:52 -0800 Reply-To: From: "Tony Hain" To: "'Tony Li'" , "'J. Noel Chiappa'" , Subject: RE: draft-kurtis-multihoming-longprefix comments Date: Thu, 9 Jan 2003 16:01:21 -0800 Message-ID: <063001c2b83b$68e785e0$9f144104@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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA00886 Tony Li wrote: > ... > You're suggesting abstraction that grows with distance. You > may recall that I proposed that we do exactly this in 1992 > with continental aggregation. I was shouted down. That doesn't mean it was a bad idea, just ahead of its time. :) > > This only works because in almost all cases, continents are > internally connected and the number of exceptions is quite > small. Further, over time, as we wire the planet, even these > exceptions will disappear. > > So yes, I have no objections to continental scale aggregation. > Unfortunately, that is not a technique that recurses down to the > micro level. We need to work with the connectivity that is > naturally in place and cannot force fit it to suit. > > To take your street address metaphor farther, we should not > insist on building bridges across the Grand Canyon just to > insure that a zip code is contiguous. The contiguous requirement only applies to short prefixes. In the case where it is not possible to make it contiguous, longer prefixes are necessary. The fact it is not perfect does not mean the whole approach is invalid, just that it carries a set of engineering trade-off's like all the others. For the sake of discussion, let's assume it is technically, financially, or politically infeasible to bridge the Grand Canyon. Also that there is a significant population of multi-homed sites on both sides. This would lead to all circuits on the north rim routing through Salt Lake City, while the south rim routes through Phoenix (ignoring the obvious cross connect through Las Vegas or LA). Further, continental scale aggregation is done in San Jose, Chicago, and D.C. Using the draft I have been working on, there are 18 /24's that would need a longer prefix exception list. See: http://www.tndh.net/~tony/ietf/GrandCanyon.htm Most of that space would be cleanly described by /26's, where the conflicts in turn being cleanly broken down by /28's ... The routing table grows with each exception region, but not at the rate of multi-homed sites. At the same time, an announcement only needs to be present if there is a site in the space covered. The prefix x6C0::/12 covering Santa Maria (west 120w), Santa Ines (south 30n), Denver (east 105w), Wyoming northern border (north 45n), associates with the San Jose aggregation point. If divided into /14's, the cut would be through the middle of the canyon about 32km west of Grand Canyon Village. The Glen Canyon section would be divided about 55km north of the Utah southern border. This leaves the entire /14 containing Fresno, Boise, and most of Nevada contiguous. The other 3 are mostly contiguous, just needing ~50 /28's to cover the exceptions. The point is that only providers connecting to San Jose would need to know the detail. Regional providers in the rest of the world would only see the x6C0::/12 announcement, if that. They might only be looking at the ::/6 which identifies the section. Also, it is clear there are other rivers covering more distance, so this is not meant to claim this is a worst case, just an exercise to show what would be necessary to address the premise. You claim it can't recurse down to the micro level. I disagree, because it will recurse on whatever scale makes economic sense. When there are too many exception entries, it will become economically viable to split the space by putting in more exchanges. The economic driver is the reason for the current set of exchanges. Historically those have been driven by circuit costs, but in an environment of capacity glut the economics change. Either way, you can't avoid flat routing in some subset of the routers, it is just a trade-off between how many routers need to know the detail vs. the interconnectivity required to mask that detail. You further claim we have to work with the connectivity that is in place, which is demonstrably false. Otherwise we would still be routing through FIX-E&W via government nets or NSF Regional's (or IMPs if we go further back). Connectivity evolves over time to match the current state of the players and the economic limitations. While we can't dictate a connectivity model, we can define technologies that work best with one or two models, while having the ability to handle exceptions. This is exactly how we migrated from government sponsored to commercial networks. It is also the case that even if we found a 'perfect' technology for the current interconnectivity, in 5 years time that model wouldn't be perfect anymore because the connectivity underneath it as well as the policies for traffic management would have changed. If we can agree on the defining characteristic separating the basement multi-homer from the global enterprise network, we can define different connectivity models for each. My approach is not intended to be a grand one-size-fits-all technology, and exceptions showing when PA should be used are discussed in the drafts. It is simply an approach that leverages current BGP deployments, and can be scaled in different parts of the world to whatever level makes economic sense. In the spirit of globalization via the Internet, it explicitly ignores artificial political borders. This may be a good or bad thing based on your views about being politically correct. ;) Tony From owner-multi6@ops.ietf.org Thu Jan 9 19:02: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 TAA01006 for ; Thu, 9 Jan 2003 19:02:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Wmfy-0007JX-00 for multi6-data@psg.com; Thu, 09 Jan 2003 16:05:30 -0800 Received: from evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net ([4.65.20.139] helo=tndh.net) by psg.com with esmtp (Exim 3.36 #2) id 18Wmfv-0007JC-00 for multi6@ops.ietf.org; Thu, 09 Jan 2003 16:05:27 -0800 Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Thu, 09 Jan 2003 16:05:33 -0800 Reply-To: From: "Tony Hain" To: "'Brian E Carpenter'" Cc: Subject: RE: draft-kurtis-multihoming-longprefix comments Date: Thu, 9 Jan 2003 16:05:03 -0800 Message-ID: <063101c2b83b$ecf844f0$9f144104@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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <3E1DA0F0.100F4C88@hursley.ibm.com> X-Spam-Status: No, hits=-1.1 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA01006 Brian E Carpenter wrote: > Tony Hain wrote: > ... > > People aren't asking for location-independent addresses, in > fact they > > are asking for the architectural equivalent of a street address. > > > > I disagree. They are asking for the equivalent of a cell > phone number, on a network that doesn't have a call setup phase. I think we are trying to get to the same place in terms of real-time air-link portability, but current implementations of cell addresses require changing whenever the service contractor changes. This is clearly acceptable to the individual, even if annoying, but to the larger entities it represents a provider lock because it becomes very costly to change. To be specific, they want: an unambiguous address that will reach the device, independent of carriage or contractor relationship over time. In other words, they should be able to change or have multiple service providers without requiring any coorelation between the address and the provider of the transport service. I believe this is closer to a street address than it is to a cell device. This is the crux of the discussion here, because that goal is completely divergent from optimizing a connectivity graph to minimize the size of the routing table. While our task is to find soulutions that keep the routing table at a reasonable scale, ignoring the basic requirement as too difficult is not useful. Tony From owner-multi6@ops.ietf.org Thu Jan 9 19:06: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 TAA01059 for ; Thu, 9 Jan 2003 19:06:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18WmjU-0007c1-00 for multi6-data@psg.com; Thu, 09 Jan 2003 16:09:08 -0800 Received: from sj-msg-core-3.cisco.com ([171.70.157.152]) by psg.com with esmtp (Exim 3.36 #2) id 18WmjR-0007aB-00 for multi6@ops.ietf.org; Thu, 09 Jan 2003 16:09:05 -0800 Received: from cisco.com (dhcp-128-107-213-207.cisco.com [128.107.213.207]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id h0A07xjS026333; Thu, 9 Jan 2003 16:08:00 -0800 (PST) Message-ID: <3E1E0F01.2090703@cisco.com> Date: Thu, 09 Jan 2003 16:08:33 -0800 From: Eliot Lear User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: alh-ietf@tndh.net CC: "'Brian E Carpenter'" , multi6@ops.ietf.org Subject: Re: draft-kurtis-multihoming-longprefix comments References: <063101c2b83b$ecf844f0$9f144104@eagleswings> In-Reply-To: <063101c2b83b$ecf844f0$9f144104@eagleswings> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-1.8 required=5.0 tests=IN_REP_TO,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Tony, Over time we still have DNS to allow for people to make changes. This means that one has to work the transition such that prefixes can change at the convenience of the end user. Eliot From owner-multi6@ops.ietf.org Thu Jan 9 19:07: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 TAA01096 for ; Thu, 9 Jan 2003 19:07:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18WmlM-0007gE-00 for multi6-data@psg.com; Thu, 09 Jan 2003 16:11:04 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 18WmlK-0007g1-00 for multi6@ops.ietf.org; Thu, 09 Jan 2003 16:11:02 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h0A0AM218799; Fri, 10 Jan 2003 01:10:26 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Fri, 10 Jan 2003 01:10:22 +0100 (CET) From: Iljitsch van Beijnum To: "Ayyasamy, Senthilkumar (UMKC-Student)" cc: Subject: RE: recent slowdown in routing table growth In-Reply-To: Message-ID: <20030110005058.S11497-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.7 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_01_02 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Thu, 9 Jan 2003, Ayyasamy, Senthilkumar (UMKC-Student) wrote: > But,as per geoff's presentation, multi-homing/TE will surely > be a major contributor in future. Why do people keep blaming multihomers for the mess that is the global routing table? Based on what we can see today, this is utter nonsense. There are maybe 10000 multihomers in the world. Even if they all do traffic engineering that's 20k routes, out of the 110k we see today. The absolute number one top reason for routing table pollution is stupidity. I came very close to including a routing table dump for AS7843. That's 610 routes, which is insane by any account. There are more than 50 ASes that announce more than 100 unnecessary prefixes, for a total of around 10% of the routing table. This is nothing less than criminal. See http://www.mcvax.org/~jhma/routing/all2.html Then there are the address conservation policies, which make the RIRs assign small blocks time and time again to people that are burning through IP addresses like a forrest fire. Routing table size problems because of multihoming are simply impossible because of the 16 bit AS number space and the current IPv6 routing guidelines that forbid multihoming. You might as well blame Coca Cola for global warming because of the carbon dioxide that escapes from their soft drinks. That makes more sense than blaming multihomers for the routing table size. > I think, prefix filtering contributed the most to the present > reduction in growth (refer randy's presentation-51th IETF) Prefix filtering is evil because it targets the wrong people: multihomers. De-peering that top 50 list will do much more good. From owner-multi6@ops.ietf.org Thu Jan 9 20: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 UAA02955 for ; Thu, 9 Jan 2003 20:19:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Wns3-0009Qi-00 for multi6-data@psg.com; Thu, 09 Jan 2003 17:22:03 -0800 Received: from kc-msxproto2.kc.umkc.edu ([134.193.143.159]) by psg.com with esmtp (Exim 3.36 #2) id 18Wns1-0009QW-00 for multi6@ops.ietf.org; Thu, 09 Jan 2003 17:22:01 -0800 Received: from KC-MAIL2.kc.umkc.edu ([134.193.143.162] RDNS failed) by kc-msxproto2.kc.umkc.edu with Microsoft SMTPSVC(5.0.2195.5329); Thu, 9 Jan 2003 19:21:59 -0600 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="iso-8859-1" Subject: RE: recent slowdown in routing table growth Date: Thu, 9 Jan 2003 19:21:59 -0600 Message-ID: Thread-Topic: recent slowdown in routing table growth Thread-Index: AcK4PJUblo80qtYwT7SB0JIzpbOWKAACDFhw From: "Ayyasamy, Senthilkumar (UMKC-Student)" To: "Iljitsch van Beijnum" Cc: X-OriginalArrivalTime: 10 Jan 2003 01:21:59.0506 (UTC) FILETIME=[AC240B20:01C2B846] X-Spam-Status: No, hits=0.6 required=5.0 tests=FROM_ENDS_IN_NUMS,QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id UAA02955 > > But,as per geoff's presentation, multi-homing/TE will surely > > be a major contributor in future. > > Why do people keep blaming multihomers for the mess that is the global > routing table? Its a prediction and not a proved fact. But, your correct that address fragmentation and failure to aggregate contribute more to the growth than multi-homing/load balancing(TE) > Prefix filtering is evil because it targets the wrong people: > multihomers. yup. that is a major problem with prefix filtering. we have to find methods for announcing fine-grained prefixes( to allow TE/multi-homing.) I don't know if any one have suggestions. But, http://www.research.att.com/~jrex/papers/filter.pdf suggests that we can define reserved communities to label those prefixes. I have some other comments -like how one can cluster a set of identically announced prefixes to reduce RT size. We can have it off-list(if you like), as the discussion is far off from multi6 charter. From owner-multi6@ops.ietf.org Thu Jan 9 20:32: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 UAA03218 for ; Thu, 9 Jan 2003 20:32:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Wo56-0009dr-00 for multi6-data@psg.com; Thu, 09 Jan 2003 17:35:32 -0800 Received: from evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net ([4.65.20.139] helo=tndh.net) by psg.com with esmtp (Exim 3.36 #2) id 18Wo53-0009df-00 for multi6@ops.ietf.org; Thu, 09 Jan 2003 17:35:29 -0800 Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Thu, 09 Jan 2003 17:35:33 -0800 Reply-To: From: "Tony Hain" To: "'Eliot Lear'" Cc: "'Brian E Carpenter'" , Subject: RE: draft-kurtis-multihoming-longprefix comments Date: Thu, 9 Jan 2003 17:35:03 -0800 Message-ID: <063301c2b848$7f57c5d0$9f144104@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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <3E1E0F01.2090703@cisco.com> X-Spam-Status: No, hits=-0.5 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_03_05 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id UAA03218 Eliot Lear wrote: > Over time we still have DNS to allow for people to make > changes. This > means that one has to work the transition such that prefixes > can change > at the convenience of the end user. My name does not change when I move or change cell providers, but it is still painful and expensive to touch every place that has the name to address mapping. Multiply that for larger enterprises, and the numbers get big enough for budget watchers to notice. Also, we already see a market for email redirection, where an email address can stay consistent over ISP changes. Clearly some people don't want to deal with changing the mappings from their name to the locator info if they don't have to, and large enterprises do this all the time by registering their own names rather than taking a subdomain from the ISP. In any case, DNS is not the only place names are translated into addresses, so we must not base an approach on the assumption that it is. Tony From owner-multi6@ops.ietf.org Fri Jan 10 02:49: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 CAA19983 for ; Fri, 10 Jan 2003 02:49:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18WtwO-000Fzl-00 for multi6-data@psg.com; Thu, 09 Jan 2003 23:50:56 -0800 Received: from [65.174.124.37] (helo=dmz2.procket.com) by psg.com with esmtp (Exim 3.36 #2) id 18WtwM-000FzH-00 for multi6@ops.ietf.org; Thu, 09 Jan 2003 23:50:54 -0800 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id 3E8F43445E; Fri, 10 Jan 2003 00:01:04 -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 h0A7oIZR026560; Thu, 9 Jan 2003 23:50:19 -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="iso-8859-1" Subject: RE: recent slowdown in routing table growth Date: Thu, 9 Jan 2003 23:50:18 -0800 Message-ID: Thread-Topic: recent slowdown in routing table growth Thread-Index: AcK4PSChYIUSlMiWRwu8v/Da9jf1IQAPqSoA From: "Tony Li" To: "Iljitsch van Beijnum" , "Ayyasamy, Senthilkumar (UMKC-Student)" Cc: X-Spam-Status: No, hits=0.8 required=5.0 tests=SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA19983 | Why do people keep blaming multihomers for the mess that is | the global routing table? Because it is an unsolved technical problem that needs to be addressed. Please consider the very long term. What will IPv6 look like in 2050? | Based on what we can see today, this is utter nonsense. | There are maybe 10000 multihomers in the world. So? It will continue to grow. I can remember when the default free table was 5000 routes. Total. And the number of multihomers will eventually start to grow faster than the number of ISPs. We're already seeing ISP contraction. Connectivity is becoming more mission-critical every day, so more people multihome for reliability. And today those 10000 cost more resources to the DFZ than any other 10000 sites. | The absolute number one top reason for routing table pollution | is stupidity. Agreed, but the IETF is *NOT* about reducing stupidity. Don't believe me? Go to a meeting. ;-) | Routing table size problems because of multihoming are simply impossible | because of the 16 bit AS number space and the current IPv6 routing | guidelines that forbid multihoming. And what happens when we shift to 4 byte AS numbers? And the restriction on multihoming is lifted because we, in our infinite wisdom, decided that PI space is just fine? We need an architecture where people can multihome without a DFZ routing table entry. And yes, we need to fix a lot of other problems too. But any one of these problems could eventually eat us alive and we have to fix all of them. My vote is that we not forget the harder technical issues and leave the social engineering issues for those that are more qualified. Tony From owner-multi6@ops.ietf.org Fri Jan 10 05:06: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 FAA22885 for ; Fri, 10 Jan 2003 05:06:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Ww5i-000IMj-00 for multi6-data@psg.com; Fri, 10 Jan 2003 02:08:42 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 18Ww5g-000IMV-00 for multi6@ops.ietf.org; Fri, 10 Jan 2003 02:08:40 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h0AA87919899; Fri, 10 Jan 2003 11:08:08 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Fri, 10 Jan 2003 11:08:07 +0100 (CET) From: Iljitsch van Beijnum To: Tony Li cc: Subject: RE: recent slowdown in routing table growth In-Reply-To: Message-ID: <20030110104351.H11497-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.4 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Thu, 9 Jan 2003, Tony Li wrote: > | Why do people keep blaming multihomers for the mess that is > | the global routing table? > Because it is an unsolved technical problem that needs to be addressed. > Please consider the very long term. What will IPv6 look like in 2050? Long term concern is reasonable, but today's mess has nothing to do with multihoming. > | Based on what we can see today, this is utter nonsense. > | There are maybe 10000 multihomers in the world. > So? It will continue to grow. I can remember when the default free > table was 5000 routes. Total. And the number of multihomers will > eventually start to grow faster than the number of ISPs. We're > already seeing ISP contraction. But this doesn't mean consolidation of the prefixes they announce so this is largely meaningless. In IPv4, the problem is unsolvable. Unfortunately, IPv6 is inheriting too many of the problematic IPv6 policies but the larger address space and stricter rules should help. > And today those 10000 cost more resources to the DFZ than any other > 10000 sites. Today 50 incompetent network administrators cost more resources than the 10000 most resource-costly but well-managed sites. > We need an architecture where people can multihome without a DFZ routing > table entry. And yes, we need to fix a lot of other problems too. But > any one of these problems could eventually eat us alive and we have to > fix all of them. My vote is that we not forget the harder technical > issues and leave the social engineering issues for those that are more > qualified. We all know what needs to be done but somehow that's not enough to make it happen. There are basically two ways to engineer solutions to problems that are hard to solve by conventional methods: 1. Use conventional/proven/obvious solutions and simply keep working until you have something that works well enough to be usable 2. Think out of the box The problem with type 1 solutions is that they tend to be huge and complex and this only gets worse over time. The problem with type 2 solutions is that they often seem ridiculous. "Packet switching? That will never work." "Reduce the instruction set? That's nonsense." "Publish the encryption algorithm? Don't be silly." It turned out that packet switching, RISC CPUs and public scruteny of encryption algorithms were major steps forward. From owner-multi6@ops.ietf.org Fri Jan 10 05:11: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 FAA23037 for ; Fri, 10 Jan 2003 05:11:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18WwBx-000IU4-00 for multi6-data@psg.com; Fri, 10 Jan 2003 02:15:09 -0800 Received: from c2bapps1.btconnect.com ([193.113.209.21]) by psg.com with smtp (Exim 3.36 #2) id 18WwBv-000ITG-00 for multi6@ops.ietf.org; Fri, 10 Jan 2003 02:15:07 -0800 Received: from ati (actually host host62-7-122-229.in-addr.btopenworld.com) by c2bapps1 with SMTP-CUST (XT-PP) with ESMTP; Fri, 10 Jan 2003 10:14:03 +0000 Reply-To: From: "Christian de Larrinaga" To: "Ayyasamy, Senthilkumar \(UMKC-Student\)" , "Pekka Savola" , "Tony Li" Cc: "Paul Francis" , Subject: RE: recent slowdown in routing table growth Date: Fri, 10 Jan 2003 10:14:00 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01, USER_AGENT_OUTLOOK version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I put Geoff's presentation at the master lectures up at http://www.england.isoc.org/event/melectures.rhtm If there is anybody in London on evening of Thursday 16th Jan the UK IPv6 Task Force is holding a lecture night and reception see http://www.uk.ipv6tf.org for registration. > > > 1) raised awareness: this exponentially-looking growth raised some > > alarms, there was a presentation in IETF51 in London (Aug > > 2001), etc. -- > > (some) people fixed some of their systems. > > > Mainly 1), but I'd also like to get some more concrete references. > > > http://www.potaroo.net/papers/bgp/bgp-june02.pdf > http://www.packetdesign.net/docs/cengiz.pdf snip > One can check geoff huston BGP page for an up-to-date report. > Also, compare the above presentations with the previous IETF > ptomaine/plenary presentations. Christian From owner-multi6@ops.ietf.org Fri Jan 10 08:33: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 IAA27671 for ; Fri, 10 Jan 2003 08:33:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18WzJE-000LUn-00 for multi6-data@psg.com; Fri, 10 Jan 2003 05:34:52 -0800 Received: from host-40.homerun.telia.com ([194.23.29.40] helo=dhcp-168-17-67.autonomica.se) by psg.com with esmtp (Exim 3.36 #2) id 18WzJ7-000LUT-00 for multi6@ops.ietf.org; Fri, 10 Jan 2003 05:34:45 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp-168-17-67.autonomica.se (8.12.2/8.10.2) with ESMTP id h0ADZO5E022653; Fri, 10 Jan 2003 14:35:25 +0100 (CET) Date: Fri, 10 Jan 2003 14:09:45 +0100 Subject: Re: draft-kurtis-multihoming-longprefix comments 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: Kurt Erik Lindqvist In-Reply-To: <200301071518.h07FIHqs029150@ginger.lcs.mit.edu> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-2.9 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02, USER_AGENT_APPLEMAIL version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > First, once again, about "provider-independent addresses", AKA > "connectivity- > independent addresses". > > This is pretty much like asking for a street address that stays the > same even > when you move. [..] > Look, if you want some sort of identifier for machines, one that stays > the > same even when a machine moves somewhere else, the IPv4 architecture > simply > does not provide it. Frankly, it wasn't even guessed at as a > requirement, > back when the Internet had 18 total nets in it. To be honest I think you are not really mirroring the full story here. > IPv6 adopted the IPv4 architecture lock, stock, and barrel, changing > only the > length of the address. This is touted as its great strength - in fact, > it's > its greatest weakness, and we see an example here. Which is why we have this WG.... > *Don't* come ask for "location-indepedent street addresses". > I think that is one of the questions we have to ask. It might not be the answer, but we do need to ask the question. > >> Well, what I am looking for is a) Any idea of why people are doing >> this. We are again back to the problem that we should first understand >> what we are trying to solve before we start posting solutions. > > Oh, I think it's reasonably easy to understand why people want > identifiers > for their machines that stay the same even if they change providers. > They > want to make it easy (or at least easier) to change providers, and > prevent > lock-in. There is two sides to this a) Why do people multihome? b) Why do they want PI-like address space? What worries me is if people are doing a to get to b. I don't want to see these two being the same. > The only possible solution *in the architecture as it stands* is to > use DNS > names, if people need a location-independent host identifier. There is AFAIK no limit on this group to use the architecure as it stands. And I don't believe DNS is the only solution. - kurtis - From owner-multi6@ops.ietf.org Fri Jan 10 09:53: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 JAA29574 for ; Fri, 10 Jan 2003 09:53:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18X0XJ-000N8V-00 for multi6-data@psg.com; Fri, 10 Jan 2003 06:53:29 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 18X0XD-000N8F-00 for multi6@ops.ietf.org; Fri, 10 Jan 2003 06:53:24 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h0AEqmA20225; Fri, 10 Jan 2003 15:52:48 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Fri, 10 Jan 2003 15:52:48 +0100 (CET) From: Iljitsch van Beijnum To: Kurt Erik Lindqvist cc: Subject: Re: draft-kurtis-multihoming-longprefix comments In-Reply-To: Message-ID: <20030110152815.F11497-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.0 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_01_02 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Fri, 10 Jan 2003, Kurt Erik Lindqvist wrote: > There is two sides to this > a) Why do people multihome? > b) Why do they want PI-like address space? > What worries me is if people are doing a to get to b. I don't want to > see these two being the same. People multihome because it makes their connection to the net more reliable, because it is sometimes cheaper and because you get better performance if interconnection between ISPs isn't very good. People want PI space because that way changing ISPs is trivial. And even for people who don't want to multihome this is very important: if your ISP goes belly up, you want to be able to connect to a new one very quickly. In theory, renumbering isn't a big problem: you only need to change a DHCP configuration or some prefix advertisements. In practice, it is a nightmare because IP addresses show up in way too many places, often to enforce access restrictions. Getting rid of this is probably the hardest part in any multiple-address solution. So either we have portable addresses or we create a better way to do access restrictions. > > > The only possible solution *in the architecture as it stands* is to > > use DNS > > names, if people need a location-independent host identifier. > > There is AFAIK no limit on this group to use the architecure as it > stands. And I don't believe DNS is the only solution. > > > - kurtis - > > -- http://shameless-book-plug.bgpexpert.com/'BGP'-by-Iljitsch-van-Beijnum/ From owner-multi6@ops.ietf.org Fri Jan 10 13:43: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 NAA10751 for ; Fri, 10 Jan 2003 13:43:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18X48y-0003Dv-00 for multi6-data@psg.com; Fri, 10 Jan 2003 10:44:36 -0800 Received: from sj-msg-core-3.cisco.com ([171.70.157.152]) by psg.com with esmtp (Exim 3.36 #2) id 18X48u-0003Bo-00 for multi6@ops.ietf.org; Fri, 10 Jan 2003 10:44:33 -0800 Received: from cisco.com ([10.21.82.18]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id h0AIg5jS028694; Fri, 10 Jan 2003 10:42:06 -0800 (PST) Message-ID: <3E1F141F.30100@cisco.com> Date: Fri, 10 Jan 2003 10:42:39 -0800 From: Eliot Lear User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: alh-ietf@tndh.net CC: "'Brian E Carpenter'" , multi6@ops.ietf.org Subject: Re: draft-kurtis-multihoming-longprefix comments References: <063301c2b848$7f57c5d0$9f144104@eagleswings> In-Reply-To: <063301c2b848$7f57c5d0$9f144104@eagleswings> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-2.6 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_02_03, USER_AGENT,USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Tony Hain wrote: > Eliot Lear wrote: > >>Over time we still have DNS to allow for people to make >>changes. This >>means that one has to work the transition such that prefixes >>can change >>at the convenience of the end user. > > > My name does not change when I move or change cell providers, but it is > still painful and expensive to touch every place that has the name to > address mapping. Multiply that for larger enterprises, and the numbers > get big enough for budget watchers to notice. Your initial comment related to enterprises. Enterprises don't change providers all that often. But even if they did, we have the tools to readdress devices in IPv4 -- it's called DHCP. It could *even* be used in conjunction with mobile-ip, and not just for the FA. Thus, one uses one mechanism for mobility, another one for a stable identifier, and for that matter, perhaps a third for micromobility. This falls under the classification of "the right tool for the right job". > > Also, we already see a market for email redirection, where an email > address can stay consistent over ISP changes. Clearly some people don't > want to deal with changing the mappings from their name to the locator > info if they don't have to, and large enterprises do this all the time > by registering their own names rather than taking a subdomain from the > ISP. In any case, DNS is not the only place names are translated into > addresses, so we must not base an approach on the assumption that it is. Let's back up: user@pobox.com (for example) uses pobox.com as a place to have a stable identifier. This would be no different than user@userspersonaldomain.com except that it takes some amount of work to maintain a server. But even so the name remains the same. So long as userspersonaldomain.com can easily determine its address, and records can be updated by authorized individuals, life continues. This is possible. Ralph Droms has worked on functionality such as prefix delegation. Then, see above. Can you explain to me why systems that use translation other than DNS aren't broken and worth fixing? Eliot From owner-multi6@ops.ietf.org Fri Jan 10 20:25: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 UAA21978 for ; Fri, 10 Jan 2003 20:25:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18XAQp-000EuC-00 for multi6-data@psg.com; Fri, 10 Jan 2003 17:27:27 -0800 Received: from evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net ([4.65.20.139] helo=tndh.net) by psg.com with esmtp (Exim 3.36 #2) id 18XAQl-000EtR-00 for multi6@ops.ietf.org; Fri, 10 Jan 2003 17:27:23 -0800 Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Fri, 10 Jan 2003 17:27:20 -0800 Reply-To: From: "Tony Hain" To: "'Eliot Lear'" Cc: "'Brian E Carpenter'" , Subject: RE: draft-kurtis-multihoming-longprefix comments Date: Fri, 10 Jan 2003 17:26:32 -0800 Message-ID: <070101c2b910$79b05610$9f144104@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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <3E1F141F.30100@cisco.com> X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id UAA21978 Eliot Lear wrote: > ... > Your initial comment related to enterprises. Enterprises > don't change > providers all that often. 'Often' is a function of your perspective of time. Even if they don't meet your definition of often, they want the ability to move at a moments notice without the threat of a significant cost hanging over their heads. > But even if they did, we have the tools to > readdress devices in IPv4 -- it's called DHCP. It could > *even* be used > in conjunction with mobile-ip, and not just for the FA. > Thus, one uses > one mechanism for mobility, another one for a stable > identifier, and for > that matter, perhaps a third for micromobility. This falls under the > classification of "the right tool for the right job". Readdressing the nodes is not the problem. In IPv6 the RA allows a smoother version of doing that job, because it allows both old and new. The real problem is in finding all the places that addresses are explicitly stored. > ... > user@pobox.com (for example) uses pobox.com as a place to have a > stable identifier. This would be no different than > user@userspersonaldomain.com except that it takes some amount > of work to > maintain a server. The server is not the problem. This is due to the difference between a central vs. distributed database. The user can change user@pobox.com and it happens as quickly and as often as the user wants to change it. With a personal domain, the minimum usable time is measured in hours, and to be completely useful, we are talking a day or two (I have first hand experience here because Verizon changes my address a couple of times a year, and it takes a few hours after I get the dns updated before I can use the name). > But even so the name remains the same. So long as > userspersonaldomain.com can easily determine its address, and records > can be updated by authorized individuals, life continues. Eventually ... > This is > possible. Ralph Droms has worked on functionality such as prefix > delegation. Then, see above. > > Can you explain to me why systems that use translation other than DNS > aren't broken and worth fixing? Because it is DNS that is broken (read that not reliable and fast) and hasn't been fixed in 15 years. When people either can't register values in DNS (due to lack of a scalable trust infrastructure for access to the database), or their app can't reliably get answers back in the necessary timeframe, they choose to build their own explicit tables. One simple version of this is router acl's, another is SIP or multi-player game rendezvous points. DNS does not work for all applications, therefore DNS names can't be the solution for all multi-homing. From owner-multi6@ops.ietf.org Sun Jan 12 10:25: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 KAA10913 for ; Sun, 12 Jan 2003 10:25:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Xk2B-000780-00 for multi6-data@psg.com; Sun, 12 Jan 2003 07:28:23 -0800 Received: from pop-ls-09-1-dialup-170.freesurf.ch ([194.230.235.170] helo=dhcp-168-17-67.autonomica.se) by psg.com with esmtp (Exim 3.36 #2) id 18Xk27-00077o-00 for multi6@ops.ietf.org; Sun, 12 Jan 2003 07:28:20 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp-168-17-67.autonomica.se (8.12.2/8.10.2) with ESMTP id h0CFSf5E022783; Sun, 12 Jan 2003 16:28:52 +0100 (CET) Date: Fri, 10 Jan 2003 17:03:51 +0100 Subject: Re: draft-kurtis-multihoming-longprefix comments Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Pekka Savola , To: Iljitsch van Beijnum From: Kurt Erik Lindqvist In-Reply-To: <20030108000730.M11497-100000@sequoia.muada.com> Message-Id: <1CB41904-24B5-11D7-A551-000393AB1404@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-1.6 required=5.0 tests=DATE_IN_PAST_24_48,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_APPLEMAIL version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > (Think about it: 64 bits is enough to give every square millimeter of > earth surface an address.) Then think that is not that long ago the address efficiency usage was around 4% (I might remember this incorrect but I have a vague feeling we where around that at pre-CIDR). I think that the last figure I saw was at around 35-40%. It's still not that impressive, but also very hard to get much better (Without research in the field I would assume that 60% would be close to a practical/theoretical maximum limit (is there any research done in this field?). - kurtis - From owner-multi6@ops.ietf.org Sun Jan 12 10:25: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 KAA10916 for ; Sun, 12 Jan 2003 10:25:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Xjzv-00075j-00 for multi6-data@psg.com; Sun, 12 Jan 2003 07:26:03 -0800 Received: from pop-ls-09-1-dialup-170.freesurf.ch ([194.230.235.170] helo=dhcp-168-17-67.autonomica.se) by psg.com with esmtp (Exim 3.36 #2) id 18Xjzp-00075V-00 for multi6@ops.ietf.org; Sun, 12 Jan 2003 07:25:58 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp-168-17-67.autonomica.se (8.12.2/8.10.2) with ESMTP id h0CFQD5E022779; Sun, 12 Jan 2003 16:26:19 +0100 (CET) Date: Fri, 10 Jan 2003 16:59:35 +0100 Subject: Re: draft-kurtis-multihoming-longprefix comments Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "J. Noel Chiappa" , To: Iljitsch van Beijnum From: Kurt Erik Lindqvist In-Reply-To: <20030107230051.W11497-100000@sequoia.muada.com> Message-Id: <83974729-24B4-11D7-A551-000393AB1404@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-1.6 required=5.0 tests=DATE_IN_PAST_24_48,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_APPLEMAIL version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Now obviously in the real world interconnection between regions within > an ISP network is denser than between ISP networks within regions, but > regional interconnection is still dense enough to make it worth the > trouble. You are touching on one of the areas that makes me think twice about geo-aggregation and that is intra-operator routing and policy. It's not insolvable, and I will not make the claim that I understand this fully (on the contrary, I am just a hang-around..:) ), but it makes some of the night-mare set-ups I have seen so far look even worse. Then again, there is a lot out there that we need to clean up anyway.... > But in the mean time I'm working on a multiple address draft which is > of > course much cooler but upgrading all hosts in the world also has its > problems... > Well, as discussed in Atlanta, I don't think we will come down with a "one-solution-fit-all". Sorry. - kurtis - From owner-multi6@ops.ietf.org Sun Jan 12 10:26: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 KAA10943 for ; Sun, 12 Jan 2003 10:26:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Xk3N-0007AK-00 for multi6-data@psg.com; Sun, 12 Jan 2003 07:29:37 -0800 Received: from pop-ls-09-1-dialup-170.freesurf.ch ([194.230.235.170] helo=dhcp-168-17-67.autonomica.se) by psg.com with esmtp (Exim 3.36 #2) id 18Xk3K-0007A0-00 for multi6@ops.ietf.org; Sun, 12 Jan 2003 07:29:35 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp-168-17-67.autonomica.se (8.12.2/8.10.2) with ESMTP id h0CFUM5E022786 for ; Sun, 12 Jan 2003 16:30:25 +0100 (CET) Date: Fri, 10 Jan 2003 17:09:23 +0100 Mime-Version: 1.0 (Apple Message framework v551) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: Really about draft-kurtis-multihoming-longprefix-00.txt From: Kurt Erik Lindqvist To: multi6@ops.ietf.org Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=0.0 required=5.0 tests=DATE_IN_PAST_24_48,SPAM_PHRASE_00_01,USER_AGENT_APPLEMAIL version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Just a note that I today _really_ submitted the above draft as a individual contribution to the editor. I hope it will show soon. I fixed all grammar and spelling errors (and some other issues) in the draft and hope it will be available soon. I also updated the http:/www.kurtis.pp.se/ietf/draft-kurtis-multihoming-longprefix-00.txt file. - kurtis - PS The road-map discussed in Atlanta should also be done shortly. From owner-multi6@ops.ietf.org Sun Jan 12 10:33: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 KAA11160 for ; Sun, 12 Jan 2003 10:33:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18XkA8-0007L5-00 for multi6-data@psg.com; Sun, 12 Jan 2003 07:36:36 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 18XkA6-0007Km-00 for multi6@ops.ietf.org; Sun, 12 Jan 2003 07:36:34 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h0CFa0126229; Sun, 12 Jan 2003 16:36:00 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Sun, 12 Jan 2003 16:36:00 +0100 (CET) From: Iljitsch van Beijnum To: Kurt Erik Lindqvist cc: Subject: Re: draft-kurtis-multihoming-longprefix comments In-Reply-To: <83974729-24B4-11D7-A551-000393AB1404@kurtis.pp.se> Message-ID: <20030112163351.B11497-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.4 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Fri, 10 Jan 2003, Kurt Erik Lindqvist wrote: > > Now obviously in the real world interconnection between regions within > > an ISP network is denser than between ISP networks within regions, but > > regional interconnection is still dense enough to make it worth the > > trouble. > You are touching on one of the areas that makes me think twice about > geo-aggregation and that is intra-operator routing and policy. Read the draft, this issue is addressed and should not be a problem. Iljitsch From owner-multi6@ops.ietf.org Sun Jan 12 10:36: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 KAA11212 for ; Sun, 12 Jan 2003 10:36:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18XkD7-0007Pf-00 for multi6-data@psg.com; Sun, 12 Jan 2003 07:39:41 -0800 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 18XkD4-0007PR-00 for multi6@ops.ietf.org; Sun, 12 Jan 2003 07:39:39 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h0CFdYh09368; Sun, 12 Jan 2003 17:39:34 +0200 Date: Sun, 12 Jan 2003 17:39:34 +0200 (EET) From: Pekka Savola To: Kurt Erik Lindqvist cc: multi6@ops.ietf.org Subject: Re: Really about draft-kurtis-multihoming-longprefix-00.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Fri, 10 Jan 2003, Kurt Erik Lindqvist wrote: > Just a note that I today _really_ submitted the above draft as a > individual contribution to the editor. I hope it will show soon. I > fixed all grammar and spelling errors (and some other issues) in the > draft and hope it will be available soon. I also updated the > http:/www.kurtis.pp.se/ietf/draft-kurtis-multihoming-longprefix-00.txt > file. Are you sure? Wdiff shows this, the version in the I-D directory and the first version identical.. Or maybe I missed something.. -- 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 Sun Jan 12 16:43: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 QAA15228 for ; Sun, 12 Jan 2003 16:43:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18XpuK-000HLn-00 for multi6-data@psg.com; Sun, 12 Jan 2003 13:44:40 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 18XpuH-000HLa-00 for multi6@ops.ietf.org; Sun, 12 Jan 2003 13:44:38 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h0CLi7n26548 for ; Sun, 12 Jan 2003 22:44:07 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Sun, 12 Jan 2003 22:44:07 +0100 (CET) From: Iljitsch van Beijnum To: Subject: Multiaddress multihoming Message-ID: <20030112163603.W11497-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.5 required=5.0 tests=SPAM_PHRASE_01_02 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk As I mentioned, I've been working on a draft for multiaddress multihoming in IPv6. The problem I'm having is that most of what I'm writing down is either too much detail or too obvious. The whole thing is just too big. So I want to focus on the more practical aspects, but I'm afraid the tradeoffs there will seem arbitrary without explaining the big picture first. So that's what I want to do in this message. Feedback is appreciated. The basic idea is to apply logic similar to the end-to-end principle to multihoming: if we can do it in the end hosts, don't impose any changes on the network layer as this only makes the whole thing harder to deploy. The next step is to separate the locator and identifier functions. In order to keep our options open, we shouldn't pick a single identifier namespace, but rather accept any arbitrary variable-length binary value as an identifier. The identifier/namespace type must be explicitly identified inside protocols to be able to represent it using the right conventions, to be able to perform identifier to locator mapping in the right way, to avoid collisions and to make special handling of certain identifier types possible. The TCP or UDP checksum is calculated over the identifiers, the transport protocol header and user data. A new API is provided that makes it possible for applications to provide the transport protocol with just an identifier, and the transport protocol looks up an initial set of locators. The preferred identifier type at this time would be the fully qualified domain name. FQDNs are already in wide use and there is a well-understood mapping mechanism for this type of identifier to locators already in place: the DNS. The new identifiers and the full set of locators for each end would not be be carried in each packet, but rather be negotiated prior to the exchange of data. Since this negotiation mechanism is common to different transport protocols, it should be a separate protocol. Also, it makes sense to make this a general negotiation mechanism that can negotiate additional information, such as the use of additional authentication that can replace the basic level of security prevously provided by return routability. So far so good, with plenty of work to do, for instance in the area of security, but this should all be relatively straightforward. Backward compatibility. In order for unmodified applications that use the IPv4 or IPv6 socket API to work with this scheme, calls to these APIs are intercepted. The IPv4 or IPv6 address is turned into a hostname, that is subsequently used as an identifier. (Presumably, using the .in-addr.arpa domain.) Additional compatibility to existing implementations can be gained by using the 4 or 16 byte IP address values as identifiers. Then regular TCP or UDP over IPv4 or IPv6 can be used without any real changes, by adding layers on top and underneath these protocols: the layer on top does the negotiation and the layer underneath replaces the IP addresses used as locators by the ones used as identifies, possibly switching IP versions at the same time. Hosts with unmodified IPv4 or IPv6 stacks can use this multihoming mechanism by offloading the necessary processing to a proxy. The proxy presents itself as a router to the host. When the host transmits packets, the proxy intercepts then and looks up their destination address in the DNS to determine whether the destination is multihomed. If not, the packet is forwarded as usual and a cache entry is created that enables to proxy to forward subsequent packets immediately. If the destination is multihomed, the proxy goes through the negotiation cycle. The original IP header is then stripped from the packet, and a new one containing a set of source and destination locators that was negotiated is added, and the packet is forwarded. No transport layer information is changed. The reverse is done for packets received from the multihomed destination network. The proxy monitors the flow of traffic to determine when a source/destination locator pair stops working so it can switch to another pair. Incoming sessions work the same way, except that the other end initiates the negotiation phase with the proxy. Iljitsch van Beijnum From owner-multi6@ops.ietf.org Mon Jan 13 02:46: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 CAA03653 for ; Mon, 13 Jan 2003 02:46:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18XzK6-000Flm-00 for multi6-data@psg.com; Sun, 12 Jan 2003 23:47:54 -0800 Received: from tlp1.cobweb.autonomica.se ([130.244.10.138] helo=dhcp-168-17-67.autonomica.se) by psg.com with esmtp (Exim 3.36 #2) id 18XzK4-000FlZ-00 for multi6@ops.ietf.org; Sun, 12 Jan 2003 23:47:52 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp-168-17-67.autonomica.se (8.12.2/8.10.2) with ESMTP id h0D7me5E022866; Mon, 13 Jan 2003 08:48:42 +0100 (CET) Date: Fri, 10 Jan 2003 17:13:07 +0100 Subject: Re: draft-kurtis-multihoming-longprefix comments Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "'J. Noel Chiappa'" , To: From: Kurt Erik Lindqvist In-Reply-To: <044101c2b6ad$94d61250$9f144104@eagleswings> Message-Id: <67C51E21-24B6-11D7-A551-000393AB1404@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-1.2 required=5.0 tests=DATE_IN_PAST_48_96,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_APPLEMAIL version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > This is where the analogy breaks down ... I had though more about it > after sending the earlier note, and realized this would come up. The > copper/fiber doesn't change from the site perspective. More below: > >> from that computer to *different place* on the network - to >> the infrastructure of provider Y. **That host has, from the >> point of view of the rest of the network, moved to a new >> location on the network**. >> > > The street analogy would express this as the choice of direction at the > stop sign (end of the consistent copper/fiber loop). Using the > different > attachment point as a different address model, I would have a different > service address when turning left, than turning right or going > straight. > While I might give different instructions to those coming toward me > from > each of those directions, the actual address doesn't change. > To be completely honest - making a analogy between street names and IP addresses doesn't cut it all IMHO. We are close to apple and orange comparison. You can always make one of them superior to the other depending on your personal preference. Best regards, - kurtis - From owner-multi6@ops.ietf.org Mon Jan 13 02:46: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 CAA03670 for ; Mon, 13 Jan 2003 02:46:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18XzKC-000Fm6-00 for multi6-data@psg.com; Sun, 12 Jan 2003 23:48:00 -0800 Received: from tlp1.cobweb.autonomica.se ([130.244.10.138] helo=dhcp-168-17-67.autonomica.se) by psg.com with esmtp (Exim 3.36 #2) id 18XzKA-000Flo-00 for multi6@ops.ietf.org; Sun, 12 Jan 2003 23:47:58 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp-168-17-67.autonomica.se (8.12.2/8.10.2) with ESMTP id h0D7mq5E022886; Mon, 13 Jan 2003 08:48:52 +0100 (CET) Date: Sun, 12 Jan 2003 20:15:38 +0100 Subject: Re: draft-kurtis-multihoming-longprefix comments Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: To: Iljitsch van Beijnum From: Kurt Erik Lindqvist In-Reply-To: <20030110152815.F11497-100000@sequoia.muada.com> Message-Id: <3BABFA79-2662-11D7-A551-000393AB1404@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-2.1 required=5.0 tests=DATE_IN_PAST_12_24,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_03_05,USER_AGENT_APPLEMAIL version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> There is two sides to this > >> a) Why do people multihome? >> b) Why do they want PI-like address space? > >> What worries me is if people are doing a to get to b. I don't want to >> see these two being the same. > > People multihome because it makes their connection to the net more > reliable, because it is sometimes cheaper and because you get better > performance if interconnection between ISPs isn't very good. > > People want PI space because that way changing ISPs is trivial. And > even > for people who don't want to multihome this is very important: if your > ISP goes belly up, you want to be able to connect to a new one very > quickly. Well, this is what I intuitively would say as well. However, there is (as you yourself noted in an earlier email) not that many people that multihome. There are a lot more that get PI space. I am still doubtful that we understand the issue. I am leaning to the conclusion that what you want depend on what you are. And each will require a different solution. In principle, a "advanced" DSL home user want to multihome for price. Here are multiple address solution might be the right answer. If I am a SOHO, I am probably also after cost benefits. If I am a on-line broker I am probably after resilience, and a routing solution might be what I want. If I am IBM, I will fall under any provider category. I think something that is very important to keep in mind is what Tony Li said, we need to get away from the model where when a user want's to multihome he will add a entry in the DFZ. The question is, does that apply for everyone and do we think we can get there in one single large evolutionary step? I think we need to get there; we will get there; but we will have to do it bit by bit. > In theory, renumbering isn't a big problem: you only need to change a > DHCP configuration or some prefix advertisements. In practice, it is a > nightmare because IP addresses show up in way too many places, often to > enforce access restrictions. Getting rid of this is probably the > hardest > part in any multiple-address solution. I know of some really large re-numberings. I think most of the time, people are making a larger fuss of this than it is. Best regards, - kurtis - From owner-multi6@ops.ietf.org Mon Jan 13 17:08: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 RAA25946 for ; Mon, 13 Jan 2003 17:08:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18YClr-000GkZ-00 for multi6-data@psg.com; Mon, 13 Jan 2003 14:09:27 -0800 Received: from pcp744791pcs.reston01.va.comcast.net ([68.49.138.160] helo=mail.krioukov.net) by psg.com with esmtp (Exim 3.36 #2) id 18YClm-000Ggo-00 for multi6@ops.ietf.org; Mon, 13 Jan 2003 14:09:23 -0800 Received: from DIMA1 (dhcp-host-017.pcp744791pcs.reston01.va.comcast.net [192.168.1.17]) by mail.krioukov.net (8.9.3/8.9.3) with SMTP id RAA32082; Mon, 13 Jan 2003 17:08:50 -0500 From: "Dmitri Krioukov" To: "Tony Li" Cc: Subject: RE: draft-kurtis-multihoming-longprefix comments Date: Mon, 13 Jan 2003 17:08:48 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-Spam-Status: No, hits=1.2 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_RFCI,SPAM_PHRASE_01_02, USER_AGENT_OUTLOOK version=2.43 X-Spam-Level: * Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit There is this obvious thought that there might be some theoretical results already obtained showing that no change within model X would solve problem Y since what we perceive as problem Y is in fact a theorem in X. In other words, Y is just caused by X. As the first step, there might be some lower bounds for local memory requirements of routing schemes with specific stretch factors... -- dima. > -----Original Message----- > From: owner-multi6@ops.ietf.org [mailto:owner-multi6@ops.ietf.org]On > Behalf Of Tony Li > Sent: Tuesday, January 07, 2003 4:41 PM > To: Iljitsch van Beijnum > Cc: multi6@ops.ietf.org > Subject: RE: draft-kurtis-multihoming-longprefix comments > > > > > | > The current routing technology does NOT scale properly. > | There is not > | > going to be any intermeidate approach based on the > | current technology > | > that will scale. > | > | Now I have to go and disagree with you there. > | > | With a reasonable level of aggregation current technology will scale > | just fine. > | > | Aggregation is simply a means to divide the routing > | information over the > | routers so that a single router doesn't have to hold all possible > | routes. Today, if routers are owned by the same owner, they hold the > | same routing information. Maybe it's time we try > | aggregating based on > | something else than router ownership. > > > The current architecture has no incentive for end user sites to want > to be aggregated and without that, the architecture is bound to fail. > Right now, we have two large incentives not to aggregate: multihoming and > more-specifics for traffc engineering. > > We need to change something, moving forward. > > Tony From owner-multi6@ops.ietf.org Mon Jan 27 01:29: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 BAA28208 for ; Mon, 27 Jan 2003 01:29:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18d2kO-0002rh-00 for multi6-data@psg.com; Sun, 26 Jan 2003 22:27:56 -0800 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 18d2kL-0002q8-00 for multi6@ops.ietf.org; Sun, 26 Jan 2003 22:27:54 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h0R6RZr11787; Mon, 27 Jan 2003 08:27:35 +0200 Date: Mon, 27 Jan 2003 08:27:34 +0200 (EET) From: Pekka Savola To: Margaret Wasserman cc: Erik Nordmark , Keith Moore , , , Subject: renumbering/multi-addressing [Re: Enforcing unreachability of site local addresses] In-Reply-To: <5.1.0.14.2.20030126070456.03451d80@mail.windriver.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_02_03,USER_AGENT_PINE version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Hello, I added multi6 on Cc: list for this particular piece of the thread. On Sun, 26 Jan 2003, Margaret Wasserman wrote: [...] > Some folks have argued that easy renumbering would eliminate the need > for enterprises to have provider-independent addressing, but I don't > agree. Addresses are stored in many places in the network besides > the interfaces of routers and hosts, such as access control lists, > configuration files, .hosts files, DNS configurations, ACL lists, etc. > In many cases, addresses are stored in nodes on other subnets. So, > being able to renumber the interfaces of hosts and routers on a > particular network or subnet doesn't even solve half of the problem. There are multiple reasons why people want PI addresses. Renumbering and multi-addressing has multiple different models. Some are easy and some are very difficult. We should develop at least the _easy_ solutions because they are probably useful too. For now, it's enough to manage the first 80% of the problem. Consider four reasons why people might want PI, routable addresses: - "I don't want to be in problems if my ISP goes bankrupt!" ==> multiple addresses are just fine here (deploy them before the ISP goes down, but use only one set of them etc.) - "I want to be able to change ISP's at will reasonably easily, to keep an edge" ==> multiple addresses are fine here too! - "I want to be able to protect against failures in my link(s) to my ISP and problems in our router(s)" ==> multiple addresses can deal with that too, with some added glue! - "I want to be able to protect against failures in my upstream ISP" ==> tough cookie, no solution here! Get the picture? Greedy folks want it all, but actually we _can_ provide quite a bit of it already! > Choices seem to be: > > (A) Continue with PA addressing, and accept that enterprises will > use IPv6 NAT to get provider-independence. > (B) Allocate PI addresses, and trust that we can determine a > scalable PI routing scheme before we hit route scaling > issues in the IPv6 backbone. I don't comment on these except that you seem to be making some conclusions I don't agree on. I don't think PA equals IPv6 NAT, not at all. There are solutions there. -- 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 Jan 27 14: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 OAA23387 for ; Mon, 27 Jan 2003 14:19:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18dEno-0004LG-00 for multi6-data@psg.com; Mon, 27 Jan 2003 11:20:16 -0800 Received: from roam.psg.com ([147.28.4.2]) by psg.com with esmtp (Exim 3.36 #1) id 18dEnj-0004L4-00 for multi6@ops.ietf.org; Mon, 27 Jan 2003 11:20:12 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.12) id 18dEnh-0000vq-00 for multi6@ops.ietf.org; Mon, 27 Jan 2003 11:20:09 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15925.34034.121425.300757@thomasm-u1.cisco.com> In-Reply-To: References: <5.1.0.14.2.20030126070456.03451d80@mail.windriver.com> From: Michael Thomas Date: Mon, 27 Jan 2003 11:13:54 -0800 (PST) To: Pekka Savola Cc: Margaret Wasserman , Erik Nordmark , Keith Moore , , Subject: renumbering/multi-addressing [Re: Enforcing unreachability of site local addresses] X-Spam-Status: No, hits=-0.4 required=5.0 tests=IN_REP_TO,REFERENCES,RESENT_TO,SPAM_PHRASE_03_05 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] Pekka, It seems to me that you left out the most nettlesome problem about why people want address stability: name mappings, both in the form of DNS and everywhere else you find raw IP addresses floating around. In many ways, this mimics the Y2K problem in that it's very hard to gauge _what_ exactly might break until you do a complete assessment. And the complete assessment is enough to scare the timid woodland creatures away. Until there's a realistic way for people to pull the lever and make a switch, there's going to be a lot of back pressure to keep address stablity regardless of how harmful their means of keeping stablity is to the net at large. Mike Pekka Savola writes: > Hello, > > I added multi6 on Cc: list for this particular piece of the thread. > > On Sun, 26 Jan 2003, Margaret Wasserman wrote: > [...] > > Some folks have argued that easy renumbering would eliminate the need > > for enterprises to have provider-independent addressing, but I don't > > agree. Addresses are stored in many places in the network besides > > the interfaces of routers and hosts, such as access control lists, > > configuration files, .hosts files, DNS configurations, ACL lists, etc. > > In many cases, addresses are stored in nodes on other subnets. So, > > being able to renumber the interfaces of hosts and routers on a > > particular network or subnet doesn't even solve half of the problem. > > There are multiple reasons why people want PI addresses. Renumbering and > multi-addressing has multiple different models. Some are easy and some > are very difficult. We should develop at least the _easy_ solutions > because they are probably useful too. For now, it's enough to manage the > first 80% of the problem. > > Consider four reasons why people might want PI, routable addresses: > > - "I don't want to be in problems if my ISP goes bankrupt!" > ==> multiple addresses are just fine here (deploy them before the ISP > goes down, but use only one set of them etc.) > > - "I want to be able to change ISP's at will reasonably easily, to keep an > edge" > ==> multiple addresses are fine here too! > > - "I want to be able to protect against failures in my link(s) to my ISP > and problems in our router(s)" > ==> multiple addresses can deal with that too, with some added glue! > > - "I want to be able to protect against failures in my upstream ISP" > ==> tough cookie, no solution here! > > Get the picture? Greedy folks want it all, but actually we _can_ provide > quite a bit of it already! > > > Choices seem to be: > > > > (A) Continue with PA addressing, and accept that enterprises will > > use IPv6 NAT to get provider-independence. > > (B) Allocate PI addresses, and trust that we can determine a > > scalable PI routing scheme before we hit route scaling > > issues in the IPv6 backbone. > > I don't comment on these except that you seem to be making some > conclusions I don't agree on. I don't think PA equals IPv6 NAT, not at > all. There are solutions there. > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- From owner-multi6@ops.ietf.org Thu Jan 30 05:58: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 FAA24091 for ; Thu, 30 Jan 2003 05:58:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18eCP6-00031z-00 for multi6-data@psg.com; Thu, 30 Jan 2003 02:58:44 -0800 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 18eCP2-00031B-00 for multi6@ops.ietf.org; Thu, 30 Jan 2003 02:58:41 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h0UAwbk15666 for ; Thu, 30 Jan 2003 12:58:37 +0200 Date: Thu, 30 Jan 2003 12:58:36 +0200 (EET) From: Pekka Savola To: multi6@ops.ietf.org Subject: Draft: PI addressing derived from AS numbers Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-0.4 required=5.0 tests=SIGNATURE_SHORT_DENSE,SPAM_PHRASE_01_02,USER_AGENT_PINE version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Hello, I've sent a short draft (7 pages) to Internet-Drafts for publication. I propose an automatic allocation of /48, /40 or /32 (based on how the community feels) of PI addresses if you have an AS number. A 16-bit AS number in the range 1 - 2^15, that is. This is just to enable IPv6 multihoming temporarily, until another mechanism is devised, to those end-sites that already do it today. This is kind of a "stop those lame excuses now, please" -solution. Note: personally, I think ASN-PI like this is not a good idea, but it's at least better than some others, like breaking aggregates or doing stuff like that -- this is controlled, after a fashion. Until publication, it's available at: http://www.netcore.fi/pekkas/ietf/draft-savola-multi6-asn-pi-00.txt And the abstract is: In IPv6, the current IPv4 site multihoming practises have been operationally disabled, to prevent a creation of an unmanageable swamp of more specific routes. Some argue that the lack of a comprehensive site multihoming solution is hindering the deployment of IPv6. This memo presents a few proposals for end-sites with autonomous system (AS) number to be able to derive a provider independent block of addresses from the first half of the 16-bit AS- number space. This could enable a temporary IPv6 site multihoming solution for those that already employ similar mechanisms in IPv4. -- 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 Jan 30 11:25: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 LAA02976 for ; Thu, 30 Jan 2003 11:25:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18eHWh-000BSp-00 for multi6-data@psg.com; Thu, 30 Jan 2003 08:26:55 -0800 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 18eHWe-000BSd-00 for multi6@ops.ietf.org; Thu, 30 Jan 2003 08:26:52 -0800 Subject: RE: Draft: PI addressing derived from AS numbers Date: Thu, 30 Jan 2003 08:26:52 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <963621801C6D3E4A9CF454A1972AE8F54B89@server2000.arneill-py.sacramento.ca.us> Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Thread-Topic: Draft: PI addressing derived from AS numbers Thread-Index: AcLIUAdBFj23PScCRQitSGnkBUuD0wAJ325g From: "Michel Py" To: "Pekka Savola" , , "Iljitsch van Beijnum" X-Spam-Status: No, hits=0.8 required=5.0 tests=SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA02976 Pekka, This is an interesting draft, thanks for submitting. I do like the fact that it does indeed try to limit the number of prefixes announced but I think it's a terrible idea at the moment, though. This would create a terrible precedent. In the long run, we can expect: - People that have swamp space lobbying for v6 PI also, on the grounds that if people that have an ASN get v6 PI space they should get it too. Actually, swamp space holders have on paper a better reason than ASN holders to get v6 PI space. - AS numbers being extended to 32 bits. Then people that get ASNs above 64k will also strongly lobby to get PI on the grounds that it's not fair that early adopters only get it. If we had no other choice, I would support this as being not as bad as unrestricted PI. But it's still unaggregatable, and we do have a better choice: GAPI. If we come to the point where the community decides that indeed the deployment of IPv6 is being hindered by the lack of a solution (and we're not there yet), we could then discuss about adding a clause to GAPI that limits the initial allocations to organizations that already have an ASN. Michel. --------------------------------------------- From: Pekka Savola [mailto:pekkas@netcore.fi] Hello, I've sent a short draft (7 pages) to Internet-Drafts for publication. I propose an automatic allocation of /48, /40 or /32 (based on how the community feels) of PI addresses if you have an AS number. A 16-bit AS number in the range 1 - 2^15, that is. This is just to enable IPv6 multihoming temporarily, until another mechanism is devised, to those end-sites that already do it today. This is kind of a "stop those lame excuses now, please" -solution. Note: personally, I think ASN-PI like this is not a good idea, but it's at least better than some others, like breaking aggregates or doing stuff like that -- this is controlled, after a fashion. Until publication, it's available at: http://www.netcore.fi/pekkas/ietf/draft-savola-multi6-asn-pi-00.txt And the abstract is: In IPv6, the current IPv4 site multihoming practises have been operationally disabled, to prevent a creation of an unmanageable swamp of more specific routes. Some argue that the lack of a comprehensive site multihoming solution is hindering the deployment of IPv6. This memo presents a few proposals for end-sites with autonomous system (AS) number to be able to derive a provider independent block of addresses from the first half of the 16-bit AS- number space. This could enable a temporary IPv6 site multihoming solution for those that already employ similar mechanisms in IPv4. From owner-multi6@ops.ietf.org Thu Jan 30 14:14: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 OAA07647 for ; Thu, 30 Jan 2003 14:14:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18eK9g-000GPE-00 for multi6-data@psg.com; Thu, 30 Jan 2003 11:15:20 -0800 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 18eK9a-000GOy-00 for multi6@ops.ietf.org; Thu, 30 Jan 2003 11:15:15 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h0UJF8x19083; Thu, 30 Jan 2003 21:15:08 +0200 Date: Thu, 30 Jan 2003 21:15:08 +0200 (EET) From: Pekka Savola To: Michel Py cc: multi6@ops.ietf.org, Iljitsch van Beijnum Subject: RE: Draft: PI addressing derived from AS numbers In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F54B89@server2000.arneill-py.sacramento.ca.us> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk To re-iterate (for all the w.g.), I don't like the approach myself, but I fail to see good alternatives, _if_ something that works out has to be pushed out soon. If there's no such need, fine. Btw, in a private comment a few bad typographical errors were pointed out to me, so I updated the draft about 2 hours after I sent the message here. On Thu, 30 Jan 2003, Michel Py wrote: > This would create a terrible precedent. In the long run, we can expect: > - People that have swamp space lobbying for v6 PI also, on the grounds > that if people that have an ASN get v6 PI space they should get it too. > Actually, swamp space holders have on paper a better reason than ASN > holders to get v6 PI space. Uhh, what do you mean by swamp space holders, those that don't have ASN? Multihomers that use private ASN's or static routing and have their primary ISP advertise a more specific? > - AS numbers being extended to 32 bits. If I have any say, I wouldn't extend AS number space at all, but I guess that's another issue.. instead of making policy people try to solve a problem with technology. A bad mix. Perhaps some serious time for IAB/IESG architectureal guidance. But I digress... > Then people that get ASNs above > 64k will also strongly lobby to get PI on the grounds that it's not fair > that early adopters only get it. I agree, but when that happens (3+ years), I'm hoping there are already some mechanism(s) to do at least some multihoming. The main point with the mechanism is that I don't see it likely that new, really significant, big enterprises just crop up with a timescale of 3-5+ years and _require_ this kind of mechanism. (As could be argued by many enterprises of 10,000+ employees, today.) > If we had no other choice, I would support this as being not as bad as > unrestricted PI. But it's still unaggregatable, and we do have a better > choice: GAPI. GAPI is a new term to me. I assume this means Geographically Aggregated PI. That kind of proposals have some really bad drawbacks, and I'm having difficulties imagining those ideas materializing. > If we come to the point where the community decides that indeed the > deployment of IPv6 is being hindered by the lack of a solution (and > we're not there yet), [...] Well, maybe it is hindered, at least on paper. Some just make lame excuses for not getting into IPv6. For some, these problems are real, of course, but hardly something to delay IPv6 migration.. -- 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 Jan 30 22:04: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 WAA16921 for ; Thu, 30 Jan 2003 22:04:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18eRUc-000BM5-00 for multi6-data@psg.com; Thu, 30 Jan 2003 19:05:26 -0800 Received: from sj-msg-core-3.cisco.com ([171.70.157.152]) by psg.com with esmtp (Exim 3.36 #1) id 18eRUb-000BLs-00 for multi6@ops.ietf.org; Thu, 30 Jan 2003 19:05:25 -0800 Received: from cisco.com ([10.21.81.195]) by sj-msg-core-3.cisco.com (8.12.2/8.12.6) with ESMTP id h0V34sB6028415; Thu, 30 Jan 2003 19:04:55 -0800 (PST) Message-ID: <3E39E7DA.6050606@cisco.com> Date: Thu, 30 Jan 2003 19:04:58 -0800 From: Eliot Lear User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola CC: Michel Py , multi6@ops.ietf.org, Iljitsch van Beijnum Subject: Re: Draft: PI addressing derived from AS numbers References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-1.8 required=5.0 tests=IN_REP_TO,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Ultimately the same (or very similar) routing decision process will occur, with the same complexity and the same problems, so I would agree with you assessments. Thus, while I understand the reasoning for the proposal, I would argue that perhaps the best thing to do is nothing until we have something better. That may be a while. Oh well... But thanks.. Eliot From owner-multi6@ops.ietf.org Thu Jan 30 22: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 WAA17261 for ; Thu, 30 Jan 2003 22:37:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18eS1E-000D7q-00 for multi6-data@psg.com; Thu, 30 Jan 2003 19:39:08 -0800 Received: from jazz-1.trumpet.com.au ([203.5.119.62]) by psg.com with esmtp (Exim 3.36 #1) id 18eS1C-000D7Z-00 for multi6@ops.ietf.org; Thu, 30 Jan 2003 19:39:06 -0800 Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id OAA10223; Fri, 31 Jan 2003 14:38:46 +1100 (EST) Date: Fri, 31 Jan 2003 14:38:45 +1100 (EST) From: Peter Tattam To: Eliot Lear cc: Pekka Savola , Michel Py , multi6@ops.ietf.org, Iljitsch van Beijnum Subject: Re: Draft: PI addressing derived from AS numbers In-Reply-To: <3E39E7DA.6050606@cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.0 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk I will be working to progress my recent work to draft stage over the next few months. I have reason to beleive it will offer the flexibilit yof BG and PI space without impacting the current routing infrastructure. I would suggest holding off on such an interim solution as you are suggesting it will be a step backwards, not forwards. I agree that doing nothing is better than this proposal. Peter On Thu, 30 Jan 2003, Eliot Lear wrote: > Ultimately the same (or very similar) routing decision process will > occur, with the same complexity and the same problems, so I would agree > with you assessments. Thus, while I understand the reasoning for the > proposal, I would argue that perhaps the best thing to do is nothing > until we have something better. That may be a while. Oh well... > > But thanks.. > > Eliot > > > -- 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 Thu Jan 30 23:00: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 XAA17701 for ; Thu, 30 Jan 2003 23:00:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18eSOp-000EWp-00 for multi6-data@psg.com; Thu, 30 Jan 2003 20:03:31 -0800 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 18eSOn-000EWa-00 for multi6@ops.ietf.org; Thu, 30 Jan 2003 20:03:29 -0800 Subject: RE: Draft: PI addressing derived from AS numbers Date: Thu, 30 Jan 2003 20:03:28 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <963621801C6D3E4A9CF454A1972AE8F54B8C@server2000.arneill-py.sacramento.ca.us> Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Thread-Topic: Draft: PI addressing derived from AS numbers Thread-Index: AcLI1ZBwPr1vqmGHTVGa3S6nIKLjsQABIUcw From: "Michel Py" To: "Eliot Lear" , "Pekka Savola" Cc: , "Iljitsch van Beijnum" X-Spam-Status: No, hits=-0.3 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA17701 > Eliot Lear wrote: > Ultimately the same (or very similar) routing decision process > will occur, with the same complexity and the same problems, so > I would agree with you assessments. Thus, while I understand > the reasoning for the proposal, I would argue that perhaps the > best thing to do is nothing until we have something better. > That may be a while. Oh well... I concur with this. Pekka, your draft is clever. I'm not sure I can express correctly my feelings about it, but I'll try. It is a valuable contribution and I strongly encourage you to keep making such contributions. You deserve credit for it. I will fight it not because it's bad (it's not) but because the timing is not right. Your draft amounts to admitting that we collectively failed to deliver a multihoming solution for IPv6. The time to make this call has not come yet. Michel. From owner-multi6@ops.ietf.org Thu Jan 30 23:32: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 XAA18464 for ; Thu, 30 Jan 2003 23:32:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18eStO-000GHf-00 for multi6-data@psg.com; Thu, 30 Jan 2003 20:35:06 -0800 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 18eStL-000GGw-00 for multi6@ops.ietf.org; Thu, 30 Jan 2003 20:35:03 -0800 Subject: RE: Draft: PI addressing derived from AS numbers Date: Thu, 30 Jan 2003 20:35:01 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <963621801C6D3E4A9CF454A1972AE8F54B8E@server2000.arneill-py.sacramento.ca.us> Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Thread-Topic: Draft: PI addressing derived from AS numbers Thread-Index: AcLIk+jn29KCwmb7TW2/gq8BCCOAUgATGxIg From: "Michel Py" To: "Pekka Savola" Cc: , "Iljitsch van Beijnum" X-Spam-Status: No, hits=0.0 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA18464 Pekka, >> Michel Py wrote: >> This would create a terrible precedent. In the long run, we can >> expect: >> - People that have swamp space lobbying for v6 PI also, on the >> grounds that if people that have an ASN get v6 PI space they >> should get it too. Actually, swamp space holders have on paper >> a better reason than ASN holders to get v6 PI space. > Pekka Savola wrote: > Uhh, what do you mean by swamp space holders, those that don't > have ASN? Multihomers that use private ASN's or static routing > and have their primary ISP advertise a more specific? Someone please debunk me if I'm wrong, but I think that swamp space was allocated without the current restrictions of either having a distinct routing policy or being multihomed. This means that they are a few guys that still have swamp space (a class C, for the most part) and don't have an AS. These guys are not multihomed, they just have their ISP announce their swamp prefix and have the luxury of switching ISPs without renumbering, which is exactly what PI is about: one _OWNS_ the address. > GAPI is a new term to me. http://www.ietf.org/internet-drafts/draft-py-multi6-gapi-00.txt Beta allocation: http://arneill-py.sacramento.ca.us/ipv6mh/geov6.txt Michel. From owner-multi6@ops.ietf.org Fri Jan 31 02:17: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 CAA00634 for ; Fri, 31 Jan 2003 02:17:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18eVSj-000PXo-00 for multi6-data@psg.com; Thu, 30 Jan 2003 23:19:45 -0800 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 18eVSf-000PXb-00 for multi6@ops.ietf.org; Thu, 30 Jan 2003 23:19:42 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h0V7JQL23294; Fri, 31 Jan 2003 09:19:26 +0200 Date: Fri, 31 Jan 2003 09:19:26 +0200 (EET) From: Pekka Savola To: Michel Py cc: Eliot Lear , , Iljitsch van Beijnum Subject: RE: Draft: PI addressing derived from AS numbers In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F54B8C@server2000.arneill-py.sacramento.ca.us> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Thu, 30 Jan 2003, Michel Py wrote: [...] > Your draft amounts to admitting that we collectively failed to deliver a > multihoming solution for IPv6. The time to make this call has not come > yet. If that's how folks feel, that's fine. It's all about the timing. As said, I don't like the approach either, but I guess we have different timescales in our heads. However, please note that the ASN-PI proposal is/was _not_ meant to be a catchall solution. Only a solution for those folks who have currently found it important enough to perform the most extensive form of multihoming, via obtaining AS numbers and a prefix (or stealing one). -- 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 Jan 31 08:29: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 IAA05906 for ; Fri, 31 Jan 2003 08:29:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18ebD1-000AAk-00 for multi6-data@psg.com; Fri, 31 Jan 2003 05:27:55 -0800 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by psg.com with esmtp (Exim 3.36 #1) id 18ebCy-000AAT-00 for multi6@ops.ietf.org; Fri, 31 Jan 2003 05:27:52 -0800 Received: from roadrunner.ecs.soton.ac.uk (roadrunner.ecs.soton.ac.uk [152.78.68.161]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id NAA14653 for ; Fri, 31 Jan 2003 13:27:50 GMT Received: from login.ecs.soton.ac.uk (login.ecs.soton.ac.uk [152.78.68.162]) by roadrunner.ecs.soton.ac.uk (8.12.3/8.12.3) with ESMTP id h0VDRkAU014753 for ; Fri, 31 Jan 2003 13:27:46 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h0VDRkU12685 for multi6@ops.ietf.org; Fri, 31 Jan 2003 13:27:46 GMT Date: Fri, 31 Jan 2003 13:27:46 +0000 From: Tim Chown To: multi6@ops.ietf.org Subject: Re: Draft: PI addressing derived from AS numbers Message-ID: <20030131132746.GH12232@login.ecs.soton.ac.uk> Mail-Followup-To: multi6@ops.ietf.org References: <963621801C6D3E4A9CF454A1972AE8F54B8E@server2000.arneill-py.sacramento.ca.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F54B8E@server2000.arneill-py.sacramento.ca.us> User-Agent: Mutt/1.4i X-ECS-MailScanner: Found to be clean X-Spam-Status: No, hits=-3.0 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT,USER_AGENT_MUTT version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Thu, Jan 30, 2003 at 08:35:01PM -0800, Michel Py wrote: > > Someone please debunk me if I'm wrong, but I think that swamp space was > allocated without the current restrictions of either having a distinct > routing policy or being multihomed. This means that they are a few guys > that still have swamp space (a class C, for the most part) and don't > have an AS. These guys are not multihomed, they just have their ISP > announce their swamp prefix and have the luxury of switching ISPs > without renumbering, which is exactly what PI is about: one _OWNS_ the > address. And presumably these are a bigger hit on the DFZ routing table size than multihomers? Tim From owner-multi6@ops.ietf.org Fri Jan 31 09:51: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 JAA08559 for ; Fri, 31 Jan 2003 09:51:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18ecWn-000DDN-00 for multi6-data@psg.com; Fri, 31 Jan 2003 06:52:25 -0800 Received: from ebola.psc.edu ([128.182.61.124] helo=localhost) by psg.com with esmtp (Exim 3.36 #1) id 18ecWh-000DD5-00 for multi6@ops.ietf.org; Fri, 31 Jan 2003 06:52:19 -0800 Received: from ebola.psc.edu (localhost [127.0.0.1]) by localhost (8.12.2/8.12.2) with ESMTP id h0VEqLYg009618 for ; Fri, 31 Jan 2003 09:52:22 -0500 (EST) Date: Fri, 31 Jan 2003 09:52:21 -0500 From: "Michael H. Lambert" To: multi6@ops.ietf.org Subject: RE: Draft: PI addressing derived from AS numbers Message-ID: <38146371.1044006741@ebola.psc.edu> In-Reply-To: References: 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=-1.3 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > To re-iterate (for all the w.g.), I don't like the approach myself, but I > fail to see good alternatives, _if_ something that works out has to be > pushed out soon. If there's no such need, fine. Would it make sense to push Pekka's draft along the experimental track in the spirit of RFC 1797 (the 39/8 subnet experiment)? It may not be an optimal solution, but it would give the community some breathing room while better methods are developed. I concur with Pekka that sunset provisions are important. Michael +-----------------------------------------------------------------------+ | Michael H. Lambert, Network Engineer Phone: +1 412 268-4960 | | Pittsburgh Supercomputing Center FAX: +1 412 268-8200 | | 4400 Fifth Avenue, Pittsburgh, PA 15213 lambert@psc.edu | +-----------------------------------------------------------------------+ From owner-multi6@ops.ietf.org Fri Jan 31 10:12: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 KAA09085 for ; Fri, 31 Jan 2003 10:12:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18ecrT-000E0L-00 for multi6-data@psg.com; Fri, 31 Jan 2003 07:13:47 -0800 Received: from cyphermail.sandelman.ottawa.on.ca ([192.139.46.78] helo=noxmail.sandelman.ottawa.on.ca) by psg.com with esmtp (Exim 3.36 #1) id 18ecrR-000E09-00 for multi6@ops.ietf.org; Fri, 31 Jan 2003 07:13:45 -0800 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 h0VFCML16357 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Fri, 31 Jan 2003 10:12:28 -0500 (EST) Received: from marajade.sandelman.ottawa.on.ca (marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h0VFCERQ002009 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Fri, 31 Jan 2003 10:12:16 -0500 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by marajade.sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h0VFCBMn002006 for ; Fri, 31 Jan 2003 10:12:14 -0500 Message-Id: <200301311512.h0VFCBMn002006@marajade.sandelman.ottawa.on.ca> To: multi6@ops.ietf.org Subject: Re: Draft: PI addressing derived from AS numbers In-reply-to: Your message of "Thu, 30 Jan 2003 20:35:01 PST." <963621801C6D3E4A9CF454A1972AE8F54B8E@server2000.arneill-py.sacramento.ca.us> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Fri, 31 Jan 2003 10:12:11 -0500 From: Michael Richardson X-Spam-Status: No, hits=-1.4 required=5.0 tests=IN_REP_TO,LINES_OF_YELLING,PGP_SIGNATURE,QUOTED_EMAIL_TEXT, SPAM_PHRASE_01_02 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Michel" == Michel Py writes: Michel> Pekka, >>> Michel Py wrote: This would create a terrible precedent. In the long >>> run, we can expect: - People that have swamp space lobbying for v6 PI >>> also, on the grounds that if people that have an ASN get v6 PI space >>> they should get it too. Actually, swamp space holders have on paper a >>> better reason than ASN holders to get v6 PI space. >> Pekka Savola wrote: Uhh, what do you mean by swamp space holders, >> those that don't have ASN? Multihomers that use private ASN's or >> static routing and have their primary ISP advertise a more specific? Michel> Someone please debunk me if I'm wrong, but I think that swamp Michel> space was allocated without the current restrictions of either Michel> having a distinct routing policy or being multihomed. This means Michel> that they are a few guys that still have swamp space (a class C, Michel> for the most part) and don't have an AS. These guys are not No, I disagree with what you wrote. I think that there are huge numbers of people who have swamp space, but do not have an AS. There are even many tier-3 ISPs with /19s from >204 class C space that do not have ASs, as they've only ever been single homed ISPs. There are lots of AS#s which as not really in use anymore (or should not be in use) following merges and acquisitions. They continue to be out there, though. The AS proposal certainly results in a much smaller DFZ than if we handed every holder of PI IPv4 space PI space in IPv6. Having said all of this, there are also lots of organizations that currently possess PI space (a university with a class B for instance) that are currently not multihomed (and may not even speak BGP), but practice serial-multihoming - they switch ISPs without renumbering. Finally, we have an increasing number of places that have "multihomed" because they got PA IPv4 space from two (or more providers) and advertise www.example.com under two IP addresses. Very confusing to their customers who do not have smart web proxies: site doesn't work, shift-reload, site works. Click, site doesn't work. shift-reload, site works. I have recently moved one to proper multihoming, and they are much happier. I would very much like to have given them some kind of PI IPv6 space. As it is, they have 6to4 based IPv6 space numbered from their PI IPv4 space. ] 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"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPjqSSYqHRg3pndX9AQHdfQP+JbyBKuEy87YbalmXxVKMmAcecLMLLJ45 ZrCvABQRZUlgHsMumh4+yGsk+ZjCgp1OkXsEDNS30RWhxPMhFe/6umIp8lxX+656 0uzA9jn5ZCRULA12QfLYoL+QlX6NMRNzpf5gwpaZcMMdtXJmntMESnl0tomxoQin XYJK3N5X5rQ= =U9GJ -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Fri Jan 31 11:23: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 LAA11136 for ; Fri, 31 Jan 2003 11:23:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18edxa-000GtL-00 for multi6-data@psg.com; Fri, 31 Jan 2003 08:24:10 -0800 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 18edxU-000GsB-00 for multi6@ops.ietf.org; Fri, 31 Jan 2003 08:24:04 -0800 Subject: RE: Draft: PI addressing derived from AS numbers Date: Fri, 31 Jan 2003 08:24:04 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <963621801C6D3E4A9CF454A1972AE8F5B94D@server2000.arneill-py.sacramento.ca.us> Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Thread-Topic: Draft: PI addressing derived from AS numbers Thread-Index: AcLJLmbIxSbyV1U4QLGOEYMpjOlUyQAFnDUg From: "Michel Py" To: "Tim Chown" , X-Spam-Status: No, hits=0.0 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA11136 Tim, >> Michel Py wrote: >> Someone please debunk me if I'm wrong, but I think that swamp >> space was allocated without the current restrictions of either >> having a distinct routing policy or being multihomed. This means >> that they are a few guys that still have swamp space (a class C, >> for the most part) and don't have an AS. These guys are not >> multihomed, they just have their ISP announce their swamp prefix >> and have the luxury of switching ISPs without renumbering, which >> is exactly what PI is about: one _OWNS_ the address. > Tim Chown wrote: > And presumably these are a bigger hit on the DFZ routing table > size than multihomers? I don't think so, it more a matter of creating the precedent then real savings on the routing table size. Michel. From owner-multi6@ops.ietf.org Fri Jan 31 11: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 LAA11216 for ; Fri, 31 Jan 2003 11:29:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18ee4L-000HB9-00 for multi6-data@psg.com; Fri, 31 Jan 2003 08:31:09 -0800 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by psg.com with esmtp (Exim 3.36 #1) id 18ee4I-000HAq-00 for multi6@ops.ietf.org; Fri, 31 Jan 2003 08:31:06 -0800 Received: from roadrunner.ecs.soton.ac.uk (roadrunner.ecs.soton.ac.uk [152.78.68.161]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id QAA20407 for ; Fri, 31 Jan 2003 16:31:05 GMT Received: from login.ecs.soton.ac.uk (login.ecs.soton.ac.uk [152.78.68.162]) by roadrunner.ecs.soton.ac.uk (8.12.3/8.12.3) with ESMTP id h0VGV08A008248 for ; Fri, 31 Jan 2003 16:31:00 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h0VGV0l15237 for multi6@ops.ietf.org; Fri, 31 Jan 2003 16:31:00 GMT Date: Fri, 31 Jan 2003 16:31:00 +0000 From: Tim Chown To: multi6@ops.ietf.org Subject: Re: Draft: PI addressing derived from AS numbers Message-ID: <20030131163100.GD15124@login.ecs.soton.ac.uk> Mail-Followup-To: multi6@ops.ietf.org References: <963621801C6D3E4A9CF454A1972AE8F5B94D@server2000.arneill-py.sacramento.ca.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F5B94D@server2000.arneill-py.sacramento.ca.us> User-Agent: Mutt/1.4i X-ECS-MailScanner: Found to be clean X-Spam-Status: No, hits=-4.6 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MUTT version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Fri, Jan 31, 2003 at 08:24:04AM -0800, Michel Py wrote: > > Tim Chown wrote: > > And presumably these are a bigger hit on the DFZ routing table > > size than multihomers? > > I don't think so, it more a matter of creating the precedent then real > savings on the routing table size. OK, I beleive you, but would be interested in any stats in this area? Tim From owner-multi6@ops.ietf.org Fri Jan 31 11:46: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 LAA11705 for ; Fri, 31 Jan 2003 11:46:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18eeLP-000I2O-00 for multi6-data@psg.com; Fri, 31 Jan 2003 08:48:47 -0800 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 18eeLL-000I1u-00 for multi6@ops.ietf.org; Fri, 31 Jan 2003 08:48:44 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h0VGmdt26598 for ; Fri, 31 Jan 2003 18:48:40 +0200 Date: Fri, 31 Jan 2003 18:48:39 +0200 (EET) From: Pekka Savola To: multi6@ops.ietf.org Subject: Re: Draft: PI addressing derived from AS numbers In-Reply-To: <20030131163100.GD15124@login.ecs.soton.ac.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.0 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_01_02,USER_AGENT_PINE version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Fri, 31 Jan 2003, Tim Chown wrote: > On Fri, Jan 31, 2003 at 08:24:04AM -0800, Michel Py wrote: > > > > Tim Chown wrote: > > > And presumably these are a bigger hit on the DFZ routing table > > > size than multihomers? > > > > I don't think so, it more a matter of creating the precedent then real > > savings on the routing table size. > > OK, I beleive you, but would be interested in any stats in this area? I'd like to hear a specific definition of this, so we could _have_ stats. Do you mean announcing a more specific route from different origin AS than the aggregate? Do you you want to restrict that to address blocks allocated by RIR's somehow, etc.? I've actually done some analysis on a portion of the routing table to look for multihoming; extracting this info, if defined, might not be a problem. -- 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 Jan 31 12:03: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 MAA12093 for ; Fri, 31 Jan 2003 12:03:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18eebK-000Ip5-00 for multi6-data@psg.com; Fri, 31 Jan 2003 09:05:14 -0800 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 18eebG-000Iol-00 for multi6@ops.ietf.org; Fri, 31 Jan 2003 09:05:11 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h0VH57726730 for ; Fri, 31 Jan 2003 19:05:07 +0200 Date: Fri, 31 Jan 2003 19:05:07 +0200 (EET) From: Pekka Savola To: multi6@ops.ietf.org Subject: Comment on draft-ietf-multi6-v4-multihoming-00 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-0.1 required=5.0 tests=SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Hi, Anyone remember draft-ietf-multi6-v4-multihoming-00 from 2001? Well, I've been thinking about IPv4 multihoming background for a while now, and would like to have people consider something which may not have been obvious to all. The draft lists the following: 3. Motivations for Multihoming 3.1 Redundancy 3.2 Load Sharing 3.3 Performance 3.4 Policy I'd like to propose an additional item, "3.0 Independence". It's only implicitly included under Policy, and technically (mostly) included under redundancy.. but it seems to me that it is a major reason for certain solutions, and a critical reason why many IPv6 site multihoming solutions are not considered adequate. Is there some flaw in my thinking? Are there other missing pieces in the old document? Any other references to documenting IPv4 practises? -- 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 Jan 31 19:17: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 TAA23065 for ; Fri, 31 Jan 2003 19:17:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18elLz-000ENL-00 for multi6-data@psg.com; Fri, 31 Jan 2003 16:17:51 -0800 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 18elLw-000EN8-00 for multi6@ops.ietf.org; Fri, 31 Jan 2003 16:17:48 -0800 Content-class: urn:content-classes:message Subject: RE: Draft: PI addressing derived from AS numbers Date: Fri, 31 Jan 2003 16:17:47 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <963621801C6D3E4A9CF454A1972AE8F54B97@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Thread-Topic: Draft: PI addressing derived from AS numbers Thread-Index: AcLJOTmM/d1FNIZRSnyvpHb15vCIHAATT9Cg From: "Michel Py" To: "Michael Lambert" , X-Spam-Status: No, hits=0.0 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA23065 Michael, > Would it make sense to push Pekka's draft along the experimental > track in the spirit of RFC 1797 (the 39/8 subnet experiment)? > It may not be an optimal solution, but it would give the > community some breathing room while better methods are developed. > I concur with Pekka that sunset provisions are important. If a sunset is required, then requesting a "special" 6bone pTLA would be the way to go. I don't see what that would buy though, and here's the rationale: The idea behind Pekka's draft is that deployment of IPv6 is being hindered because organizations that currently have an ASN are waiting for some kind of PI to deploy. Why are they waiting? Because they don't want to renumber. Giving these guys a prefix that sunsets does not do them any good. Michel. From owner-multi6@ops.ietf.org Fri Jan 31 20: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 UAA24025 for ; Fri, 31 Jan 2003 20:01:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18em3I-000Gcd-00 for multi6-data@psg.com; Fri, 31 Jan 2003 17:02:36 -0800 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 18em3G-000GcR-00 for multi6@ops.ietf.org; Fri, 31 Jan 2003 17:02:34 -0800 Content-class: urn:content-classes:message Subject: RE: Draft: PI addressing derived from AS numbers Date: Fri, 31 Jan 2003 17:02:33 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <963621801C6D3E4A9CF454A1972AE8F54B96@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Thread-Topic: Draft: PI addressing derived from AS numbers Thread-Index: AcLJRvKlXE3rhEBOQ16K8uiDEC9TmgAP1e+Q From: "Michel Py" To: "Tim Chown" , X-Spam-Status: No, hits=-0.2 required=5.0 tests=GIVING_AWAY,QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id UAA24025 Tim / Pekka, >>> Tim Chown wrote: >>> And presumably these are a bigger hit on the DFZ routing >>> table size than multihomers? >> Michel Py wrote: >> I don't think so, it more a matter of creating the precedent >> then real savings on the routing table size. > OK, I beleive you, but would be interested in any stats in this area? Sure, but keep reading. > Pekka Savola wrote: > I'd like to hear a specific definition of this, so we could _have_ > stats. Do you mean announcing a more specific route from different > origin AS than the aggregate? Do you you want to restrict that to > address blocks allocated by RIR's somehow, etc.? > I've actually done some analysis on a portion of the routing table > to look for multihoming; extracting this info, if defined, might > not be a problem. I don't think that the real number actually matters. Is it 10k? 20k? 30k? nobody cares because in 3 or 4 years if we have 30k routes to deal with it would not be a problem for any decent router. The problem is that we would have opened the gates of hell by giving away PI to a certain category of users and that everyone else and their dog will want one too and the issue is dealing with a billion routes in 10 years. Michel. From owner-multi6@ops.ietf.org Fri Jan 31 20:11: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 UAA24203 for ; Fri, 31 Jan 2003 20:11:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18emDX-000HBD-00 for multi6-data@psg.com; Fri, 31 Jan 2003 17:13:11 -0800 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 18emDU-000HAq-00 for multi6@ops.ietf.org; Fri, 31 Jan 2003 17:13:08 -0800 Content-class: urn:content-classes:message Subject: RE: Draft: PI addressing derived from AS numbers Date: Fri, 31 Jan 2003 17:13:08 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <963621801C6D3E4A9CF454A1972AE8F54B9A@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Thread-Topic: Draft: PI addressing derived from AS numbers Thread-Index: AcLJPCtAZHehwkPdTaKnXAM3qjq5GQAUcbmA From: "Michel Py" To: "Michael Richardson" , X-Spam-Status: No, hits=0.0 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id UAA24203 > Michael Richardson wrote: > The AS proposal certainly results in a much smaller DFZ than if > we handed every holder of PI IPv4 space PI space in IPv6. Absolutely, the point I was making is not that it would be bigger, as I do like the idea, but that it would likely not be possible to stick to it: If we give PI to ASN holders, you can be sure that the lobbying of swamp space holders to get the same thing is going to be a freight train that nobody will be able to stop. > I would very much like to have given them some kind of > PI IPv6 space. I have been finicky lately about the semantics of this: Some kind of PI other than the one we have could be fine, but certainly not straight PI. Michel.