From owner-Big-Internet@munnari.oz.au Tue Feb 2 05:58:48 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA08580; Tue, 2 Feb 1993 05:59:03 +1100 (from owner-Big-Internet) Return-Path: Received: from vela.acs.oakland.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08566; Tue, 2 Feb 1993 05:58:48 +1100 (from bill.simpson@um.cc.umich.edu) Received: from via.ws07.merit.edu by vela.acs.oakland.edu with SMTP id AA20691 (5.65c+/IDA-1.4.4); Mon, 1 Feb 1993 13:58:31 -0500 Date: Mon, 1 Feb 93 13:25:12 EDT From: "William Allen Simpson" Message-Id: <9074.bill.simpson@um.cc.umich.edu> To: big-internet@munnari.oz.au Reply-To: bsimpson@morningstar.com Subject: Metro Addressing Summary OK, now that the questioners have learned the granularity of a U.S. metro area, perhaps we can get to general principles. Are we agreed that (whether for actual routing or Endpoint Identifier), it is reasonable to design the numbering space in the following order? 1) planetary body in the solar system 2) continent on the planetary body 3) political boundary within a continent 4) metropolitan statistical area 5) provider 6) site I have not heard any request for interstellar allocation. We seem to have reached consensus that the provider allocation must definitely not span planets, or continents. There has been strong sentiment from the European contingent that assignment should at least roughly follow current political boundaries, although such boundaries may change in the future. In the short term (IP4), we can probably ignore metros. There are few providers, and even fewer metro points of contact. If we can agree on this, we can get the IP guidelines document completed and published. We do not seem to have reached consensus as to whether sites will be required to change numbers when they change providers. I don't think it is a short term (IP4) issue, and wish to table it for long term until we have more experience with the IP4 replacement. I am personally convinced that, in the long term (SIP/PIP/etc), the provider allocation within metropolitan areas will allow the greatest utility in management of numbering space. It would make me very happy if the SIP and PIP adherants could agree on a numbering scheme. By Wednesday, I will make a revision of the North American proposed assignments based on the census figures that Larry Kestenbaum provided. Bill.Simpson@um.cc.umich.edu From owner-Big-Internet@munnari.oz.au Tue Feb 2 06:55:20 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA10228; Tue, 2 Feb 1993 06:55:29 +1100 (from owner-Big-Internet) Return-Path: Received: from babyoil.ftp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10223; Tue, 2 Feb 1993 06:55:20 +1100 (from kasten@ftp.com) Received: by ftp.com id AA07839; Mon, 1 Feb 93 14:55:06 -0500 Date: Mon, 1 Feb 93 14:55:06 -0500 Message-Id: <9302011955.AA07839@ftp.com> To: bsimpson@morningstar.com Subject: Re: Metro Addressing Summary From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: big-internet@munnari.oz.au > Are we agreed that (whether for actual routing or Endpoint Identifier), > it is reasonable to design the numbering space in the following order? > > 1) planetary body in the solar system > 2) continent on the planetary body > 3) political boundary within a continent > 4) metropolitan statistical area > 5) provider > 6) site > No we are not agreed. Endpoints are numbers. They have ABSOLUTELY NO TOPOLOGICAL SIGNIFICANCE. That is the whole point of having them distinct from addresses which DO HAVE TOPOLOGICAL SIGNIFICANCE. (where to satellites and space shuttles and the like fall in this scheme? do they qualify as planetary bodies? How about moons and asteroids and comets....) > I have not heard any request for interstellar allocation. what would you do about pioneer (i think) which is beyond the orbit of pluto at this point :-) I still do not recall how a company, which might have several providers, and its own internal, international, net would fit into this scheme. FTP has two offices, one on the left coast and one on the right coast. The left coast office might get connected via BARRNET, the right coast office via NEARNET, the right coast office might also have a PSI connection, _and_ we might have a private T1 line between the two. How would these be addressed? How would this be handled when we get a European office, with a private T1 to our right-coast office, and an EARN connection? -- Frank Kastenholz From owner-Big-Internet@munnari.oz.au Tue Feb 2 08:15:20 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12313; Tue, 2 Feb 1993 08:15:28 +1100 (from owner-Big-Internet) Return-Path: Message-Id: <9302012115.12313@munnari.oz.au> Received: from research.att.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12308; Tue, 2 Feb 1993 08:15:20 +1100 (from hgs@research.att.com) Received: by inet; Mon Feb 1 16:15 EST 1993 Date: Mon, 1 Feb 93 16:14:56 EST From: hgs@research.att.com (Henning G. Schulzrinne) To: bsimpson@morningstar.com, big-internet@munnari.oz.au Subject: Re: Metro Addressing Summary Maybe this has been beaten to death already, but for most countries, the telephone company already divides countries into routing areas (area codes in the U.S. and Canada). The density of area codes and their current utilization (I seem to remember statistics to that effect) should give a good indication as to the density of telecom needs, in particular since some concentrations do not necessarily follow metropolitan areas. Bellcore probably has plans for at least 10 years as to how area codes are to be split. Also, while I may or may not know what metropolitan area my town belongs to (is every town assigned to one? what about sparsely populated areas such as North Dakota or Alaska?), I definitely do know my area code. Clearly, area codes change relatively frequently (as do metropolitan areas, if maybe less so). We could use the current assignment as the basis for Internet assignment, or, once renumbering hosts has become trivial, follow the area code splits, as they can be expected to roughly trace telecom/internet density. Note that the number of metro areas (about 90) and area codes (about 150) is on the same order of magnitude. Inventing yet another numbering scheme does not seem to offer profound advantages over using one that already exists and people are very familiar with. Or am I missing something? --- Henning Schulzrinne (hgs@research.att.com) AT&T Bell Laboratories (MH 2A-244) 600 Mountain Ave; Murray Hill, NJ 07974 phone: +1 908 582-2262; fax: +1 908 582-5809 From owner-big-internet@munnari.oz.au Tue Feb 2 13:08:05 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22480; Tue, 2 Feb 1993 13:08:18 +1100 (from owner-big-internet) Return-Path: Received: from motgate.mot.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19169; Tue, 2 Feb 1993 11:38:46 +1100 (from lambert@phx.sectel.mot.com) Received: from pobox.mot.com ([129.188.137.100]) by motgate.mot.com with SMTP (5.65c/IDA-1.4.4/MOT-2.6 for ) id AA02611; Mon, 1 Feb 1993 18:37:54 -0600 Received: from phx.sectel.mot.com ([192.94.147.2]) by pobox.mot.com with SMTP (5.65c/IDA-1.4.4/MOT-2.6) id AA03060; Mon, 1 Feb 1993 18:37:50 -0600 Received: from oasis.sectel by phx.sectel.mot.com (4.1/SMI-4.1) id AA11844; Mon, 1 Feb 93 17:36:38 MST Date: Mon, 1 Feb 93 17:36:38 MST From: lambert@phx.sectel.mot.com (Paul Lambert) Message-Id: <9302020036.AA11844@ phx.sectel.mot.com> To: bsimpson@morningstar.com Subject: Re: Metro Addressing Summary Cc: big-internet@munnari.oz.au > From owner-Big-Internet@munnari.oz.au Mon Feb 1 14:36:00 1993 > Are we agreed that (whether for actual routing or Endpoint Identifier), > it is reasonable to design the numbering space in the following order? > > 1) planetary body in the solar system > 2) continent on the planetary body > 3) political boundary within a continent > 4) metropolitan statistical area > 5) provider > 6) site > > I have not heard any request for interstellar allocation. > What about Low Earth Orbit satellites? These satellites will provide communication service that cross continental and political boundaries. Airliners will also cross these same boundaries. It is important to not lump the concept of Endpoint Ids in with topological determined addresses. Paul Lambert From owner-big-internet@munnari.oz.au Tue Feb 2 15:57:38 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA28807; Tue, 2 Feb 1993 15:57:47 +1100 (from owner-big-internet) Return-Path: Received: from SPECTRUM.CMC.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25057; Tue, 2 Feb 1993 14:14:40 +1100 (from lars@CMC.COM) Received: by Spectrum.CMC.COM (4.1/SMI-4.1(Spectrum)) id AA02199; Mon, 1 Feb 93 19:12:46 PST Newsgroups: ietf.big-internet Path: lars From: lars@spectrum.CMC.COM (Lars Poulsen) Subject: Re: Metro Addressing Summary Message-Id: <1993Feb2.031236.2161@spectrum.CMC.COM> Organization: CMC Network Systems (Rockwell DCD), Santa Barbara, CA, USA References: <9302011955.AA07839@ftp.com> Date: Tue, 2 Feb 93 03:12:36 GMT Apparently-To: Big-Internet@munnari.OZ.AU In article <9302011955.AA07839@ftp.com> kasten@ftp.com (Frank Kastenholz) writes: > > 1) planetary body in the solar system > > 2) continent on the planetary body > > 3) political boundary within a continent > > 4) metropolitan statistical area > > 5) provider > > 6) site > >I still do not recall how a company, which might have several >providers, and its own internal, international, net would fit into this >scheme. FTP has two offices, one on the left coast and one on the right >coast. The left coast office might get connected via BARRNET, the right >coast office via NEARNET, the right coast office might also have a >PSI connection, _and_ we might have a private T1 line between the two. > >How would these be addressed? > >How would this be handled when we get a European office, with a private >T1 to our right-coast office, and an EARN connection? I would expect the following addresses (in some numeric realization): Earth.NoAm.Usa.Ca.Sfo.FTP Earth.NoAm.Usa.Ma.Bos.FTP Earth.Europe.UK.Lon.FTP The routing along the intra-company links would be a routing policy within your own routers. In fact, this is likely to lead to much more cost-effective routing than any current scheme. -- / Lars Poulsen, SMTS Software Engineer Internet E-mail: lars@CMC.COM CMC Network Products / Rockwell Int'l Telephone: +1-805-968-4262 Santa Barbara, CA 93117-3083 TeleFAX: +1-805-968-8256 From owner-big-internet@munnari.oz.au Tue Feb 2 19:01:05 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA04906; Tue, 2 Feb 1993 19:01:08 +1100 (from owner-big-internet) Return-Path: Received: from optics.wc.novell.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00737; Tue, 2 Feb 1993 16:46:48 +1100 (from minshall@wc.novell.com) Received: from by wc.novell.com (4.1/smi4.1.1.v91190) id AB01409; Mon, 1 Feb 93 21:43:11 PST Date: Mon, 1 Feb 93 21:43:11 PST Message-Id: <9302020543.AB01409@wc.novell.com> To: big-internet@munnari.oz.au From: minshall@wc.novell.com X-Sender: minshall@optics.wc.novell.com (Unverified) Subject: I-IP-P Hi, all. This is a proposal for an "Inter-Internetwork Layer Layer". In other words, there are IPv4, SIP, PIP, TUBA, etc., all of which provide common services to TCP, UDP, ICMP, etc. (more or less, and some provide things outside the intersection). It would be *nice* if all of this would settle down such that only one IP existed, and this might even happen. But if that doesn't happen... Define an "Inter-Internetwork Protocol Protocol" ("I-IP-P" - anyone seen "Charlotte's Web" recently?), which consists minimally of source and destination addresses and a protocol demultiplexer (but could include a hop count and/or checksum). Then, define how TCP, UDP, etc., run over I-IP-P (protocol numbers, how the pseudo-header checksum is computed, for example). Then, define how IP-IP-P runs over IPv4, SIP, PIP, TUBA, etc. (Where this founders, of course, are those neat things that aren't exactly in the intersection, like TOS, flow id's, multicast possibly, etc. Vague waving of hands...) Note that the I-IP-P header is *NOT* used for any routing. That is done with the IP of choice. Note also that it is not necessarily the case the the source and destination addresses in the I-IP-P header are from the same IP. Note finally (in this note) that the address size is probably fairly large and/or variable. Thoughts? Greg Minshall From owner-Big-Internet@munnari.oz.au Tue Feb 2 19:51:45 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA06358; Tue, 2 Feb 1993 19:51:54 +1100 (from owner-Big-Internet) Return-Path: Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06349; Tue, 2 Feb 1993 19:51:45 +1100 (from tli@cisco.com) Received: by lager.cisco.com; Tue, 2 Feb 1993 00:51:20 -0800 Date: Tue, 2 Feb 1993 00:51:20 -0800 From: Tony Li Message-Id: <199302020851.AA29011@lager.cisco.com> To: bill.simpson@um.cc.umich.edu, kasten@ftp.com Cc: big-internet@munnari.oz.au Subject: Metro Addressing Summary Bill, Are we agreed that (whether for actual routing or Endpoint Identifier), it is reasonable to design the numbering space in the following order? 1) planetary body in the solar system 2) continent on the planetary body 3) political boundary within a continent 4) metropolitan statistical area 5) provider 6) site No, not at all. Are you suggesting that there be fixed boundaries in the address for each level? If so, what happens when you exhaust this fragment? Are you suggesting this rigid format for the levels of hierarchy? Why are you imposing such a structure on the world when you need not do so? Unnecessary structure means that later you will have to change (i.e., introduce a wart) when you need more flexibility. We seem to have reached consensus that the provider allocation must definitely not span planets, or continents. I would not agree about continents. I know of providers that span continents. In some sense, "provider allocation" is a misnomer. It really is "topology based allocation". I can imagine topologies in which a provider (for various reasons) has links to a continent but is not interconnected to the remainder of the Internet on that continent. Forcing the provider to use the continental address in this case is a major mistake. I would agree about planets, tho. ;-) There has been strong sentiment from the European contingent that assignment should at least roughly follow current political boundaries, although such boundaries may change in the future. I believe that this should be a wholly local decision. I would also point out that unless the network topology has some consistency with the address assignment plan, that aggregation at this level may be difficult and/or impossible. Aggregation one level above this does fix things tho. So if you want to make a local mess, it really is local. ;-) In the short term (IP4), we can probably ignore metros. There are few providers, and even fewer metro points of contact. If we can agree on this, we can get the IP guidelines document completed and published. Agreed. But you knew that... ;-) We do not seem to have reached consensus as to whether sites will be required to change numbers when they change providers. I don't think it is a short term (IP4) issue, and wish to table it for long term until we have more experience with the IP4 replacement. I think that we do have consensus that sites are not REQUIRED to renumber, but are STRONGLY ENCOURAGED to do so. Wordsmith this if you like... I think that we SHOULD point out that the ability to renumber, whether for the case of host relocation or provider change is a very strong requirement for IP7. I am personally convinced that, in the long term (SIP/PIP/etc), the provider allocation within metropolitan areas will allow the greatest utility in management of numbering space. It would make me very happy if the SIP and PIP adherants could agree on a numbering scheme. Again, I'm not convinced that it should be provider based so much as topologically based... This is to say that the metro area should be the root of the local topologically addressed tree. what would you do about pioneer (i think) which is beyond the orbit of pluto at this point :-) No problem. It doesn't speak IPv4. Upgrade it to IPv7 and solve the problem there. ;-) I still do not recall how a company, which might have several providers, and its own internal, international, net would fit into this scheme. FTP has two offices, one on the left coast and one on the right coast. The left coast office might get connected via BARRNET, the right coast office via NEARNET, the right coast office might also have a PSI connection, _and_ we might have a private T1 line between the two. How would these be addressed? How would this be handled when we get a European office, with a private T1 to our right-coast office, and an EARN connection? Suggest you get either the RL draft or RFC 1237. These cases and the possible alternatives are discussed at great length. Tony From owner-Big-Internet@munnari.oz.au Tue Feb 2 21:09:06 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA08412; Tue, 2 Feb 1993 21:09:22 +1100 (from owner-Big-Internet) Return-Path: Received: from europe.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08403; Tue, 2 Feb 1993 21:09:06 +1100 (from abochann@brussels.cisco.com) Received: from brussels.cisco.com by europe.cisco.com with TCP; Tue, 2 Feb 93 10:04:29 GMT Received: by brussels.cisco.com; Tue, 2 Feb 93 11:02:31 +0100 From: Alex Bochannek Message-Id: <9302021002.AA25815@brussels.cisco.com> Subject: Metro Addressing Summary To: big-internet@munnari.oz.au Date: Tue, 2 Feb 93 11:02:29 MET Cc: bill.simpson@um.cc.umich.edu, kasten@ftp.com Reply-To: abochann@cisco.com X-Mailer: ELM [version 2.3 PL11] Just thought I might throw in my 2 cents to the metro addressing issue. > 1) planetary body in the solar system > 2) continent on the planetary body > 3) political boundary within a continent > 4) metropolitan statistical area > 5) provider > 6) site I believe geographical boundaries like 1) and 2) are extremely unlikely to change, 4) might change over time but slowly (if we do not take things like wars into account). 5) and 6) might change frequently and the provider can also span any of the areas covered by 1), 2) and 3). And now to number three. Well, if I look at my atlas I had back in high-school and now look at the current European map, it changed quite a bit. What I am saying is, be prepared for political boundaries changing as quickly as anything else... The point of view of a German who is from a city that was divided and surrounded by a country that used to be a second Germany ;-) -- Alex Bochannek TAC : +32 2 643 26-30 Technical Support Analyst Direct: +32 2 643 26-38 Cisco Systems International S.A. Fax : +32 2 643 26-27 250 avenue Louise, 8th Floor RFC822: abochann@cisco.com 1050 Brussels, Belgium From owner-Big-Internet@munnari.oz.au Wed Feb 3 03:23:08 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA19999; Wed, 3 Feb 1993 03:23:58 +1100 (from owner-Big-Internet) Return-Path: Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19982; Wed, 3 Feb 1993 03:23:08 +1100 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <11716>; Tue, 2 Feb 1993 08:22:31 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Tue, 2 Feb 1993 08:22:19 -0800 To: minshall@wc.novell.com Cc: big-internet@munnari.oz.au, deering@parc.xerox.com Subject: Re: I-IP-P In-Reply-To: Your message of "Mon, 01 Feb 93 21:43:11 PST." <9302020543.AB01409@wc.novell.com> Date: Tue, 2 Feb 1993 08:22:11 PST Sender: Steve Deering From: Steve Deering Message-Id: <93Feb2.082219pst.12171@skylark.parc.xerox.com> Greg, So, you are proposing to apply the internetworking approach recursively, creating an inter-internetwork. We can already do that with any one of the IPNext proposals (or with XNS or ...), by tunneling over any of the others. Can you explain more clearly (1) why you want to define yet another header for that purpose, and (2) what problems you intend it to solve? Some of us think it is important to keep the size of the internet header relatively small, since it is overhead in every datagram, so the thought of a second, redundant header does not particularly appeal. Or were you just proposing a generic API, and not a full-fledged extra protocol layer? Steve From owner-Big-Internet@munnari.oz.au Wed Feb 3 05:28:31 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA23633; Wed, 3 Feb 1993 05:28:44 +1100 (from owner-Big-Internet) Return-Path: Received: from oliveb.ATC.Olivetti.Com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23627; Wed, 3 Feb 1993 05:28:31 +1100 (from roode@arezzo.oas.olivetti.com) Received: by oliveb.ATC.Olivetti.Com (5.65/1.34) id AA01641; Tue, 2 Feb 93 10:28:21 -0800 Received: by oliveb.ATC.Olivetti.Com (5.51/smail2.5/12-18-87) id AA01636; Tue, 2 Feb 93 10:28:17 PST Received: by arezzo.oas.olivetti.com (4.1/SMI-3.2) id AA04762; Tue, 2 Feb 93 10:28:10 PST Date: Tue, 2 Feb 93 10:28:09 PST From: David Roode To: lambert@phx.sectel.mot.com (Paul Lambert) Cc: bsimpson@morningstar.com, big-internet@munnari.oz.au Subject: Re: Metro Addressing Summary In-Reply-To: Your message of Mon, 1 Feb 1993 16:36:38 -0800 Message-Id: Thanks, maybe Wednesday.... From owner-Big-Internet@munnari.oz.au Wed Feb 3 20:08:20 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA25132; Wed, 3 Feb 1993 20:08:27 +1100 (from owner-Big-Internet) Return-Path: Received: from mitsou.inria.fr by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25129; Wed, 3 Feb 1993 20:08:20 +1100 (from huitema@mitsou.inria.fr) Received: by mitsou.inria.fr (5.65c/IDA-1.2.8) id AA24443; Wed, 3 Feb 1993 10:10:57 +0100 Message-Id: <199302030910.AA24443@mitsou.inria.fr> To: Tony Li Cc: big-internet@munnari.oz.au Subject: Re: Metro Addressing Summary In-Reply-To: Your message of "Tue, 02 Feb 93 00:51:20 PST." <199302020851.AA29011@lager.cisco.com> Date: Wed, 03 Feb 93 10:10:56 +0100 From: Christian Huitema Summarizing is a good idea, but I don't think we have progressed enough so far to be able to summarize a consensus. Out of the current debate, I could barely see a couple of quasi agreements: * Many people believe that "addresses" should not be too tightly coupled to the topology. Or at least, many can be coupled to have said precisely that. * A larger set of participants in the discussion agree that addresses should be "structured" so as to enable "aggregation", e.g. route all addresses that start by "01101110111" on one single route regardless of the "remaining bits". * Geographical assignment of addresses is presented as one way to achieve this objective -- if two networks are geographically near one other, chances are that they will be also near oneother in the network topology. That assumption is however fiercely debated, with counter examples such as big worldwide companies, low orbiting satellites (geo. stat. orbiting have the same property, btw). Similarly, the idea that addresses should not follow network topology is also debated, e.g. by JNC who asserts that if an address does not contain routing information it is merely a binary name, an EID, that has always to be completed by a more significant "address". One of the most obscure point in the debate is the definition of the alternative to geographical address, i.e. provider addressing. According to various participants, a "provider" can be: 1) a large "transit" carrier, e.g. ANS on steroids, grown to multinational status. 2) a large "private transit" organisation, connecting clients all over the world, e.g. a network dedicated to high energy physicists. 3) a quasi monopolistic "regional" network, similar to the "baby bells". In that model, "customers" are given address in the regional domain; some magic is used to associate them with one of the many transit carriers connected to the regional. 4) a competitive regional network. Customers here are not only expected to select the prefered transit networks, but also to swap between "local attachments", or to maintain multiple attachments I tend to believe that we should first get an agreement on what we want to facilitate: cost efficient routing between quasi monopolistic regionals or customer hopping between competitive regionals. Christian Huitema From owner-Big-Internet@munnari.oz.au Thu Feb 4 02:02:48 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA05170; Thu, 4 Feb 1993 02:02:55 +1100 (from owner-Big-Internet) Return-Path: Received: from babyoil.ftp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05162; Thu, 4 Feb 1993 02:02:48 +1100 (from kasten@ftp.com) Received: by ftp.com id AA17391; Wed, 3 Feb 93 10:02:34 -0500 Date: Wed, 3 Feb 93 10:02:34 -0500 Message-Id: <9302031502.AA17391@ftp.com> To: Christian.Huitema@sophia.inria.fr Subject: Re: Metro Addressing Summary From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: tli@cisco.com, big-internet@munnari.oz.au Christian, > * Many people believe that "addresses" should not be too tightly coupled to > the topology. Or at least, many can be coupled to have said precisely that. Addresses MUST be very very tightly coupled to the topology. This is the definition of an address, since it defines a point on the topology. What MUST NOT be coupled to the topology in any way is the Endpoint Identifier. > * Geographical assignment of addresses is presented as one way to achieve this > objective -- if two networks are geographically near one other, chances are > that they will be also near oneother in the network topology. I do not think that we can make this claim. One building could be connected to the network via, e.g., NEARNET, while the building across the street is connected via PSI. For example, a friend of mine works about 40 miles from where I am. FTP gets its service through NEARNET (the New England regional in the US). The company she works for gets her connection through a dialup line into CERFNET (a US California regional/comemrcial provider). We are both in the Northeast corner of the US, as is NEARNET. CERFNET is based in the Southwest corner of the US (about as geographically far away as possible). Her's a traceroute from me to her CERFNET connection: hop 1: 128.127.125.13 sulfur-dioxide.ftp.com hop 2: 128.127.2.1 backyard.ftp.com hop 3: 128.127.1.5 near-gw.ftp.com hop 4: 131.192.37.1 bbn1-gw.near.net hop 5: 131.192.2.2 mit2-gw.near.net hop 6: 192.54.222.6 enss.near.net hop 7: 140.222.49.3 t3-2.Hartford-cnss49.t3.ans.net hop 8: 140.222.48.4 t3-3.Hartford-cnss48.t3.ans.net hop 9: 140.222.32.3 t3-2.New-York-cnss32.t3.ans.net hop 10: 140.222.40.2 t3-1.Cleveland-cnss40.t3.ans.net hop 11: 140.222.24.3 t3-2.Chicago-cnss24.t3.ans.net hop 12: 140.222.8.2 t3-1.San-Francisco-cnss8.t3.ans.net hop 13: 140.222.16.1 t3-0.Los-Angeles-cnss16.t3.ans.net hop 14: 140.222.17.1 t3-0.Los-Angeles-cnss17.t3.ans.net hop 15: 140.222.135.1 t3-0.enss135.t3.ans.net hop 16: 198.17.46.152 longboard.sdsc.edu I do not believe that we can adequately describe the addressing hierarchy at this time. We know that we need a hierarchy. We can specify how to make the hierarchy. We can not specify what the elements of the hierarchy should be. To do so now would be like Paul Mockapetris specifying what should be in each level of the DNS hierarchy in 1983. All that we can honestly do is to specify that a hierarchy exists, define how to specify it, define the top levels (like .gov, .mil, .edu, .com, ., etc) and then delegate the hierarchy down to some owner. Top levels could be geographic based, provider based, based, and so on. Each of the top-levels might have its own plusses and minuses. For example, I imagine that provider-based addresses would be easier to aggregate into routes, at the expense of not being "portable" to different providers. An "owner-based" route (e.g. the top level of the hierarchy would be the equivalent of the DNS ftp.com) would be highly portable, but harder to aggregate. In turn, a provider might have different charging based on the type of address FTP wants to use. -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From owner-Big-Internet@munnari.oz.au Thu Feb 4 02:23:03 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA05695; Thu, 4 Feb 1993 02:23:10 +1100 (from owner-Big-Internet) Return-Path: Received: from mitsou.inria.fr by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05692; Thu, 4 Feb 1993 02:23:03 +1100 (from huitema@mitsou.inria.fr) Received: by mitsou.inria.fr (5.65c/IDA-1.2.8) id AA25613; Wed, 3 Feb 1993 16:25:44 +0100 Message-Id: <199302031525.AA25613@mitsou.inria.fr> To: kasten@ftp.com Cc: big-internet@munnari.oz.au Subject: Re: Metro Addressing Summary In-Reply-To: Your message of "Wed, 03 Feb 93 10:02:34 EST." <9302031502.AA17391@ftp.com> Date: Wed, 03 Feb 93 16:25:43 +0100 From: Christian Huitema Frank, I never dared saying that everybody agreed with my assertions, and in fact quoted the opposite argument later in the message. However, your statement that: Addresses MUST be very very tightly coupled to the topology. This is the definition of an address, since it defines a point on the topology. What MUST NOT be coupled to the topology in any way is the Endpoint Identifier. can be clearly demonstrated false by reductio ad absurdum. If the was no degree of liberty at all between addresses and topology, I would have to "renumber" my domains each time I "change the topology", e.g. each time I add a link to my network. I don't do that, and don't want to. Your assertion can also be demonstrated false by counter example. Networks have been demonstrated to work where the address has no relation whatsoever with the location -- a set of bridged Ethernets is a good example. The whole debate on EIDs is about whether one should have one single number space for both "endpoints" and "middlepoints" in the topology, or whether one should needs two. I prefer managing one single space, or more precisely using one single space for manging the internetworking. After all, we already have EIDs available through the DNS, if the applications need them. On the other hand, I think we agree on the plus and minuses of each strategy. The tighter the coupling between addresses and topology, the lesser the size of routing tables ... and also the lesser the "portability" or "flexibility". Christian Huitema From owner-Big-Internet@munnari.oz.au Thu Feb 4 03:03:08 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA06709; Thu, 4 Feb 1993 03:03:14 +1100 (from owner-Big-Internet) Return-Path: Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06706; Thu, 4 Feb 1993 03:03:08 +1100 (from dcrocker@Mordor.Stanford.EDU) Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA23791; Wed, 3 Feb 93 08:03:02 -0800 Message-Id: <9302031603.AA23791@Mordor.Stanford.EDU> To: minshall@wc.novell.com Cc: big-internet@munnari.oz.au Subject: Re: I-IP-P Org: The Branch Office, Sunnyvale CA Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Mon, 01 Feb 93 21:43:11 -0800. <9302020543.AB01409@wc.novell.com> Date: Wed, 03 Feb 93 08:03:01 -0800 From: Dave Crocker X-Mts: smtp Greg, What a clever idea. Define an "Inter-Internetwork Protocol Protocol" ("I-IP-P" - anyone seen "Charlotte's Web" recently?), which consists minimally of source and destination addresses and a protocol demultiplexer (but could include a hop count and/or checksum). Then, define how TCP, UDP, etc., run over I-IP-P (protocol numbers, how the pseudo-header checksum is computed, for example). Then, define how IP-IP-P runs over IPv4, SIP, PIP, TUBA, etc. In fact, it's such a good idea, I think it's already been done. It's the original IPAE spec, although the mapping to "lower layers" was only done for IP. But the IPAE-specific "mini-layer" had source/dest addresses and a multiplexing field. Ain't tunneling great? Dave From owner-Big-Internet@munnari.oz.au Thu Feb 4 03:12:48 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA06909; Thu, 4 Feb 1993 03:12:56 +1100 (from owner-Big-Internet) Return-Path: Message-Id: <9302031612.6909@munnari.oz.au> Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06906; Thu, 4 Feb 1993 03:12:48 +1100 (from yakov@watson.ibm.com) Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R2) with BSMTP id 5217; Wed, 03 Feb 93 11:12:45 EST Date: Wed, 3 Feb 93 11:12:44 EST From: yakov@watson.ibm.com To: Christian.Huitema@sophia.inria.fr, kasten@ftp.com Cc: big-internet@munnari.oz.au Subject: Metro Addressing Summary Ref: Your note of Wed, 03 Feb 93 16:25:43 +0100 >The tighter the coupling between addresses and topology, the lesser >the size of routing tables... and also the lesser the "portability" >or "flexibility". Christian, While your assertion about the size of routing tables is certainly true, your assertion about "portability" or "flexibility" true ONLY if you'll assume that address renumbering is an impossible (or very difficult) concept. If we assume that renumbering is possible, then we can "have our cake and eat it" -- have lesser size of routing tables, without sacrificing the "portability" or "flexibility". The above doesn't imply that renumbering is easy, but on the other hand, I don't think it belongs to the domain of rocket science either. Yakov. ake it work. (If someone out there believes that it doesn't really need a lot of mechanism, I will be delighted to see your specification which proves that point. Really.) One item concerning the range of schemes that are being contemplated: Since addressing is such a core part of the technology, models which substantially differ from those that have already been in use carry with them, in my opinion, inherently large risk. Since they haven't been used before -- or haven't been used in any large scale -- we can't claim to understand their physics. Since a clock is ticking on the Internet, we need to consider schemes which can be deployed reasonably soon, FOR PRODUCTION USE. Dave From owner-Big-Internet@munnari.oz.au Thu Feb 4 03:17:17 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA07024; Thu, 4 Feb 1993 03:17:24 +1100 (from owner-Big-Internet) Return-Path: Received: from interlock.ans.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07021; Thu, 4 Feb 1993 03:17:17 +1100 (from dennis@ans.net) Received: by interlock.ans.net id AA14879 (InterLock SMTP Gateway 1.1 for big-internet@munnari.oz.au); Wed, 3 Feb 1993 11:16:16 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 3 Feb 1993 11:16:16 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 3 Feb 1993 11:16:16 -0500 From: Dennis Ferguson Message-Id: <199302031616.AA20929@foo.ans.net> To: Christian Huitema Cc: Tony Li , big-internet@munnari.oz.au Subject: Re: Metro Addressing Summary In-Reply-To: (Your message of Wed, 03 Feb 93 09:10:56 GMT.) <199302030910.AA24443@mitsou.inria.fr.ans-relay> Date: Wed, 03 Feb 93 11:16:21 -0500 Christian, > * Geographical assignment of addresses is presented as one way to achieve this > objective -- if two networks are geographically near one other, chances are > that they will be also near oneother in the network topology. I think this is the primary point of misunderstanding about geographical assignment which exists, that is what is "topology"? When you connect to an IP service provider you are topologically closer to other customers of that provider, in terms of routing, than you are to customers of other providers. Period. This is in good measure a consequence of the IGP/EGP split we make in routing protocols. A destination which is reachable via IGP-derived routes is always considered "closer" than a destination which is reachable via EGP-derived routes. As a consequence, if you live in Boston and obtain your IP service from PSI, you are topologically closer to PSI's California customers than you are to the guy across the street who bought his service from NEARnet. This is an unavoidable result of the structure we give to the routing, as this is what defines "topology". And this would still be true even if PSI and NEARnet exchanged traffic with each other in Boston. Routing relationships define topology, not circuitry. If geographical assignment of addresses is required we are going to either have to restructure the way IP service is provisioned in geographical areas or invent new routing protocols. At the current state of the art the assertion of a causal connection between geography and topology made above is simply false. Dennis From owner-Big-Internet@munnari.oz.au Thu Feb 4 04:11:47 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA08244; Thu, 4 Feb 1993 04:11:56 +1100 (from owner-Big-Internet) Return-Path: Received: from OERV01.er.doe.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08239; Thu, 4 Feb 1993 04:11:47 +1100 (from hitchcoc@oerv01.er.doe.gov) Received: by er.doe.gov (5.57/OER-V1.0) id AA27208; Wed, 3 Feb 93 12:08:13 -0500 Date: Wed, 3 Feb 93 12:08:13 -0500 From: hitchcoc@oerv01.er.doe.gov (Dan Hitchcock) Message-Id: <9302031708.AA27208@er.doe.gov> To: Christian.Huitema@sophia.inria.fr, tli@cisco.com Subject: Re: Metro Addressing Summary Cc: big-internet@munnari.oz.au We need to make a clear distinction between EID's and Addresses. What users want from EID's 1) to be able to change providers without changing EID's 2) to be able to use EID's to find other users Addresses efficiently. 3) local control of at least some level(s) in the EID hierarchy to facilitate local management. 4) To be able to use EID's to determine multiple Addresses based on context: i.e., EID->IPv4 address, EID->CLNP NSAP, EID->SIP,PIP,... mappings should exist so only one EID plan needs to be maintained at local site. What Providers want from EID's 1) to be able to efficiently identify traffic from their customers and capture billing relevant data. 2) efficient mapping from EID pairs to routing info. What users want from Addresses: 1) efficient routing via their preferred carriers 2) firewalls between them and things that carriers change like carrier specific net topology. What carriers want from Addresses: 1) topologically relevant aggregation to support routing info compression 2) carrier - carrier and carrier-user accounting tools(could be done using EID's) 3) to be able to change routing info structure without affecting management of end user sites. The requirements for these two objecs are significantly different, which is why I believe EID's and Addresses need to be different objects. Comment: Within a local area which is at least as big as a metro area the routing topologies of different providers are likely to be similar. Note that the cost to construct a network is made up of the variable costs per network mile, the variable costs per network node(either end site or internal. Also note, that the right of way costs for using topology different than the existing rights of way are higher than stringing stuff on existing poles, etc. Therefore all network providers are trying to maximize the # of possible suscribers while minimizing the capital cost of providing the service. This is a highly constrained optimization problem.the location of the nodes of the resulting graph are fixed and the connectivity matrix of the nodes is also known because of the high cost of new rights of way,. All of these things drive local carriers to have similar topologies. In the case of long haul or backbone nets the density of connections is lower so the solutions tend to be more varied. If this is true then their are two important cases to consider EID's and addresses in all packets. EID's not in all packets. In the first case many of the "administrative functions" like determining what carrier a subscriber wants to use can be based on the EID's leaving Addresses to only wory about routing. In the second case, some of these administrative functions need to be dealt with efficiently by the Address structureIn this case, provider based addressing has a some real advantages IF address changes are transparent to users. However, if address change transparency cannot be achieved then the geography based address assignment might not be so bad because most providers will ahve similar metro topologies anyway. What is really required here is an address with a structure like: + with the same geography based address assignment for all providers. Dan Hitchcock From owner-Big-Internet@munnari.oz.au Thu Feb 4 05:14:18 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA10145; Thu, 4 Feb 1993 05:14:27 +1100 (from owner-Big-Internet) Return-Path: Received: from nero.clearpoint.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10142; Thu, 4 Feb 1993 05:14:18 +1100 (from martillo@nero.clearpoint.com) Received: by nero.clearpoint.com (4.1/1.34) id AA04632; Wed, 3 Feb 93 13:07:13 EST Date: Wed, 3 Feb 93 13:07:13 EST From: martillo@nero.clearpoint.com (Joachim Carlo Santos Martillo Ajami) Message-Id: <9302031807.AA04632@nero.clearpoint.com> To: Christian.Huitema@sophia.inria.fr, tli@cisco.com, big-internet@munnari.oz.au In-Reply-To: (Frank Kastenholz's message of Wed, 3 Feb 93 10:02:34 -0500 <9302031502.AA17391@ftp.com> Subject: Metro Addressing Summary Date: Wed, 3 Feb 93 10:02:34 -0500 To: Christian.Huitema@sophia.inria.fr Subject: Re: Metro Addressing Summary From: kasten@ftp.com (Frank Kastenholz) Christian, > * Many people believe that "addresses" should not be too tightly coupled to > the topology. Or at least, many can be coupled to have said precisely that. Addresses MUST be very very tightly coupled to the topology. This is the definition of an address, since it defines a point on the topology. What MUST NOT be coupled to the topology in any way is the Endpoint Identifier. Is this supposed to be a general principle? Certainly, one can build very complex physical network topologies with IEEE P802.1d MAC bridging, yet the physical addresses used in a given network are arbitrary. . . . All that we can honestly do is to specify that a hierarchy exists, define how to specify it, define the top levels (like .gov, .mil, .edu, .com, ., etc) and then delegate the hierarchy down to some owner. Top levels could be geographic based, provider based, based, and so on. Nameservice hierarchy and network topological hierarchy refer to structures which have no obligatory relationship. . . . -- Frank Kastenholz Joachim Carlo Santos Martillo Ajami From owner-Big-Internet@munnari.oz.au Thu Feb 4 05:18:39 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA10307; Thu, 4 Feb 1993 05:18:45 +1100 (from owner-Big-Internet) Return-Path: Received: from vela.acs.oakland.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10298; Thu, 4 Feb 1993 05:18:39 +1100 (from bill.simpson@um.cc.umich.edu) Received: from via.ws07.merit.edu by vela.acs.oakland.edu with SMTP id AA06548 (5.65c+/IDA-1.4.4); Wed, 3 Feb 1993 13:18:01 -0500 Date: Wed, 3 Feb 93 11:53:01 EDT From: "William Allen Simpson" Message-Id: <896.bill.simpson@um.cc.umich.edu> To: big-internet@munnari.oz.au Reply-To: bsimpson@morningstar.com Subject: Re: Metro Addressing Summary > > Are we agreed that (whether for actual routing or Endpoint Identifier), > > it is reasonable to design the numbering space in the following order? > > Frank Kastenholz writes: > No we are not agreed. Endpoints are numbers. They have ABSOLUTELY NO > TOPOLOGICAL SIGNIFICANCE. That is the whole point of having them > distinct from addresses which DO HAVE TOPOLOGICAL SIGNIFICANCE. > One might think from your response that I hadn't been around for rather a long time in this discussion. And that there wasn't an "or" in my statement. Apparently, you think that Endpoints are going to be administered in a single block with no structure. However, I do not believe that it will be practical to have every DNS maintain a complete copy of the entire Endpoint database, together with thousands of daily updates promulgated throughout the world. It makes sense to split the maintenance of Endpoint Identifiers along geographic lines. Particularly at planetary, continental, political and (I believe) metro boundaries, since these represent bottlenecks in the physical topology. This concept has been expressed repeatedly over the past several months. If you have an alternative organization, please let us know what it is. Tony Li writes: > No, not at all. Are you suggesting that there be fixed boundaries in > the address for each level? If so, what happens when you exhaust this > fragment? Are you suggesting this rigid format for the levels of > hierarchy? Why are you imposing such a structure on the world when > you need not do so? Unnecessary structure means that later you will > have to change (i.e., introduce a wart) when you need more flexibility. > Maybe you need to look at the plan that Steve Deering wrote for continental allocation. Right now, there's enough space in it to address every cell in every person currently living on the earth. He also left 3/4 of the space for future use. The format proposed is not rigid. It is variable based on the size of the blocks. But it isn't as "flexible" as an unbounded CLNP address :-) > > I have not heard any request for interstellar allocation. > It has been pointed out that the formal request has not yet arrived due to light speed considerations. > We seem to have reached consensus that the provider allocation must > definitely not span planets, or continents. > Tony Li again: > I would not agree about continents. I know of providers that span > continents. In some sense, "provider allocation" is a misnomer. It > really is "topology based allocation". I can imagine topologies in > which a provider (for various reasons) has links to a continent but is > not interconnected to the remainder of the Internet on that continent. > Forcing the provider to use the continental address in this case is a > major mistake. I would agree about planets, tho. ;-) > An non-interconnected provider would advertise its piece of the continental address block, and aggregation would be disrupted. The other continental providers would probably put pressure on the non-interconnected provider, so that they don't waste precious and expensive bandwith crossing oceans. Let's look at the converse. The provider-based addresses are assigned, and then the regional interconnect is added. In order to benefit, all of the sites would need to change their addresses, or the provider would need to advertise that it is the primary transit route for the other continent! Otherwise, the traffic still flows according to the old address scheme. As I said in my rationale, this plan puts the economic pressure for change and improvement where it belongs -- on the fewer providers, rather than the many sites. more Frank Kastenholz: > I still do not recall how a company, which might have several > providers, and its own internal, international, net would fit into this > scheme. FTP has two offices, one on the left coast and one on the right > coast. The left coast office might get connected via BARRNET, the right > coast office via NEARNET, the right coast office might also have a > PSI connection, _and_ we might have a private T1 line between the two. > > How would this be handled when we get a European office, with a private > T1 to our right-coast office, and an EARN connection? > I would like to expand upon Lars' earlier response. Under a metro assignment plan, each office would receive its own allocation, which would be related to the actual location, rather than company affiliation. The routes using the private links would simply have lower metrics. Right now, companies with bi-coastal and intercontinental connections receive all of their packets though a single NSFnet advertisement, because the "administrative domain" is based on the company, rather than the actual location or connectivity. This means that a packet originating on the left coast has to travel to the right coast, and then back across the private line to the left coast. Worse, packets originating overseas come to the US, and then travel back across the private oceanic line. And vice versa. Now it might be that in some cases the long private lines are faster, perhaps due to fewer hops or greater bandwidth. In this special case, the advertisements could easily continue to be set to encourage this pattern. Experience shows that in MOST current cases, the response is incredibly slow, and there are many extra hops involved. Moreover, this is clearly not an efficient use of resources. Bill.Simpson@um.cc.umich.edu From owner-Big-Internet@munnari.oz.au Thu Feb 4 05:51:31 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA11474; Thu, 4 Feb 1993 05:51:51 +1100 (from owner-Big-Internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11469; Thu, 4 Feb 1993 05:51:31 +1100 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA13945; Wed, 3 Feb 93 13:50:55 -0500 Date: Wed, 3 Feb 93 13:50:55 -0500 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9302031850.AA13945@ginger.lcs.mit.edu> To: Christian.Huitema@sophia.inria.fr, tli@cisco.com Subject: Re: Metro Addressing Summary Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu A couple of points: * A larger set of participants in the discussion agree that addresses should be "structured" so as to enable "aggregation" If you *don't* structure addresses (assuming "addresses" are the data that the routing passes around) to allow aggregation, the overhead cost of routing will be something like O(N), where N is the number of destinations in the network. This is clearly an unacceptable cost growth function in a network the size of the Internet. You *HAVE TO HAVE* aggregation, to get *better* routing overhead cost than O(N). * Geographical assignment of addresses is presented as one way to achieve this objective -- if two networks are geographically near one other, chances are that they will be also near oneother in the network topology. If you create an addressing abstractgion that contains things which are not topologically related, from the point of view of the routing, and reducing the routing overhead, you are absolutely wasting your time, and might as well have left them as separate entities. That's why I feel strongly that a topological relationship is *necessary* before doing any addressing abstraction (modulo partitioned networks, etc). Similarly, the idea that addresses should not follow network topology is also debated, e.g. by JNC who asserts that if an address does not contain routing information it is merely a binary name, an EID, that has always to be completed by a more significant "address". Two points about this. First, I don't think of an "address" as containing much routing information. My definition of an address is a structured name for a network interface; the structure is necessarily purely topological (but not sufficiently; it may also contain policy content), and thus *useful* to the routing. (There is a big debate over how the address abstraction hierarchy influences route choice which I don't have a big enough margin for, too.) Second, you don't *have* to have a more significant "address" if all you have is EID's. It just means that the routing has to track EID's directly, and thus you get a large cost function for routing overhead. Bridges (e.g. your typical Ethernet spanning tree bridge) work just fine this way. They just don't scale. One of the most obscure point in the debate is the definition of the alternative to geographical address, i.e. provider addressing. You seem to be assuming that provider addressing is *the* alternative to metro addressing. I'm not sure I agree, even if by "provider addressing" you really mean "network topology addressing". I tend to believe that we should first get an agreement on what we want to facilitate: cost efficient routing between quasi monopolistic regionals or customer hopping between competitive regionals. You seem to be building assumptions about user requirements into the basic design. I think this is bad system design, for two reasons. First, in a system that serves this large a community, different groups will want different things. Second, even if you have gauged the current desires correctly, over time what people want will almost certainly change. You should build a flexible system, one which, by being as close as possible to the underlying fundamental limits and mechanisms, allows choice as to exactly what you get out of it. (I have said this last point most murkily, I know; sorry! I don't have the words... :-) Noel From owner-Big-Internet@munnari.oz.au Thu Feb 4 05:55:20 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA11639; Thu, 4 Feb 1993 05:55:41 +1100 (from owner-Big-Internet) Return-Path: Received: from nero.clearpoint.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11624; Thu, 4 Feb 1993 05:55:20 +1100 (from martillo@nero.clearpoint.com) Received: by nero.clearpoint.com (4.1/1.34) id AA04683; Wed, 3 Feb 93 13:48:12 EST Date: Wed, 3 Feb 93 13:48:12 EST From: martillo@nero.clearpoint.com (Joachim Carlo Santos Martillo Ajami) Message-Id: <9302031848.AA04683@nero.clearpoint.com> To: Christian.Huitema@sophia.inria.fr, tli@cisco.com, big-internet@munnari.oz.au In-Reply-To: (Frank Kastenholz's message of Wed, 3 Feb 93 10:02:34 -0500 <9302031502.AA17391@ftp.com> Subject: Metro Addressing Summary Date: Wed, 3 Feb 93 10:02:34 -0500 To: Christian.Huitema@sophia.inria.fr Subject: Re: Metro Addressing Summary From: kasten@ftp.com (Frank Kastenholz) Christian, > * Many people believe that "addresses" should not be too tightly coupled to > the topology. Or at least, many can be coupled to have said precisely that. Addresses MUST be very very tightly coupled to the topology. This is the definition of an address, since it defines a point on the topology. What MUST NOT be coupled to the topology in any way is the Endpoint Identifier. Is this supposed to be a general principle? Certainly, one can build very complex physical network topologies with IEEE P802.1d MAC bridging, yet the physical addresses used in a given network are arbitrary. . . . All that we can honestly do is to specify that a hierarchy exists, define how to specify it, define the top levels (like .gov, .mil, .edu, .com, ., etc) and then delegate the hierarchy down to some owner. Top levels could be geographic based, provider based, based, and so on. Nameservice hierarchy and network topological hierarchy refer to structures which have no obligatory relationship. . . . -- Frank Kastenholz Joachim Carlo Santos Martillo Ajami From owner-Big-Internet@munnari.oz.au Thu Feb 4 05:56:00 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA11659; Thu, 4 Feb 1993 05:56:09 +1100 (from owner-Big-Internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11644; Thu, 4 Feb 1993 05:56:00 +1100 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA13972; Wed, 3 Feb 93 13:55:41 -0500 Date: Wed, 3 Feb 93 13:55:41 -0500 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9302031855.AA13972@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au, kasten@ftp.com Subject: Re: Metro Addressing Summary Cc: jnc@ginger.lcs.mit.edu Frank, I basically agree, with one minor tweak: define the top levels (like .gov, .mil, .edu, .com, ., etc) and then delegate the hierarchy down to some owner. Top levels could be geographic based, provider based, based, and so on. I think a potentially better system is one in which addresses grow from the bottom up, and you can always create a new top layer as needed. This will prevent political fights over allocation of "top level spots", and is a better fit to the way human organizations aggregate. Noel From owner-Big-Internet@munnari.oz.au Thu Feb 4 06:02:55 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA11793; Thu, 4 Feb 1993 06:03:08 +1100 (from owner-Big-Internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11787; Thu, 4 Feb 1993 06:02:55 +1100 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA14043; Wed, 3 Feb 93 14:02:28 -0500 Date: Wed, 3 Feb 93 14:02:28 -0500 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9302031902.AA14043@ginger.lcs.mit.edu> To: Christian.Huitema@sophia.inria.fr, kasten@ftp.com Subject: Re: Metro Addressing Summary Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu The whole debate on EIDs is about whether one should have one single number space for both "endpoints" and "middlepoints" in the topology, or whether one should needs two. In my mind, at least, they name completely separate kinds of things. "addresses" name network interfaces (i.e. points in the topology), and "EIDs" name computational 'objects' engaged in end-end communications, which have next to no relationship to the network communications substrate. After all, we already have EIDs available through the DNS, if the applications need them. Sort of. Reliable end-end communication protocols (e.g. TCP) don't name their peers in terms of them, and in any case, the extra layer of name mapping might be useful. The tighter the coupling between addresses and topology, the lesser the size of routing tables Absolutely! Noel From owner-Big-Internet@munnari.oz.au Thu Feb 4 06:07:11 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA11967; Thu, 4 Feb 1993 06:07:29 +1100 (from owner-Big-Internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11960; Thu, 4 Feb 1993 06:07:11 +1100 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA14103; Wed, 3 Feb 93 14:06:43 -0500 Date: Wed, 3 Feb 93 14:06:43 -0500 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9302031906.AA14103@ginger.lcs.mit.edu> To: Christian.Huitema@sophia.inria.fr, dcrocker@mordor.stanford.edu Subject: Re: Metro Addressing Summary Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu I'm inclined to believe that only concrete, detailed proposals should be discussed, rather than more general ideas. I agree that we need concrete, detailed proposals. On the other hand, I believe that abstract discussion has its place. Newton probably had a vague idea of the laws of motion before he stated them in succint mathematical form, yes? In fact, that vague level of understanding was probably a necessary precursor to the next step.... Noel From owner-Big-Internet@munnari.oz.au Thu Feb 4 06:17:49 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12259; Thu, 4 Feb 1993 06:18:08 +1100 (from owner-Big-Internet) Return-Path: Received: from babyoil.ftp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12254; Thu, 4 Feb 1993 06:17:49 +1100 (from kasten@ftp.com) Received: by ftp.com id AA27882; Wed, 3 Feb 93 14:17:41 -0500 Date: Wed, 3 Feb 93 14:17:41 -0500 Message-Id: <9302031917.AA27882@ftp.com> To: martillo@nero.clearpoint.com Subject: Re: Metro Addressing Summary From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: Christian.Huitema@sophia.inria.fr, tli@cisco.com, big-internet@munnari.oz.au > > * Many people believe that "addresses" should not be too tightly coupled to > > the topology. Or at least, many can be coupled to have said precisely that. > > Addresses MUST be very very tightly coupled to the topology. This is the > definition of an address, since it defines a point on the topology. What > MUST NOT be coupled to the topology in any way is the Endpoint Identifier. > > Is this supposed to be a general principle? Certainly, one can build > very complex physical network topologies with IEEE P802.1d MAC > bridging, yet the physical addresses used in a given network are > arbitrary. As the 802 'address' does not, in fact, identify a point on the network topology, it is not a true address. If I unplug my PC from the IP Subnet to which it is now attached, carry the PC to California, and plug it back in, the PC has changed its position on the network topology, however it will keep the same 802 number. The 802 number _is_, in fact, an end-point identifier. The fact that we call them addresses does not change this fact (I can call the thing I drive to work in each morning an apple, that doesn't mean that I can bake a pie with it). The Address/EID split does not imply that only one or the other can ever be used for forwarding packets through networks. Bridging, as a technique is certainly a valid technique for relatively "small" networks (typical rules of thumb that I've seen used for how big "too" big is 50-100 segments or 5,000 nodes; naturally this increases as bridges get more CPU and memory). I would also point out that one of the mechanisms discussed for assigning EIDs to nodes was to use the 802 number. > All that we can honestly do is to specify that a hierarchy exists, > define how to specify it, define the top levels (like .gov, .mil, > .edu, .com, ., etc) and then delegate the hierarchy > down to some owner. Top levels could be geographic based, provider > based, based, and so on. > > Nameservice hierarchy and network topological hierarchy refer to > structures which have no obligatory relationship. Never meant to imply that the DNS suggested network addressing hierarchies had a relationship. What I said (or meant to say) was that as we did for DNS, where we defined the top levels of the hierarchy very early on, delegated authority and let the delegated authorities define their own sub-hierarchies, we ought to do the same for hierarchical addressing (e.g. if the address begins with 0x00, the address is under the "metro/geographic" hierarchy, if 0x02, it is under the "service provider" hierarchy, and so on). -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From owner-big-internet@munnari.oz.au Thu Feb 4 07:56:13 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA14608; Thu, 4 Feb 1993 07:56:18 +1100 (from owner-big-internet) Return-Path: Message-Id: <9302032056.14608@munnari.oz.au> Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11761; Thu, 4 Feb 1993 06:00:21 +1100 (from yakov@watson.ibm.com) Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R2) with BSMTP id 7879; Wed, 03 Feb 93 14:00:13 EST Date: Wed, 3 Feb 93 14:00:13 EST From: yakov@watson.ibm.com To: martillo@nero.clearpoint.com, Christian.Huitema@sophia.inria.fr, big-internet@munnari.oz.au Subject: Metro Addressing Summary Ref: Your note of Wed, 3 Feb 93 13:07:13 EST >Is this supposed to be a general principle ? Certainly, one can >build very complex physical network topologies with IEEE P802.1d >MAC bridging, yet the physical addresses used in a given network >are arbitrary. Building complex topologies is certainly one of the issues. However, there is another thing to consider -- building LARGE topologies. So, the question to ask is how well IEEE P802.1d MAC bridging is suitable for building LARGE topologies. Yakov. From owner-Big-Internet@munnari.oz.au Thu Feb 4 07:51:24 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA14492; Thu, 4 Feb 1993 07:51:42 +1100 (from owner-Big-Internet) Return-Path: Received: from asylum.sf.ca.us by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14485; Thu, 4 Feb 1993 07:51:24 +1100 (from dab@asylum.sf.ca.us) Received: from dab.gate.epilogue.com by asylum.sf.ca.us via PCMAIL with DMSP id AA08501; Wed, 3 Feb 93 15:51:12 -0500 (EST) Date: Wed, 3 Feb 93 15:51:12 -0500 (EST) Message-Id: <9302032051.AA08501@asylum.sf.ca.us> To: kasten@FTP.COM Subject: Re: Metro Addressing Summary From: dab@asylum.sf.ca.us (David Bridgham) Reply-To: dab=replies@EPILOGUE.COM Cc: big-internet@MUNNARI.OZ.AU Sender: dab@asylum.sf.ca.us Repository: asylum Originating-Client: gate.epilogue.com > Date: Wed, 3 Feb 93 10:02:34 -0500 > To: big-internet@MUNNARI.OZ.AU > Subject: Re: Metro Addressing Summary > From: kasten@FTP.COM (Frank Kastenholz) > > All that we can honestly do is to specify that a hierarchy exists, > define how to specify it, define the top levels (like .gov, .mil, > .edu, .com, ., etc) and then delegate the hierarchy > down to some owner. Top levels could be geographic based, provider > based, based, and so on. Unless, of course, we take the nimrod style of heirarchical addresses where you just define the lowest layer (e.g. hardware interface) and let the address grow upwards as many layers as needed. We never have to define the top levels and get to avoid all the arguments and politics of who gets to be at the top. You also can add new levels to the top when you find that it's time to leave the planet or whatever comes next. Dave Bridgham From owner-big-internet@munnari.oz.au Thu Feb 4 08:19:09 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15033; Thu, 4 Feb 1993 08:19:14 +1100 (from owner-big-internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12129; Thu, 4 Feb 1993 06:15:12 +1100 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA14245; Wed, 3 Feb 93 14:14:44 -0500 Date: Wed, 3 Feb 93 14:14:44 -0500 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9302031914.AA14245@ginger.lcs.mit.edu> To: Christian.Huitema@sophia.inria.fr, dennis@ans.net Subject: Re: Metro Addressing Summary Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu When you connect to an IP service provider you are topologically closer to other customers of that provider, in terms of routing, than you are to customers of other providers. ... This is in good measure a consequence of the IGP/EGP split we make in routing protocols. A destination which is reachable via IGP-derived routes is always considered "closer" than a destination which is reachable via EGP-derived routes. Your first statement is true (on average), but not for the reason you gave. It would be true even in a system which did not have any EGP/IGP split (e.g. Nimrod). It is more caused by fundamentals such as the necessity to abstract roting information to manage network growth. This is an unavoidable result of the structure we give to the routing, as this is what defines "topology". I would have thought it was the other way around, that topology defines the 'envelope' of potential routing. E.g., I can't route directly from me to you, no matter how much I want to, unless there is a link there... If geographical assignment of addresses is required we are going to either have to restructure the way IP service is provisioned in geographical areas or invent new routing protocols. There is a third possibility, which is to accept a lot of overhead in the routing, due to use of addresses which are little related to actual nework topology. Noel From owner-big-internet@munnari.oz.au Thu Feb 4 09:02:27 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA16093; Thu, 4 Feb 1993 09:02:37 +1100 (from owner-big-internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12353; Thu, 4 Feb 1993 06:25:28 +1100 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA14288; Wed, 3 Feb 93 14:25:00 -0500 Date: Wed, 3 Feb 93 14:25:00 -0500 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9302031925.AA14288@ginger.lcs.mit.edu> To: Christian.Huitema@sophia.inria.fr, hitchcoc@oerv01.er.doe.gov, tli@cisco.com Subject: Re: Metro Addressing Summary Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu 2) to be able to use EID's to find other users Addresses efficiently. This might be a goal, but it's not one that I see as necessary. I think that we ought to pass EID's and addresses around as tuples the vast majority of the time, which would eliminate the need for efficient mapping. Can you explain why you feel that this is a requirement? 4) To be able to use EID's to determine multiple Addresses based on context: i.e., EID->IPv4 address, EID->CLNP NSAP, EID->SIP,PIP,... mappings should exist so only one EID plan needs to be maintained at local site. I'm not disagreeing with this one so much as just dubious that we are really going to have N (N > 1) internetworking layers deployed ubiquitously in the real world... 2) efficient mapping from EID pairs to routing info. If you change this to "forwarding info" I could probably agree.... if not, it turns into 2) above, since you use the addresses to route on, step A of doing what you say here is to convert the EID to an address, and I already questioned that one! :-) 2) firewalls between them and things that carriers change like carrier specific net topology. This is not possible if your goal is to have the addresses reflect something about the network topology, and where the named interface is in the topology. Noel From owner-big-internet@munnari.oz.au Thu Feb 4 09:58:14 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17872; Thu, 4 Feb 1993 09:58:19 +1100 (from owner-big-internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12698; Thu, 4 Feb 1993 06:39:28 +1100 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA14425; Wed, 3 Feb 93 14:38:59 -0500 Date: Wed, 3 Feb 93 14:38:59 -0500 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9302031938.AA14425@ginger.lcs.mit.edu> To: bsimpson@morningstar.com Subject: Re: Metro Addressing Summary Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu Apparently, you think that Endpoints are going to be administered in a single block with no structure. Clear statements to the contrary have been made by EID proponents. We clearly recognize the need for an administrative allocation structure. Note, however, this merely relates to *allocation*; it doesn't say anything about keeping *meaning* associated with the EID *once it has been allocated*. However, I do not believe that it will be practical to have every DNS maintain a complete copy of the entire Endpoint database, together with thousands of daily updates promulgated throughout the world. If you will recall (since you assert you've been around for rather a long time in this discussion :-), last summer Ross Callon and I went through this issue in detail, and I never proposed such a scheme. Perhaps you could consult the Big-I archive for details? It makes sense to split the maintenance of Endpoint Identifiers along geographic lines. It makes sense to split the *allocation* along political lines (although some international organizations, e.g. ITU, might also get chunks to manage), and since, at the country level, political boundaries follow geography, this makes sense. However, I violently oppose any *meaning* along geographic lines to EID's, since that defeats one of the chief goals of EID's, which is to be portable to anywhere in the network! The format proposed is not rigid. It is variable based on the size of the blocks. Yes, but is is flexible enough to be able to aggregate portions of the network topology about which you wish to make policy statements? I doubt it... the provider would need to advertise that it is the primary transit route for the other continent You seem to still be thinking in a Destination Vector model, where you pass routing tables around. Think in a map-based model instead. I'm convinced DV is not the wave of the future. Noel From owner-Big-Internet@munnari.oz.au Thu Feb 4 11:29:48 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA20245; Thu, 4 Feb 1993 11:30:05 +1100 (from owner-Big-Internet) Return-Path: Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20236; Thu, 4 Feb 1993 11:29:48 +1100 (from dcrocker@Mordor.Stanford.EDU) Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA05912; Wed, 3 Feb 93 16:29:40 -0800 Message-Id: <9302040029.AA05912@Mordor.Stanford.EDU> To: Dennis Ferguson Cc: big-internet@munnari.oz.au Subject: Re: Metro Addressing Summary Org: The Branch Office, Sunnyvale CA Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Wed, 03 Feb 93 11:16:21 -0500. <199302031616.AA20929@foo.ans.net> Date: Wed, 03 Feb 93 16:29:39 -0800 From: Dave Crocker X-Mts: smtp Question: ---- Included message: As a consequence, if you live in Boston and obtain your IP service from PSI, you are topologically closer to PSI's California customers than you are to the guy across the street who bought his service from NEARnet. I thought that the existence of Fix-east and Fix-west stood a chance of rendering this otherwise probable truth more debatable. Attempting some generality: The closer one is to an inter-carrier exchange, the more likely that provider-base addressing can be MISLEADING for routing to geogrpahically proximate neighbor. No? Dave From owner-big-internet@munnari.oz.au Thu Feb 4 14:57:03 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA27033; Thu, 4 Feb 1993 14:57:19 +1100 (from owner-big-internet) Return-Path: Message-Id: <9302040357.27033@munnari.oz.au> Received: from hadar.process.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15460; Thu, 4 Feb 1993 08:39:14 +1100 (from ULLMANN@PROCESS.COM) Date: Wed, 3 Feb 1993 16:36 -0500 From: ULLMANN@PROCESS.COM (Robert L Ullmann) To: big-internet@munnari.oz.au Subject: First draft for IPv7/RAP Hi, I have finally finished off the first draft of RAP, the route distribution and aggregation protocol for IPv7, the companion doc to draft-ullmann-ipv7. I know you've all been eagerly awaiting it. Right? It is now on world.std.com:pub/ipv7/rap.txt, I will submit it to the internet-drafts directory presently. Discussion on ipv7@world.std.com (requests to ipv7-request@world.std.com), or here if you think relevent. With my best regards, Robert Ullmann +1 508 879 6994 x226 (800) 722 7770 x226 From owner-Big-Internet@munnari.oz.au Thu Feb 4 14:54:30 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA26969; Thu, 4 Feb 1993 14:54:45 +1100 (from owner-Big-Internet) Return-Path: Received: from is.rice.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26959; Thu, 4 Feb 1993 14:54:30 +1100 (from bmanning@is.rice.edu) Received: by is.rice.edu (AA02274); Wed, 3 Feb 93 21:53:57 CST From: bmanning@is.rice.edu (William Manning) Message-Id: <9302040353.AA02274@is.rice.edu> Subject: Re: Metro Addressing Summary To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Date: Wed, 3 Feb 93 21:53:57 CST Cc: bsimpson@morningstar.com, big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu In-Reply-To: <9302031938.AA14425@ginger.lcs.mit.edu>; from "Noel Chiappa" at Feb 3, 93 2:38 pm X-Mailer: ELM [version 2.3 PL11] Noel, just what is your perceived difference between 48bit MAC numbers and your world view of EIDs? It seems to me that they could map, as long as the E only had one MAC to form its ID. The analogy breaks with multiple MACs, then you need something else as the EID. Or am I off base again? Dipping my toe back into this pond seems to bring this question to mind. -- Regards, Bill Manning bmanning@rice.edu PO Box 1892 713-285-5415 713-527-6099 Houston, Texas R.U. (o-kome) 77251-1892 ower latencies, and fewer participants. By the time the "discussion" gets to a list like this, I think it needs to be fairly well fleshed out, written down, and offered more as a detailed proposal than as assorted "thoughts". idea of the laws of motion before he stated them in succint mathematical fo rm, If he had started with an email discussion, it would have taken 3 months of debate to determine how important the use of an apple was. Dave From owner-big-internet@munnari.oz.au Thu Feb 4 15:26:21 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA27825; Thu, 4 Feb 1993 15:27:02 +1100 (from owner-big-internet) Return-Path: Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15579; Thu, 4 Feb 1993 08:43:41 +1100 (from tli@cisco.com) Received: by lager.cisco.com; Wed, 3 Feb 1993 13:43:08 -0800 Date: Wed, 3 Feb 1993 13:43:08 -0800 From: Tony Li Message-Id: <199302032143.AA16732@lager.cisco.com> To: jnc@ginger.lcs.mit.edu Cc: Christian.Huitema@sophia.inria.fr, tli@cisco.com, big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu In-Reply-To: Noel Chiappa's message of Wed, 3 Feb 93 13:50:55 -0500 <9302031850.AA13945@ginger.lcs.mit.edu> Subject: Metro Addressing Summary If you create an addressing abstraction that contains things which are not topologically related, from the point of view of the routing, and reducing the routing overhead, you are absolutely wasting your time, and might as well have left them as separate entities. That's why I feel strongly that a topological relationship is *necessary* before doing any addressing abstraction (modulo partitioned networks, etc). I'm not convinced. I _will_ agree that you need abstraction as you move up the hierarchy, but the entire concept of metro routing implies that the address flattens out below the metro level. This is wholly analogous to NSAP's, where you have hierarchy above the area, but within an area, addressing is completely flat. What does all of this mean? - The upper layers of the hierarchy MUST be tied to topology. - At some arbitrary level, some users may wish to dispense with topology based assignment. The cost is that there is no aggregation at that level. And that there must be complete topological interconnection at this level. Not using topological based assignment is wholly optional. - Below this level, there may also be aggregation since addressing can again be tied to topology. Please note that this would NOT preclude pure topological addressing. Example: A metro area has a prefix, P, a particular organization has an address O within that prefix. Within the organization,, topological addressing is again used, so that the topological local address is L. Thus, an address is P.O.L. Routing works by advertising P outside of the metro and P.O within the metro. Organizations are free to move within the metro area and there is no address change. But the metro area must again be a connected graph. Routing above the metro area is happy because aggregation of the metro area still suffices. Routing within the metro area is unhappy since it cannot aggregate organizations, but this is self-inflicted pain (which is ENTIRELY local). Routing within the organization is happy since it is again topological. Tony From owner-big-internet@munnari.oz.au Thu Feb 4 15:26:25 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA27826; Thu, 4 Feb 1993 15:27:02 +1100 (from owner-big-internet) Return-Path: Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20364; Thu, 4 Feb 1993 11:34:16 +1100 (from dcrocker@Mordor.Stanford.EDU) Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA05975; Wed, 3 Feb 93 16:33:34 -0800 Message-Id: <9302040033.AA05975@Mordor.Stanford.EDU> To: hitchcoc@oerv01.er.doe.gov (Dan Hitchcock) Cc: Christian.Huitema@sophia.inria.fr, tli@cisco.com, big-internet@munnari.oz.au Subject: EID vs Address (Re: Metro Addressing Summary) Org: The Branch Office, Sunnyvale CA Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Wed, 03 Feb 93 12:08:13 -0500. <9302031708.AA27208@er.doe.gov> Date: Wed, 03 Feb 93 16:33:34 -0800 From: Dave Crocker X-Mts: smtp Sorry if I missed the submission which answers this concern but I continue to be very frustrated with the discussion of EID vs. addresses, since I haven't seen enough detail in a spec to make the distinction real, short of noting address=something like the current IP address (but with more hierarchical structure based on some sort of topology/geography) and EID=domain name. Is there a detailed spec, somewhere, that makes all this concrete, rather than speculative? Is there any basis for knowing how such a spec will perform in the real world? Is there any sense of the risk of converting the Internet over to using it? Thanks, in advance. Dave From owner-big-internet@munnari.oz.au Thu Feb 4 16:09:37 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA29108; Thu, 4 Feb 1993 16:09:50 +1100 (from owner-big-internet) Return-Path: Message-Id: <9302040509.29108@munnari.oz.au> Received: from nic.near.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24998; Thu, 4 Feb 1993 14:06:15 +1100 (from jcurran@nic.near.net) To: Dave Crocker Cc: Dennis Ferguson , big-internet@munnari.oz.au Subject: Re: Metro Addressing Summary In-Reply-To: Your message of Wed, 03 Feb 93 16:29:39 -0800. <9302040029.AA05912@Mordor.Stanford.EDU> Date: Wed, 03 Feb 93 22:05:50 -0500 From: John Curran -------- ] From: Dave Crocker ] Subject: Re: Metro Addressing Summary ] Date: Wed, 03 Feb 93 16:29:39 -0800 ] ] Question: ] ] ---- Included message: ] ] As a consequence, if you live in Boston and obtain your IP service from ] PSI, you are topologically closer to PSI's California customers than you ] are to the guy across the street who bought his service from NEARnet. An accurate statement. You're topologically "close" to the majority of New England and several national networks (NSFNET, ESNET, Alternet). ] I thought that the existence of Fix-east and Fix-west stood a chance of ] rendering this otherwise probable truth more debatable. Attempting some ] generality: The closer one is to an inter-carrier exchange, the more likely ] that provider-base addressing can be MISLEADING for routing to geogrpahically ] proximate neighbor. No? Okay... Interchange locations such as the FIXes or the CIX do not provide any assurances that traffic wil find it way to the _closest_ interexchange point. Not all providers will subscribe to all interchange points, so traffic between provider-A and provider-B (without a common interchange point) will be based on A's policies for route acceptance until it reaches a transit network or the destination provider. Hence, being close to an "interchange" is meaningless, as that exchange may not be used by the source provider, destination provider, or may not offer a route to the destination provider due to the policies of the available transit networks. The creation of NAP's will not resolve this, as there will remain many private inter-provider exchanges. There is probably a dozen such locations in the US already. The assignment of topologically-based addresses provides little aggregation value unless the interconnection architecture is controlled or the usability of addresses is constrained to the current attachment point. Geographically- based addresses require the same concessions, but cannot provide the optimum aggregation available with topologically-based assignments. /John From owner-Big-Internet@munnari.oz.au Thu Feb 4 17:21:15 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA01574; Thu, 4 Feb 1993 17:21:34 +1100 (from owner-Big-Internet) Return-Path: Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01568; Thu, 4 Feb 1993 17:21:15 +1100 (from kre@cs.mu.OZ.AU) Received: from mundamutti.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.64+1.3.1+0.50); id AA09291 Thu, 4 Feb 1993 17:20:34 +1100 (from kre@cs.mu.OZ.AU) To: bmanning@is.rice.edu (William Manning) Cc: jnc@ginger.lcs.mit.edu (Noel Chiappa), big-internet@munnari.oz.au Subject: Re: Metro Addressing Summary In-Reply-To: Your message of "Wed, 03 Feb 1993 21:53:57 CST." <9302040353.AA02274@is.rice.edu> Date: Thu, 04 Feb 1993 17:20:14 +1100 Message-Id: <12747.728806814@cs.mu.OZ.AU> From: Robert Elz Date: Wed, 3 Feb 93 21:53:57 CST From: bmanning@is.rice.edu (William Manning) Message-ID: <9302040353.AA02274@is.rice.edu> Noel, just what is your perceived difference between 48bit MAC numbers and your world view of EIDs? I won't pretend to speak for Noel, but I believe that most of us don't see any huge difference, and EID just has to be a globally unique integer after all. Some of us don't like them for three reasons (and maybe more). 1) Not everything has a 48 bit MAC addr (eg: an older mac...) and there's no easy way to acquire single MAC addresses easily. 2) I would find it very hard to be convinced that all the MAC addresses (the ones supposed to be unique, ignore the decnet AA trash) are indeed unique, and that no manufacturer has ever assigned duplicate addresses and not rectified the situation - how would you ever know? 3) Some administrative structure to the addresses looks like it would be useful - so that it is reaosnable to register at least most of yor EID's in a directory that you have control over some segment of, rather than in some random directory somewhere assigned either to the manufacturer who assigned the address (assuming they're still solvent) or to some other random organisation. MAC addresses don't have that. kre From owner-Big-Internet@munnari.oz.au Thu Feb 4 21:27:16 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA08088; Thu, 4 Feb 1993 21:27:26 +1100 (from owner-Big-Internet) Return-Path: Received: from hpd.lut.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08081; Thu, 4 Feb 1993 21:27:16 +1100 (from J.P.Knight@lut.ac.uk) Received: from suna.lut.ac.uk by hpd.lut.ac.uk; Thu, 4 Feb 93 10:26:36 gmt Received: by suna.lut.ac.uk (4.1/SMI-4.1) id AA17925; Thu, 4 Feb 93 10:21:01 GMT Message-Id: <9302041021.AA17925@suna.lut.ac.uk> From: Jon Knight Subject: Re: Metro Addressing Summary To: dcrocker@Mordor.Stanford.EDU (Dave Crocker) Date: Thu, 4 Feb 93 10:20:59 GMT Cc: big-internet@MUNNARI.OZ.AU In-Reply-To: <9302032139.AA00256@Mordor.Stanford.EDU>; from "Dave Crocker" at Feb 3, 93 1:39 pm X-Mailer: ELM [version 2.3 PL0 (LUT)] > > > idea of the laws of motion before he stated them in succint mathematical > form, > > If he had started with an email discussion, it would have taken 3 months of > debate to determine how important the use of an apple was. > ...but someone may have pointed out that he shouldn't just assume that mass is a constant. ;-) Seriously, I personaly find the email discussions very interesting, and the idea that a small, closed body will come up with ideas behind closed doors a bit worrying (it sounds a bit too much like the international standards chaps rather than the Internet way). Surely the whole point of discussion is to throw the doors open to as many voices as possible *before* the ideas are set in stone (or rather programs)? That is one of the main uses of the Internet as far as I'm concerned, and long may it continue. Jon -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Jon Knight, Research Student in High Performance Networking and Distributed Systems in the Department of _Computer_Studies_ at Loughborough University. * Its not how big your share is, its how much you share that's important. * From owner-big-internet@munnari.oz.au Thu Feb 4 23:09:48 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA10940; Thu, 4 Feb 1993 23:09:50 +1100 (from owner-big-internet) Return-Path: Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04650; Thu, 4 Feb 1993 19:17:19 +1100 (from tli@cisco.com) Received: by lager.cisco.com; Thu, 4 Feb 1993 00:17:04 -0800 Date: Thu, 4 Feb 1993 00:17:04 -0800 From: Tony Li Message-Id: <199302040817.AA19773@lager.cisco.com> To: bill.simpson@um.cc.umich.edu ("William Allen Simpson") Cc: big-internet@munnari.oz.au Subject: Re: Metro Addressing Summary Bill, Tony Li writes: > No, not at all. Are you suggesting that there be fixed boundaries in > the address for each level? If so, what happens when you exhaust this > fragment? Are you suggesting this rigid format for the levels of > hierarchy? Why are you imposing such a structure on the world when > you need not do so? Unnecessary structure means that later you will > have to change (i.e., introduce a wart) when you need more flexibility. > Maybe you need to look at the plan that Steve Deering wrote for continental allocation. Right now, there's enough space in it to address every cell in every person currently living on the earth. So? More than 99.99% of the IPv4 space isn't really used yet (i.e., there are less than 430,000 addresses in use). You have to deal with massive losses due to allocation inefficiency. > I would not agree about continents. I know of providers that span > continents. In some sense, "provider allocation" is a misnomer. It > really is "topology based allocation". I can imagine topologies in > which a provider (for various reasons) has links to a continent but is > not interconnected to the remainder of the Internet on that continent. > Forcing the provider to use the continental address in this case is a > major mistake. I would agree about planets, tho. ;-) > An non-interconnected provider would advertise its piece of the continental address block, and aggregation would be disrupted. And thereby add noise to the system... The other continental providers would probably put pressure on the non-interconnected provider, so that they don't waste precious and expensive bandwith crossing oceans. Why? It's not like they can't charge back for it. Please remember, no matter what economic model you use, it trickles down: the users pay for everything. Let's look at the converse. The provider-based addresses are assigned, and then the regional interconnect is added. In order to benefit, all of the sites would need to change their addresses, or the provider would need to advertise that it is the primary transit route for the other continent! Otherwise, the traffic still flows according to the old address scheme. Not at all. Assuming that the transit did something intelligent, like reserve an aggregateable block for its operations on that continent, it is trivia itself. The transit advertises only that aggregate into the continental routing. If the transit chooses, it may wish to use its own intercontinental link for all of its routes. In this case, the transit then advertises its entire address block. Both add noise to the system, but this noise can be recovered by aggregation at some point near the other intercontinental links. Tony From owner-big-internet@munnari.oz.au Thu Feb 4 23:22:59 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA11211; Thu, 4 Feb 1993 23:23:05 +1100 (from owner-big-internet) Return-Path: Received: from mitsou.inria.fr by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06098; Thu, 4 Feb 1993 20:10:11 +1100 (from huitema@mitsou.inria.fr) Received: by mitsou.inria.fr (5.65c/IDA-1.2.8) id AA27247; Thu, 4 Feb 1993 10:12:42 +0100 Message-Id: <199302040912.AA27247@mitsou.inria.fr> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.oz.au Subject: Re: EGP/IGP split (was Metro Addressing Summary) In-Reply-To: Your message of "Wed, 03 Feb 93 14:14:44 EST." <9302031914.AA14245@ginger.lcs.mit.edu> Date: Thu, 04 Feb 93 10:12:41 +0100 From: Christian Huitema >Your first statement is true (on average), but not for the reason you gave. It >would be true even in a system which did not have any EGP/IGP split (e.g. >Nimrod). Noel, As mentioned by Dave Crocker, Email is a medium with limited capabilities. It is very adequate for exposing ideas, but not very adequate for leading to conclusions. Rather than repeating the same discussion again and again, we can however try to address one point you mentioned in your message -- the EGP/IGP split. In the current IP architecture, an IGP is run "within an autonomous system" composed of a set of networks. The AS is connected to the word by "external gateways". Do we want to keep this? In particular: 1) Do we want to keep the notion that independant addresses (non correlated network numbers) can be aggregated in an AS, or would we be better of if we imposed that all hosts within an AS are identified by a common address prefix? 2) Do we want to keep the notion of two different routing protocols, e.g. IGP that assume that all resources can be shared, EGP that incorporates policy constraints? 3) When multiple level of clustering are in effect, e.g. when a set of "AS" connected to the same "regional" (or metro, lets not debate that any more for a while), is the protocol we run within the cluster an "IGP" or an "EGP" ? I will just play dumb for a change, and lets the first one which risks an opinion be bashed instead of me... Christian Huitema From owner-big-internet@munnari.oz.au Thu Feb 4 23:39:21 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA11721; Thu, 4 Feb 1993 23:39:33 +1100 (from owner-big-internet) Return-Path: Received: from cheviot.ncl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08258; Thu, 4 Feb 1993 21:32:50 +1100 (from Tim.Dixon@newcastle.ac.uk) Received: from eata.ncl.ac.uk by cheviot.ncl.ac.uk id (5.65cVUW/NCL-CMA.1.35 for ) with SMTP; Thu, 4 Feb 1993 10:32:36 GMT From: "Tim.Dixon" Date: Thu, 4 Feb 1993 10:32:35 GMT Message-Id: To: big-internet@munnari.oz.au Subject: Re: Metro Addressing Summary Christian Huitema writes.. > Addresses MUST be very very tightly coupled to the topology. This is the > definition of an address, since it defines a point on the topology. What > MUST NOT be coupled to the topology in any way is the Endpoint Identifier. > >can be clearly demonstrated false by reductio ad absurdum. If the was no >degree of liberty at all between addresses and topology, I would have to >"renumber" my domains each time I "change the topology", e.g. each time I add >a link to my network. I don't do that, and don't want to. Actually, I don't think this is as absurd as it might appear. If there is an automatic process by which addresses can be assigned and their mapping to endpoint names updated, then why would you care if your address changed every day (well, you'd care because of cacheing of out-of-date addresses, but that's a different matter). I think we have to get away from a model in which an address can usefully be written down on a piece of paper and kept. I think it should also be a sine qua non of any new architecture that "renumbering", whether this is an automatically- or manually-initiated process and whatever the normal lifetime of addresses, should be a trivial operation. Tim From owner-Big-Internet@munnari.oz.au Fri Feb 5 01:25:26 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15182; Fri, 5 Feb 1993 01:25:35 +1100 (from owner-Big-Internet) Return-Path: Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15178; Fri, 5 Feb 1993 01:25:26 +1100 (from dcrocker@Mordor.Stanford.EDU) Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA20715; Thu, 4 Feb 93 06:25:07 -0800 Message-Id: <9302041425.AA20715@Mordor.Stanford.EDU> To: Jon Knight Cc: big-internet@MUNNARI.OZ.AU Subject: Re: Metro Addressing Summary Org: The Branch Office, Sunnyvale CA Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Thu, 04 Feb 93 10:20:59 +0000. <9302041021.AA17925@suna.lut.ac.uk> Date: Thu, 04 Feb 93 06:25:06 -0800 From: Dave Crocker X-Mts: smtp Jon, Your concern for keeping the process open is well-taken and a point of continuing concern around the IETF, IESG, IRTF, IAB, ISOC (which I've seen referenced as I**5). The challenge is to attend to that concern yet still get work done. In reality, most work is done by small, cohesive groups, using larger working groups as consultants, reviewers, and the like. When a smaller group (called, "design team" these days) deviates from group preferences and requirements too far, the work is rejected. I was certainly not suggesting that all real work must be done behind closed doors, rather that larger groups need relatively concrete material to chew on, most of the time. In particular, email seems not to be a good medium for extended consideration of fuzzy and/or negotiable issues. Email in a large group is even worse. Discussions tend to devolve into nit-picking details. Hence, major points often get lost. It doesn't seem to matter what the topic is or who the participants are. The difficulties seem to arise almost without exception. So I think it helps everyone to have complicated topics and discussions kept focussed by bringing ideas to the table in concrete form, whenever possible. Certainly there are times someone can and should submit a wild and crazy idea in preliminary form. But that usually should not be part of critical-path group decision making. It should be earlier than that phase of the effort, or it should be clearly distinguished from the critical-path effort. (E.g., "I realize that we've already dealt with this issue, but a major problem just occurred to me and I think a different aproach may solve it...what does everyone think about...?") Dave From owner-big-internet@munnari.oz.au Fri Feb 5 02:49:08 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17858; Fri, 5 Feb 1993 02:49:16 +1100 (from owner-big-internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17041; Fri, 5 Feb 1993 02:27:11 +1100 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA18500; Thu, 4 Feb 93 10:26:50 -0500 Date: Thu, 4 Feb 93 10:26:50 -0500 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9302041526.AA18500@ginger.lcs.mit.edu> To: bmanning@is.rice.edu Subject: Re: Metro Addressing Summary Cc: big-internet@munnari.oz.au Noel, just what is your perceived difference between 48bit MAC numbers and your world view of EIDs? Well, the chief difference is that a 48-bit MAC ID is the globally unique (allegedly :-), flat, meaningless name of an interface, whereas the EID is the g.u.f.m. name of a endpoint (the computational entity which is one end of a reliable end-end communication channel). They're both g.u.f.m. names (which is why they seem so similar) but the *class of things* they name are different. Remember, we have to distinguish between the *form* of a name, and the *thing* it names.... (Sorry to keep pounding that broken record everyone! :-). It seems to me that they could map, as long as the E only had one MAC to form its ID. The biggest problem is not "what do I do if I have two interfaces" (it's easy to pick one), but "what happens if my interface is unplugged, and stuck into some other machine". (This is a result of the point above, actually! :-) The MAC goes with the board, not the machine (in many cases). Which is not to say that MAC's couldn't be a source of EID's (as could 32 bit Internet addresses), we just have to work out how to handle things like this. Noel From owner-Big-Internet@munnari.oz.au Fri Feb 5 02:55:05 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17943; Fri, 5 Feb 1993 02:55:22 +1100 (from owner-Big-Internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17931; Fri, 5 Feb 1993 02:55:05 +1100 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA18598; Thu, 4 Feb 93 10:54:54 -0500 Date: Thu, 4 Feb 93 10:54:54 -0500 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9302041554.AA18598@ginger.lcs.mit.edu> To: jnc@ginger.lcs.mit.edu, tli@cisco.com Subject: Re: Metro Addressing Summary Cc: big-internet@munnari.oz.au If you create an addressing abstraction that contains things which are not topologically related, from the point of view of the routing, and reducing the routing overhead, you are absolutely wasting your time, and might as well have left them as separate entities. That's why I feel strongly that a topological relationship is *necessary* before doing any addressing abstraction (modulo partitioned networks, etc). I'm not convinced. Don't get me wrong, I'm not saying you can't create such naming abstractions, or that you can't make the routing function with them (at some cost), just that they aren't very useful to the routing. However, I think I detect (from your example) some misunderstanding of what I am saying. Let's look at your example, P.O.L, since I think it in fact does confirm exactly what I said. Things named P.O do have some topological relationship, since all P.* *are* within P. Likewise, all P.O.* are topologically related within the entity P.O. These parts of the address are, in fact, in agreement with my principle above. However, to investigate a hypothetical part which does conflict with my principle above, you can't divide O into two groups, O1 and O2, and use *those* as routing abstractions since all O names are not topologically related within P. If you did create such entities (O1 and O2) they would be useless to the routing. If O contains a large number of names (e.g. 10^6) routing at the O layer would probably be pretty expensive, which was part of the point of the *original* message some days ago that started all this. This is wholly analogous to NSAP's, where you have hierarchy above the area, but within an area, addressing is completely flat. Yes, and IS-IS routing has to track each and every Ethernet interface individually within an area! Could you really run a single IS-IS level 1 area to cover all the hosts in a city? And that there must be complete topological interconnection at this level. I assume you don't mean N^2 connections, just that you must be able to get from any P.O to any other P.O without leaving P? Even this is not absolutely necessary; you can use partioned network techniques to join together a disjoint P (much like IS-IS can work with partitioned level 1 areas). Routing within the metro area is unhappy since it cannot aggregate organizations, but this is self-inflicted pain (which is ENTIRELY local). Yes, it is local, but is it practical? It just seems to me that this is not the right mechanism (routing) to use to provide that capability (service mobility); the cost is very high for what you get. Noel From owner-Big-Internet@munnari.oz.au Fri Feb 5 03:50:53 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA19451; Fri, 5 Feb 1993 03:51:15 +1100 (from owner-Big-Internet) Return-Path: Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19434; Fri, 5 Feb 1993 03:50:53 +1100 (from dcrocker@Mordor.Stanford.EDU) Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA25028; Thu, 4 Feb 93 08:50:24 -0800 Message-Id: <9302041650.AA25028@Mordor.Stanford.EDU> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.oz.au Subject: Re: EID vs Address (Re: Metro Addressing Summary) Org: The Branch Office, Sunnyvale CA Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Thu, 04 Feb 93 11:02:40 -0500. <9302041602.AA18628@ginger.lcs.mit.edu> Date: Thu, 04 Feb 93 08:50:24 -0800 From: Dave Crocker X-Mts: smtp Noel, I think that this exchange is about to get to the point that it demonstrates exactly the sorts of difficulties I am claiming exist. ---- Included message: EID=domain name EID's have nothing to do with domain names. They are definitely a very What I have seen posted says that an EID refers to a host, rather than (for example) an interface, and further that the current global requirements call for a scheme of assignment which scales to allow global administration. In what ways does a domain name fail to satisfy these requirements? What other requirements have I missed? In terms of discussion process, I'll note that your response would have been more helpful if it had tended less towards blanket rejection and more toward searching out, suggesting, and responding to the weaknesses in my assertion. Such refinement of the debate is classic and required and would happen without thought were we in a high bandwitdh, low latency medium. The current inefficient exchange is typical of email. different kind of name, and since nobody ever told me for sure what kind of things a DNS name names (just that DNS names can be translated into existin Since a dns entry can point to multiple IP addresses, it most typically can be viewed as referring to a host. Taken literally, I suppose your first question could mean the IETF should ignore SIP until it has been deployed in an Internet-sized system. Clearly, that would be silly; we can Noel, a reductio ad absurdem response isn't helpful. In particularl, you haven't taken my comments literally, at all. I referred to a spec, not an implementation and certainly not an operational base. But let's pursue the SIP reference a bit further. The process for it was face-to-face exploratory conversations (no doubt with private email also), followed by a presentation (so that the slides consitute a preliminary form of spec, which is ok when the concepts and details are reasonably straightforward) followed by preliminary working group meetings. It would have been great to have a formal spec sooner, but there were enough pieces of documentation and there was a clear enough understanding of the topic and details among the primary discussants that progress was easy. Frankly, I don't think the same process would be possible with, for example PIP. (Please, don't anyone take this as criticism of PIP. Finish reading the paragraph.) PIP involves new concepts and details, of non-trivial nature. Hence, discussing it isn't trivial. Hence, documentation of the detail allows off-line consideration and concrete reference to definitions, formats, etc. I don't think I would want to be in the middle of a content-ful discussion of PIP without having a spec around. Another example of the difficulties of subtle discussion via email: The above paragraph contains a process-related caveat. I don't think it inappropriate to have included it, given the tendency of people to mis-read and over-react to messages. In email, such asides are highly distracting. In real-time conversation, they are almost un-noticed, most of the time. Dave From owner-big-internet@munnari.oz.au Fri Feb 5 04:35:11 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA20485; Fri, 5 Feb 1993 04:35:16 +1100 (from owner-big-internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18197; Fri, 5 Feb 1993 03:02:53 +1100 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA18628; Thu, 4 Feb 93 11:02:40 -0500 Date: Thu, 4 Feb 93 11:02:40 -0500 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9302041602.AA18628@ginger.lcs.mit.edu> To: dcrocker@mordor.stanford.edu, hitchcoc@oerv01.er.doe.gov Subject: Re: EID vs Address (Re: Metro Addressing Summary) Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu EID=domain name EID's have nothing to do with domain names. They are definitely a very different kind of name, and since nobody ever told me for sure what kind of things a DNS name names (just that DNS names can be translated into existing IP addresses), I can't even say for sure that they name the same class of objects. Is there any basis for knowing how such a spec will perform in the real world? Is there any sense of the risk of converting the Internet over to using it? I admit we need specs for things before they are really useful. This does not mean we can't have useful discussion without them. Taken literally, I suppose your first question could mean the IETF should ignore SIP until it has been deployed in an Internet-sized system. Clearly, that would be silly; we can extrapolate behaviour based on incomplete information. Some of us are happy to do that extrapolation based on less information that you. Do you mind? Noel From owner-big-internet@munnari.oz.au Fri Feb 5 04:45:56 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA20809; Fri, 5 Feb 1993 04:46:02 +1100 (from owner-big-internet) Return-Path: Received: from thumper.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18188; Fri, 5 Feb 1993 03:02:00 +1100 (from tsuchiya@thumper.bellcore.com) Received: from chiya.bellcore.com by thumper.bellcore.com (4.1/4.7) id for big-internet@munnari.oz.au; Thu, 4 Feb 93 11:01:52 EST Received: by chiya.bellcore.com (4.1/4.7) id for big-internet@munnari.oz.au; Thu, 4 Feb 93 11:01:50 EST Date: Thu, 4 Feb 93 11:01:50 EST From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Message-Id: <9302041601.AA19274@chiya.bellcore.com> To: Tim.Dixon@newcastle.ac.uk, big-internet@munnari.oz.au Subject: Re: Metro Addressing Summary > > Actually, I don't think this is as absurd as it might appear. If there is > an automatic process by which addresses can be assigned and their mapping to > endpoint names updated, then why would you care if your address changed every > day (well, you'd care because of cacheing of out-of-date addresses, but > that's a different matter). I think we have to get away from a model in which > an address can usefully be written down on a piece of paper and kept. Yes, absolutely. If you have a separate EID, then dealing with changing addresses becomes much easier. For instance, Pip has a "PCMP" message that tells a host when the ID to Address match is bad, and the host knows to flush its cache and go back to DNS...... Of course, you have to run DNS so that it does not cache info for long, but since Pip has an effective means of on-demand flushing, a Pip system can keep the info for a long time even though DNS has long flushed it..... > > I think it should also be a sine qua non of any new architecture that > "renumbering", whether this is an automatically- or manually-initiated process > and whatever the normal lifetime of addresses, should be a trivial operation. > Absolutely....... PX From owner-big-internet@munnari.oz.au Fri Feb 5 04:51:35 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA20952; Fri, 5 Feb 1993 04:51:39 +1100 (from owner-big-internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18609; Fri, 5 Feb 1993 03:18:39 +1100 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA18683; Thu, 4 Feb 93 11:18:23 -0500 Date: Thu, 4 Feb 93 11:18:23 -0500 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9302041618.AA18683@ginger.lcs.mit.edu> To: bmanning@is.rice.edu, kre@cs.mu.oz.au Subject: Re: Metro Addressing Summary Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu I won't pretend to speak for Noel !!! :-) all the MAC addresses ... are indeed unique, and that no manufacturer has ever assigned duplicate addresses and not rectified the situation Well, if someone has, and they get on the same, bridged, network, I'll bet is isn't going to work well! This raises a point I've thought about some; since I don't think we can absolutely guarantee that duplicate EID's never get issued (in error), the system ought to at least check for this possibility, and fail gracefully when it does happen. it is reaosnable to register at least most of yor EID's in a directory that you have control over some segment of, rather than in some random directory somewhere assigned either to the manufacturer who assigned the address (assuming they're still solvent) or to some other random organisation Good point. Ross and I (in our discussion last summer) touched on the problems with the latter course. I'd imagined something like ISOC would maintain the servers (for the unusual case when you do need an EID->something mapping), much as the NIC does the root DNS servers, but that's not a good model, since other organizations do maintain root servers as well; you want to allow local handling of this issue. Hmmm... Noel From owner-big-internet@munnari.oz.au Fri Feb 5 05:03:43 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21156; Fri, 5 Feb 1993 05:04:00 +1100 (from owner-big-internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18951; Fri, 5 Feb 1993 03:33:33 +1100 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA18870; Thu, 4 Feb 93 11:33:09 -0500 Date: Thu, 4 Feb 93 11:33:09 -0500 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9302041633.AA18870@ginger.lcs.mit.edu> To: Christian.Huitema@sophia.inria.fr, jnc@ginger.lcs.mit.edu Subject: Re: EGP/IGP split (was Metro Addressing Summary) Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu Rather than repeating the same discussion again and again Believe it or not, I'm actually pretty tired of it too! address one point you mentioned in your message -- the EGP/IGP split. Yes! In the current IP architecture, an IGP is run "within an autonomous system" composed of a set of networks. The AS is connected to the word by "external gateways". My answer is "sort of yes in spirit, absolutely no in the details". By this I mean that the architecture ought to provide for administrative control boundaries, and firewalls, but in a more flexible and sophisticated way than the current limited one level / all-or-nothing model. However, it should *absolutely* not be done through entirely separate designs for the local and global levels. Van Jacobsen has pointed out (and I take it to heart, Van :-) that routing probably wants to operate somewhat differently on local and global levels (e.g. change response time guarantees), and I concede that, but the overall system ought to have a common architecture, and common protocol, not like today with a LS IGP and a DV EGP. In a InArc retreat at San Diego, Sue Hares had a long list of issues with the way the current routing worked, and the cause of every one was the EGP/IGP split. Sure, we need autonomy and security, but not so rigid and limited. A well designed routing architecture ought not to need the design, implementation and operational expenses of entirely separate protocols at different layers.. Do we want to keep the notion that independant addresses (non correlated network numbers) can be aggregated in an AS This is the same as saying that there is no addressing structure above the AS. Hardly seems workable today... Noel From owner-big-internet@munnari.oz.au Fri Feb 5 05:14:14 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21347; Fri, 5 Feb 1993 05:14:18 +1100 (from owner-big-internet) Return-Path: Received: from transfer.stratus.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16587; Fri, 5 Feb 1993 02:11:02 +1100 (from jjmhome!crackers!nero.clearpoint.com!martillo@transfer.stratus.com) Received: from jjmhome.UUCP by transfer.stratus.com (4.1/3.12-jjm) id AA27691; Thu, 4 Feb 93 10:10:51 EST Received: by jjmhome.uucp (/\==/\ Smail3.1.25.1 #25.3) id ; Thu, 4 Feb 93 08:57 EST Received: from nero.clearpoint.com by crackers.clearpoint.com (5.65/CPI091290) id AA03220; Thu, 4 Feb 93 08:25:37 -0500 Received: by nero.clearpoint.com (4.1/1.34) id AA05363; Thu, 4 Feb 93 08:09:39 EST Date: Thu, 4 Feb 93 08:09:39 EST From: jjmhome!nero.clearpoint.com!martillo@transfer.stratus.com (Joachim Carlo Santos Martillo Ajami) Message-Id: <9302041309.AA05363@nero.clearpoint.com> To: Christian.Huitema@sophia.inria.fr, tli@cisco.com, big-internet@munnari.oz.au, jjmhome!big-internet%munnari.oz.au Cc: martillo@nero.clearpoint.com Subject: Metro Addressing Summary Date: Wed, 3 Feb 93 14:17:41 -0500 To: martillo@nero.clearpoint.com Subject: Re: Metro Addressing Summary From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: Christian.Huitema@sophia.inria.fr, tli@cisco.com, big-internet@munnari.oz.au > > * Many people believe that "addresses" should not be too tightly coupled to > > the topology. Or at least, many can be coupled to have said precisely that. > Addresses MUST be very very tightly coupled to the topology. This is the > definition of an address, since it defines a point on the topology. What > MUST NOT be coupled to the topology in any way is the Endpoint Identifier. > Is this supposed to be a general principle? Certainly, one can build > very complex physical network topologies with IEEE P802.1d MAC > bridging, yet the physical addresses used in a given network are > arbitrary. As the 802 'address' does not, in fact, identify a point on the network topology, it is not a true address. If I unplug my PC from the IP Subnet to which it is now attached, carry the PC to California, and plug it back in, the PC has changed its position on the network topology, however it will keep the same 802 number. This belief is a common misconception among engineers who do not understand the underlying mathematics of networks and who have been befuddled by the terminology associated with computer networks. If I take a Constellation Auriga (an EISA/ISA bus host resident bridge router), put it into a PC, configure it with two logical subbridges (Auriga IP interfaces), assign lb0 (logical subbridge 0) ip address netid0.hostid0, configure the Auriga to run the standard ip routing protocols, connect the PC ip interface to the same ip network as lb0 (i.e. give the PC ip address netid0.hostid1), I can move my PC to California connect lb1 to a local ip network running the standard ip routing protocols, get lb1 a local ip network address (either by manual assignment, by listening and challenge, by a dynamic ip address server if one is running or by some other procedure), and lo and behold my PC has changed its position in the network layer network topology and yet it has kept the same ip address and it talks to everybody in the ip internetwork just fine. On the other hand, I have a PC with a standard PRONET-10 adaptor and move it from one physical network to another, I could very well have to reconfigure the PC PRONET-10 adaptor physical address. In short, Kastenholz' example is completely meaningless. The 802 number _is_, in fact, an end-point identifier. The fact that we call them addresses does not change this fact (I can call the thing I drive to work in each morning an apple, that doesn't mean that I can bake a pie with it). For the IP router, the IP subnetwork ids label the endpoints between which the IP routers select paths. To consider "endpoint identifiers" entities fundamentally different from network "addresses" implies some serious confusion and misunderstanding of the mathematics which underlies computer networking technology. An analogy with telephony is relevant. Just because central office switches and toll switches work at different layers in the telephone network hierarchy, there is no reason to believe central office switches and toll switches do anything fundamentally different. The computer networking terminology may obscure the truth because a term is used for a MAC layer packet switch (bridge) which is completely different from the term for a network layer packet switch (router). Mathematically, there is no distinction between bridges and routers. Both bridges and routers switch packets on the basis of a topological path selection algorithm. It happens that P802.1d bridges use a broadcast path selection algorithm rather than a shortest path first selection algorithm as is commonly used for network layer packet switches. But such a happenstance is pure implementation decision. A MAC bridge could be implemented which used a shortest path first selection algorithm while a broadcast path selection algorithm like spanning tree could be used for network layer path selection. If Kastenholz had actually read and understood the P802.1d MAC bridging specification and the RFC 1247 OSPF Version 2 specification by J. Moy (who knows how to write an excellent specification document), he would note that spanning tree operates by pruning the equivalent topological graph where MAC bridges and LAN segments are vertices and MAC ports are graph arcs whereas OSPF procedures select paths through the equivalent topological graph (pp 3-6) where vertices are routers and networks while graph arcs are the links from the routers to the networks (except in the special case of unnumbered serial links). In OSPF, the network vertices are identified by network addresses (which contain the subnetwork id), which is a conventionalization to make exchanging path selection information simpler. In spanning tree, the LAN segment vertices could be viewed as identified by the MAC addresseses of attached end hosts. In effect, this conventionalization is used as part of the filtering procedure to cut down on network flooding. Just as there is no mathematical distinction between between first order packet switches (bridges) and second order packet switches (routers), there is no mathematical distinction between first order vertex labels (endpoint identifiers or MAC addresses which can be used to identify the LAN segment to which a communications subnet end host attaches) and second order vertex labels (network ids or network addresses which contain the network ids and which can be used to identify the network to which a network end host attaches). And here is the punch line: "Routers and bridges, from the standpoint of mathematical theory, perform the exact same sorts of mathematical operations on precisely the same sorts of mathematical objects and select paths between precisely the same sorts of mathematical objects which are called network addresses when path selection takes place at the network layer and which are called end point identifiers when path selection takes place at the MAC layer." Or to use Kastenholz' type of prosody, if he calls it mastication, and I call it chewing, we are still doing the same thing. Anyway, not realizing the basic mathematical equivalence of bridging and routing is only excusable in a very junior computer networking engineer. The Address/EID split does not imply that only one or the other can ever be used for forwarding packets through networks. Bridging, as a technique is certainly a valid technique for relatively "small" networks (typical rules of thumb that I've seen used for how big "too" big is 50-100 segments or 5,000 nodes; naturally this increases as bridges get more CPU and memory). Another ridiculous comment. Bridging as a technique is the same as routing as a technique. And these limits are technological (e.g. limited by medium bandwidth or access method) or implementation dependent (e.g. choosing a broadcast path selection algorithm like spanning tree) and are not fundamental to graph theory. Conservatively estimating, using current technology but a better path selection algorithm, bridges could probably be used to interconnect 10,000 nodes in a single subnetwork. Routers using appropriate path selection techniques at the network layer should be able to interconnect about 10,000 subnetworks. An internetwork so built using bridges to build subnetworks and routers judiciously to interconnect subnetworks should be able to provide connectivity for O(100,000,000) end hosts which would be a fair-sized network. The construction of very large internetworks becomes a much more tractable problem when first order packet switches (bridges) are used effectively in addition to second order packet switches (routers). And of course building wide-area backbones from (multiprotocol) routers is just silly and a waste of network addresses. I would also point out that one of the mechanisms discussed for assigning EIDs to nodes was to use the 802 number. -- Frank Kastenholz Joachim Carlo Santos Martillo Ajami The article represents noone's opinions other than the author's. P.S. I go through the analysis of bridging and routing in gory detail in a paper, "Routing in a Bridged Network" (rtebridg.ps), which is available on hsdndev.harvard.edu. From owner-Big-Internet@munnari.oz.au Fri Feb 5 05:28:42 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21695; Fri, 5 Feb 1993 05:29:07 +1100 (from owner-Big-Internet) Return-Path: Received: from babyoil.ftp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21668; Fri, 5 Feb 1993 05:28:42 +1100 (from kasten@ftp.com) Received: by ftp.com id AA25677; Thu, 4 Feb 93 13:28:30 -0500 Date: Thu, 4 Feb 93 13:28:30 -0500 Message-Id: <9302041828.AA25677@ftp.com> To: dcrocker@Mordor.Stanford.EDU Subject: Re: EID vs Address (Re: Metro Addressing Summary) From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: jnc@ginger.lcs.mit.edu, big-internet@munnari.oz.au > EID=domain name > > EID's have nothing to do with domain names. They are definitely a very > > What I have seen posted says that an EID refers to a host, rather than (for > example) an interface, and further that the current global requirements > call for a scheme of assignment which scales to allow global > administration. In what ways does a domain name fail to satisfy these > requirements? What other requirements have I missed? Dave, I contend that your definition of an EID is too limited. I think that an EID is the name of something that wishes to be known to the net. An EID can be: 1. A host 2. An interface of a host. 3. A Process on a specific host 4. A process that roams through the network (knowbots?) 5. Well known services, i.e. a process on any host (perhaps the DNS address respover is always EID number 882 and how I get from my PC to the local DNS resolver is a routing issue). 6. A person -- perhaps I would be EID #1 and would "sign in" to the network, and if you wanted to open a "talk" session with me you would open it to eid #1.... 7. etc The difference between Domain Names and EIDs is that Domain Names are intended to be easy for humans to understand, remember, and type, while the EID is something that can be carried around in packets. Other than that, I think that they are very similar, if not identical. -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From owner-big-internet@munnari.oz.au Fri Feb 5 05:44:53 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22013; Fri, 5 Feb 1993 05:45:24 +1100 (from owner-big-internet) Return-Path: Received: from asylum.sf.ca.us by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19264; Fri, 5 Feb 1993 03:45:18 +1100 (from dab@asylum.sf.ca.us) Received: from dab.gate.epilogue.com by asylum.sf.ca.us via PCMAIL with DMSP id AA14859; Thu, 4 Feb 93 11:44:58 -0500 (EST) Date: Thu, 4 Feb 93 11:44:58 -0500 (EST) Message-Id: <9302041644.AA14859@asylum.sf.ca.us> To: big-internet@MUNNARI.OZ.AU Subject: Re: EGP/IGP split (was Metro Addressing Summary) From: dab@asylum.sf.ca.us (David Bridgham) Reply-To: dab=replies@EPILOGUE.COM Sender: dab@asylum.sf.ca.us Repository: asylum Originating-Client: gate.epilogue.com > To: jnc@GINGER.LCS.MIT.EDU (Noel Chiappa) > Cc: big-internet@MUNNARI.OZ.AU > Subject: Re: EGP/IGP split (was Metro Addressing Summary) > In-Reply-To: Your message of "Wed, 03 Feb 93 14:14:44 EST." > <9302031914.AA14245@ginger.lcs.mit.edu> > Date: Thu, 04 Feb 93 10:12:41 +0100 > From: Christian Huitema > > >Your first statement is true (on average), but not for the reason you gave. It > >would be true even in a system which did not have any EGP/IGP split (e.g. > >Nimrod). > > In the current IP architecture, an IGP is run "within an autonomous system" > composed of a set of networks. The AS is connected to the word by "external > gateways". Do we want to keep this? In particular: The egp/igp split is a fixed, two-level heirarchy. A new system that supports as many networks and hosts as we're hoping for will need more than two levels to the heirarchy, probably a variable number over the system's lifetime. To my mind this leads inevitably to flushing the egp/igp split and accepting a fully heirarchical system where a given routing protocol may (will) run at multiple levels of the heirarchy. > 1) Do we want to keep the notion that independant addresses (non correlated > network numbers) can be aggregated in an AS, or would we be better of if > we imposed that all hosts within an AS are identified by a common address > prefix? Design the routing architecture first. Now pick an addressing form that helps routing. If the routing architecture is heirarchical then I'd bet that the best addresses are heiarchical and match the routing heirarchy. If we go with a heirarchical mapping scheme like nimrod, then the addresses (aka network attachment points) should reflect that heirarchy since it makes it easier to find the right maps (or at least a reasonable start) to plot your route. In either case there are groupings of networks (like ASs but multi-level) and addresses within the grouping have a common prefix. This is not something decided upon up front but falls out of the decision of the routing architecture. > 2) Do we want to keep the notion of two different routing protocols, e.g. IGP > that assume that all resources can be shared, EGP that incorporates policy > constraints? No. > 3) When multiple level of clustering are in effect, e.g. when a set of "AS" > connected to the same "regional" (or metro, lets not debate that any more > for a while), is the protocol we run within the cluster an "IGP" or an > "EGP" ? Call it what you want. > I will just play dumb for a change, and lets the first one which risks an > opinion be bashed instead of me... Maybe it's time to go on vacation for a couple days. Dave Bridgham From owner-big-internet@munnari.oz.au Fri Feb 5 06:23:10 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22831; Fri, 5 Feb 1993 06:23:22 +1100 (from owner-big-internet) Return-Path: Received: from babyoil.ftp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21669; Fri, 5 Feb 1993 05:28:43 +1100 (from kasten@ftp.com) Received: by ftp.com id AA25680; Thu, 4 Feb 93 13:28:32 -0500 Date: Thu, 4 Feb 93 13:28:32 -0500 Message-Id: <9302041828.AA25680@ftp.com> To: Christian.Huitema@sophia.inria.fr Subject: Re: EGP/IGP split (was Metro Addressing Summary) From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: jnc@ginger.lcs.mit.edu, big-internet@munnari.oz.au Christian, I _think_ that your note is implying a strict number of hierarchies in the routing, along with implying certain semantics based on the level of the hierarchy; that is, our current IGP/EGP split. (If this is _not_ what you meant, I am sorry). Anyway, forcing certain semantics on the routing, depending on the level in the hierarchy, is, I contend, a bad idea. No matter how many levels we have, no matter what level-based semantics we force, we will find that our hands will be tied; that some particular semantics will prevent us from doing something we want to do. > In the current IP architecture, an IGP is run "within an autonomous system" > composed of a set of networks. The AS is connected to the word by "external > gateways". Do we want to keep this? In particular: > > 1) Do we want to keep the notion that independant addresses (non correlated > network numbers) can be aggregated in an AS, or would we be better of if > we imposed that all hosts within an AS are identified by a common address > prefix? We should allow, endorse, strongly encourage, and perhaps provide almost unbearable pressure to force address assignments to allow for aggregation at each level of the hierarchy. After all, that is (we think :-) the key to dealing with the size of the network. However, to mandate that aggregation must be done at all times would be wrong. My model is that one of the charges that is levied on a lower element of the hierarchy by a higher element is based on the address that the lower element wishes to use. For example, the nets that NEARNET connects to might charge NEARNET X$ per address that NEARNET advertises. So, if NEARNET can aggregate the address for FTP with 9 other addresses, then FTP would only have to pay X/10$ to NEARNET since only one address would be advertised for all 10 sites. However, if, for some reason, FTP wanted its own address, which might not be "aggregateable" with the others, then FTP would have to pay the full X$. > > 2) Do we want to keep the notion of two different routing protocols, e.g. IGP > that assume that all resources can be shared, EGP that incorporates policy > constraints? We might want several different routing protocols, providing different types of services and functions, allowing each element of the hierarchy to make its own "cost-benefit" tradeoffs (maybe even RIP, it works fine for small net's -- calm down Noel! :-). To pre-ordain that there be only two of these protocols, and to pre-ordain their relationships (as we do with IGP/EGP today) would be wrong. > 3) When multiple level of clustering are in effect, e.g. when a set of "AS" > connected to the same "regional" (or metro, lets not debate that any more > for a while), is the protocol we run within the cluster an "IGP" or an > "EGP" ? -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From owner-Big-Internet@munnari.oz.au Fri Feb 5 07:24:23 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA23984; Fri, 5 Feb 1993 07:24:34 +1100 (from owner-Big-Internet) Return-Path: Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23981; Fri, 5 Feb 1993 07:24:23 +1100 (from tli@cisco.com) Received: by lager.cisco.com; Thu, 4 Feb 1993 12:24:10 -0800 Date: Thu, 4 Feb 1993 12:24:10 -0800 From: Tony Li Message-Id: <199302042024.AA18378@lager.cisco.com> To: jnc@ginger.lcs.mit.edu Cc: jnc@ginger.lcs.mit.edu, tli@cisco.com, big-internet@munnari.oz.au In-Reply-To: Noel Chiappa's message of Thu, 4 Feb 93 10:54:54 -0500 <9302041554.AA18598@ginger.lcs.mit.edu> Subject: Metro Addressing Summary This is wholly analogous to NSAP's, where you have hierarchy above the area, but within an area, addressing is completely flat. Yes, and IS-IS routing has to track each and every Ethernet interface individually within an area! Could you really run a single IS-IS level 1 area to cover all the hosts in a city? No, of course not. But the P.O.L model is slightly different. It means that you can make any level in the model flat. So at the metro level, you have a flat list of organizations, but the local addresses are still hierarchical. Could you really run a single ISIS level X process to cover all of the organizations in the city? Possibly. Depends on the city. In any case, the point of this model is that it makes it painful to those who do want to do metro addressing. They must commit, up front, to supporting the full number of entries for P.O addresses and decide the size of the address space that they want to be flat. I assume you don't mean N^2 connections, just that you must be able to get from any P.O to any other P.O without leaving P? Yah. Even this is not absolutely necessary; you can use partioned network techniques to join together a disjoint P (much like IS-IS can work with partitioned level 1 areas). True. However, I was trying to save the kludges till later. ;-) Routing within the metro area is unhappy since it cannot aggregate organizations, but this is self-inflicted pain (which is ENTIRELY local). Yes, it is local, but is it practical? It just seems to me that this is not the right mechanism (routing) to use to provide that capability (service mobility); the cost is very high for what you get. Absolutely. And those willing to pay it are welcome to do so. Those who don't want to pay it (e.g., hey, I live in East Timbuktu there's only one provider in my area ANYHOW) can do topological addressing AND they never see metro addresses, just aggregates. Tony From owner-big-internet@munnari.oz.au Fri Feb 5 07:42:18 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA24241; Fri, 5 Feb 1993 07:42:31 +1100 (from owner-big-internet) Return-Path: Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22020; Fri, 5 Feb 1993 05:45:53 +1100 (from dcrocker@Mordor.Stanford.EDU) Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA26415; Thu, 4 Feb 93 10:45:40 -0800 Message-Id: <9302041845.AA26415@Mordor.Stanford.EDU> To: kasten@ftp.com Cc: big-internet@munnari.oz.au Subject: Re: EID vs Address (Re: Metro Addressing Summary) Org: The Branch Office, Sunnyvale CA Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Thu, 04 Feb 93 13:28:30 -0500. <9302041828.AA25677@ftp.com> Date: Thu, 04 Feb 93 10:45:39 -0800 From: Dave Crocker X-Mts: smtp Frank, Yikes. Hadn't realized that EIDs were intended to be part of the general resource location exercise. This all leaves me even more interested in seeing specs, since the facility(ies?) implied sure would be powerful and useful. Dave From owner-big-internet@munnari.oz.au Fri Feb 5 08:39:57 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA25321; Fri, 5 Feb 1993 08:40:58 +1100 (from owner-big-internet) Return-Path: Message-Id: <9302042140.25321@munnari.oz.au> Received: from hadar.process.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23249; Fri, 5 Feb 1993 06:41:04 +1100 (from ULLMANN@PROCESS.COM) Date: Thu, 4 Feb 1993 14:39 -0500 From: ULLMANN@PROCESS.COM (Robert L Ullmann) To: big-internet@munnari.oz.au Subject: FWD: Re: EGP/IGP split (was Metro Addressing Summary) Hi, >From: jnc@ginger.lcs.mit.edu (Noel Chiappa) >Van Jacobsen has pointed out (and I take it to heart, Van :-) that routing >probably wants to operate somewhat differently on local and global levels >(e.g. change response time guarantees), and I concede that, but the overall >system ought to have a common architecture, and common protocol, not like >today with a LS IGP and a DV EGP. It's worse than that; usually it is DV LGP (RIP), LS IGP, and DV EGP. I agree that the IGP/EGP split is the source of a lot of the problems. The primary design focus of RAP is to have one common protocol for the whole range. The usefulness of DV at both ends of the range is instructive. Best Regards, Robert (see world.std.com:pub/ipv7/rap.txt) From owner-big-internet@munnari.oz.au Fri Feb 5 10:04:40 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA27700; Fri, 5 Feb 1993 10:04:42 +1100 (from owner-big-internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24911; Fri, 5 Feb 1993 08:24:35 +1100 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA26294; Thu, 4 Feb 93 16:24:24 -0500 Date: Thu, 4 Feb 93 16:24:24 -0500 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9302042124.AA26294@ginger.lcs.mit.edu> To: dcrocker@mordor.stanford.edu, kasten@ftp.com Subject: Re: EID vs Address (Re: Metro Addressing Summary) Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu This all leaves me even more interested in seeing specs, since the facility(ies?) implied sure would be powerful and useful. Unfortunately, I think the term "EID" is coming to cover as much ground as the term "address", which is sort of unfortunate, since when I created the term I did have a vey specific definition. Oh well... Noel From owner-big-internet@munnari.oz.au Fri Feb 5 11:04:20 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA29230; Fri, 5 Feb 1993 11:04:26 +1100 (from owner-big-internet) Return-Path: Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24353; Fri, 5 Feb 1993 07:48:30 +1100 (from tli@cisco.com) Received: by lager.cisco.com; Thu, 4 Feb 1993 12:48:14 -0800 Date: Thu, 4 Feb 1993 12:48:14 -0800 From: Tony Li Message-Id: <199302042048.AA19256@lager.cisco.com> To: martillo@nero.clearpoint.com Cc: Christian.Huitema@sophia.inria.fr, tli@cisco.com, big-internet@munnari.oz.au, martillo@nero.clearpoint.com In-Reply-To: Joachim Carlo Santos Martillo Ajami's message of Thu, 4 Feb 93 14:16:03 EST <9302041916.AA06051@nero.clearpoint.com> Subject: Metro Addressing Summary If I take a Constellation Auriga (an EISA/ISA bus host resident bridge router), put it into a PC, configure it with two logical subbridges (Auriga IP interfaces), assign lb0 (logical subbridge 0) ip address netid0.hostid0, configure the Auriga to run the standard ip routing protocols, connect the PC ip interface to the same ip network as lb0 (i.e. give the PC ip address netid0.hostid1), I can move my PC to California connect lb1 to a local ip network running the standard ip routing protocols, get lb1 a local ip network address (either by manual assignment, by listening and challenge, by a dynamic ip address server if one is running or by some other procedure), and lo and behold my PC has changed its position in the network layer network topology and yet it has kept the same ip address and it talks to everybody in the ip internetwork just fine. Bzzt. If NOTHING else, netid0 is not announced via exterior routing. Packets destined to netid0.hostid0 will not be delivered. I'm impressed by the fact that your mechanism requires you to change your IP address and you claim that it has not changed. For the IP router, the IP subnetwork ids label the endpoints between which the IP routers select paths. Bzzt. The IP router routes on different entities, depending on the proximity to the destination. Possible candidates include (but are NOT limited to) default, an aggregate, a network number, a summary route, a subnet number or a link layer address. To consider "endpoint identifiers" entities fundamentally different from network "addresses" implies some serious confusion and misunderstanding of the mathematics which underlies computer networking technology. Endpoint identifiers today ARE network addresses. This is a problem with the current model because it prevents relocation of the endpoint within the network. Consider the case of a VaxCluster. Suppose that you wish to connect to a particular service within the Cluster and that after connecting, the administrator decides to take that portion of the cluster down. While the service may be able to migrate to another processor, how do you migrate your network connection to another host within the cluster? The current hack would be to allocate another IP address as the cluster alias... Mathematically, there is no distinction between bridges and routers. Thanks, but there is. There is no aggregation of the address space in a bridge. Tony From owner-Big-Internet@munnari.oz.au Fri Feb 5 11:36:11 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA00405; Fri, 5 Feb 1993 11:37:33 +1100 (from owner-Big-Internet) Return-Path: Received: from dscs.arc.nasa.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00380; Fri, 5 Feb 1993 11:36:11 +1100 (from medin@nsipo.nasa.gov) Received: Thu, 4 Feb 93 16:14:06 PST from localhost.arc.nasa.gov by dscs.arc.nasa.gov (4.1/1.5T) Message-Id: <9302050014.AA02399@dscs.arc.nasa.gov> To: dab=replies@EPILOGUE.COM Cc: big-internet@munnari.oz.au Subject: Re: Metro Addressing Summary In-Reply-To: Your message of "Thu, 04 Feb 93 11:44:55 EST." <9302041644.AA14855@asylum.sf.ca.us> Date: Thu, 04 Feb 93 16:14:06 -0800 From: "Milo S. Medin" (NASA ARC NSI Office) Dave, 2 points: 1) Some protocols (ie DECNET IV) reprogram the MAC addresses on systems that run it, because they don't have an arp protocol. 2) Some hosts (ie Sun's) have the ethernet address stored on the CPU board, not the interfaces, so that a multihomed Sun would have the same MAC address on both ethernet interfaces. I think you're better off staying away from MAC addresses since they are used for a lot of odd things, especially by some other protocols. Thanks, Milo From owner-big-internet@munnari.oz.au Fri Feb 5 12:23:36 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA01789; Fri, 5 Feb 1993 12:23:51 +1100 (from owner-big-internet) Return-Path: Message-Id: <9302050123.1789@munnari.oz.au> Received: from nic.near.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24913; Fri, 5 Feb 1993 08:24:38 +1100 (from jcurran@nic.near.net) To: kasten@ftp.com Cc: Christian.Huitema@sophia.inria.fr, jnc@ginger.lcs.mit.edu, big-internet@munnari.oz.au Subject: Re: EGP/IGP split (was Metro Addressing Summary) In-Reply-To: Your message of Thu, 04 Feb 93 13:28:32 -0500. <9302041828.AA25680@ftp.com> Date: Thu, 04 Feb 93 16:24:14 -0500 From: John Curran -------- ] From: Frank Kastenholz ] Subject: Re: EGP/IGP split (was Metro Addressing Summary) ] Date: Thu, 4 Feb 93 13:28:32 -0500 ] ] ... ] We should allow, endorse, strongly encourage, and perhaps provide almost ] unbearable pressure to force address assignments to allow for aggregation ] at each level of the hierarchy. After all, that is (we think :-) the ] key to dealing with the size of the network. However, to mandate that ] aggregation must be done at all times would be wrong. ] ] My model is that one of the charges that is levied on a lower element ] of the hierarchy by a higher element is based on the address that the ] lower element wishes to use. For example, the nets that NEARNET ] connects to might charge NEARNET X$ per address that NEARNET ] advertises. So, if NEARNET can aggregate the address for FTP with 9 ] other addresses, then FTP would only have to pay X/10$ to NEARNET ] since only one address would be advertised for all 10 sites. However, ] if, for some reason, FTP wanted its own address, which might not be ] "aggregateable" with the others, then FTP would have to pay the full ] X$. If the network providers can directly account for the costs of maintaining a routing entry, and these costs are relatively high, then there will be natural economic incentives to recover those costs by a per-route charge. This could happen in order to recover internal equipment costs, OR as a result of a per-route charge imposed by a transit provider. Hence, your model is sound, and will probably be inevitable just prior to IP network depletion. (Once depletion occurs, there will be a tendency to balkanize and all bets are off...) /John From owner-big-internet@munnari.oz.au Fri Feb 5 16:36:55 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA10379; Fri, 5 Feb 1993 16:37:01 +1100 (from owner-big-internet) Return-Path: Received: from nero.clearpoint.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22829; Fri, 5 Feb 1993 06:23:16 +1100 (from martillo@nero.clearpoint.com) Received: by nero.clearpoint.com (4.1/1.34) id AA06051; Thu, 4 Feb 93 14:16:03 EST Date: Thu, 4 Feb 93 14:16:03 EST From: martillo@nero.clearpoint.com (Joachim Carlo Santos Martillo Ajami) Message-Id: <9302041916.AA06051@nero.clearpoint.com> To: Christian.Huitema@sophia.inria.fr, tli@cisco.com, big-internet@munnari.oz.au Cc: martillo@nero.clearpoint.com Subject: Metro Addressing Summary Date: Wed, 3 Feb 93 14:17:41 -0500 To: martillo@nero.clearpoint.com Subject: Re: Metro Addressing Summary From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: Christian.Huitema@sophia.inria.fr, tli@cisco.com, big-internet@munnari.oz.au > > * Many people believe that "addresses" should not be too tightly coupled to > > the topology. Or at least, many can be coupled to have said precisely that. > Addresses MUST be very very tightly coupled to the topology. This is the > definition of an address, since it defines a point on the topology. What > MUST NOT be coupled to the topology in any way is the Endpoint Identifier. > Is this supposed to be a general principle? Certainly, one can build > very complex physical network topologies with IEEE P802.1d MAC > bridging, yet the physical addresses used in a given network are > arbitrary. As the 802 'address' does not, in fact, identify a point on the network topology, it is not a true address. If I unplug my PC from the IP Subnet to which it is now attached, carry the PC to California, and plug it back in, the PC has changed its position on the network topology, however it will keep the same 802 number. This belief is a common misconception among engineers who do not understand the underlying mathematics of networks and who have been befuddled by the terminology associated with computer networks. If I take a Constellation Auriga (an EISA/ISA bus host resident bridge router), put it into a PC, configure it with two logical subbridges (Auriga IP interfaces), assign lb0 (logical subbridge 0) ip address netid0.hostid0, configure the Auriga to run the standard ip routing protocols, connect the PC ip interface to the same ip network as lb0 (i.e. give the PC ip address netid0.hostid1), I can move my PC to California connect lb1 to a local ip network running the standard ip routing protocols, get lb1 a local ip network address (either by manual assignment, by listening and challenge, by a dynamic ip address server if one is running or by some other procedure), and lo and behold my PC has changed its position in the network layer network topology and yet it has kept the same ip address and it talks to everybody in the ip internetwork just fine. On the other hand, I have a PC with a standard PRONET-10 adaptor and move it from one physical network to another, I could very well have to reconfigure the PC PRONET-10 adaptor physical address. In short, Kastenholz' example is completely meaningless. The 802 number _is_, in fact, an end-point identifier. The fact that we call them addresses does not change this fact (I can call the thing I drive to work in each morning an apple, that doesn't mean that I can bake a pie with it). For the IP router, the IP subnetwork ids label the endpoints between which the IP routers select paths. To consider "endpoint identifiers" entities fundamentally different from network "addresses" implies some serious confusion and misunderstanding of the mathematics which underlies computer networking technology. An analogy with telephony is relevant. Just because central office switches and toll switches work at different layers in the telephone network hierarchy, there is no reason to believe central office switches and toll switches do anything fundamentally different. The computer networking terminology may obscure the truth because a term is used for a MAC layer packet switch (bridge) which is completely different from the term for a network layer packet switch (router). Mathematically, there is no distinction between bridges and routers. Both bridges and routers switch packets on the basis of a topological path selection algorithm. It happens that P802.1d bridges use a broadcast path selection algorithm rather than a shortest path first selection algorithm as is commonly used for network layer packet switches. But such a happenstance is pure implementation decision. A MAC bridge could be implemented which used a shortest path first selection algorithm while a broadcast path selection algorithm like spanning tree could be used for network layer path selection. If Kastenholz had actually read and understood the P802.1d MAC bridging specification and the RFC 1247 OSPF Version 2 specification by J. Moy (who knows how to write an excellent specification document), he would note that spanning tree operates by pruning the equivalent topological graph where MAC bridges and LAN segments are vertices and MAC ports are graph arcs whereas OSPF procedures select paths through the equivalent topological graph (pp 3-6) where vertices are routers and networks while graph arcs are the links from the routers to the networks (except in the special case of unnumbered serial links). In OSPF, the network vertices are identified by network addresses (which contain the subnetwork id), which is a conventionalization to make exchanging path selection information simpler. In spanning tree, the LAN segment vertices could be viewed as identified by the MAC addresseses of attached end hosts. In effect, this conventionalization is used as part of the filtering procedure to cut down on network flooding. Just as there is no mathematical distinction between between first order packet switches (bridges) and second order packet switches (routers), there is no mathematical distinction between first order vertex labels (endpoint identifiers or MAC addresses which can be used to identify the LAN segment to which a communications subnet end host attaches) and second order vertex labels (network ids or network addresses which contain the network ids and which can be used to identify the network to which a network end host attaches). And here is the punch line: "Routers and bridges, from the standpoint of mathematical theory, perform the exact same sorts of mathematical operations on precisely the same sorts of mathematical objects and select paths between precisely the same sorts of mathematical objects which are called network addresses when path selection takes place at the network layer and which are called end point identifiers when path selection takes place at the MAC layer." Or to use Kastenholz' type of prosody, if he calls it mastication, and I call it chewing, we are still doing the same thing. Anyway, not realizing the basic mathematical equivalence of bridging and routing is only excusable in a very junior computer networking engineer. The Address/EID split does not imply that only one or the other can ever be used for forwarding packets through networks. Bridging, as a technique is certainly a valid technique for relatively "small" networks (typical rules of thumb that I've seen used for how big "too" big is 50-100 segments or 5,000 nodes; naturally this increases as bridges get more CPU and memory). Another ridiculous comment. Bridging as a technique is the same as routing as a technique. And these limits are technological (e.g. limited by medium bandwidth or access method) or implementation dependent (e.g. choosing a broadcast path selection algorithm like spanning tree) and are not fundamental to graph theory. Conservatively estimating, using current technology but a better path selection algorithm, bridges could probably be used to interconnect 10,000 nodes in a single subnetwork. Routers using appropriate path selection techniques at the network layer should be able to interconnect about 10,000 subnetworks. An internetwork so built using bridges to build subnetworks and routers judiciously to interconnect subnetworks should be able to provide connectivity for O(100,000,000) end hosts which would be a fair-sized network. The construction of very large internetworks becomes a much more tractable problem when first order packet switches (bridges) are used effectively in addition to second order packet switches (routers). And of course building wide-area backbones from (multiprotocol) routers is just silly and a waste of network addresses. I would also point out that one of the mechanisms discussed for assigning EIDs to nodes was to use the 802 number. -- Frank Kastenholz Joachim Carlo Santos Martillo Ajami The article represents noone's opinions other than the author's. P.S. I go through the analysis of bridging and routing in gory detail in a paper, "Routing in a Bridged Network" (rtebridg.ps), which is available on hsdndev.harvard.edu. From owner-big-internet@munnari.oz.au Fri Feb 5 20:56:20 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA19322; Fri, 5 Feb 1993 20:56:24 +1100 (from owner-big-internet) Return-Path: Received: from mitsou.inria.fr by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16393; Fri, 5 Feb 1993 19:16:29 +1100 (from huitema@mitsou.inria.fr) Received: by mitsou.inria.fr (5.65c/IDA-1.2.8) id AA29274; Fri, 5 Feb 1993 09:18:59 +0100 Message-Id: <199302050818.AA29274@mitsou.inria.fr> To: kasten@ftp.com Cc: big-internet@munnari.oz.au Subject: Re: EGP/IGP split (was Metro Addressing Summary) In-Reply-To: Your message of "Thu, 04 Feb 93 13:28:32 EST." <9302041828.AA25680@ftp.com> Date: Fri, 05 Feb 93 09:18:57 +0100 From: Christian Huitema Frank, My wife must be right -- I certainly have a problem with my English. For I certainly did not meant to mandate, advise, or whatever, a fixed number of hierarchies in the routing. In fact, the SIP spec, to which I contributed, specifies an undefined number of hierarchically organized 'clusters'. What I observed was that the current IP architecture does have an EGP/IGP split, and so does the current CLNP architecture, and a couple of others probably too. There was in fact one big rationale for this -- mapping the network structure to the "organisation" structure, and having special optimisations within an organisation's network where all the resources are owned by one single entity. We have a challenge here. I can easily understand how a DV protocol, which is only concerned with "local scope", could manage and aggregate variable length submasks -- we might have to do some specification work though, e.g. how to run a hierachy of BGP's and RIP's. Why I do not see clearly is whether we can have a hierarchy of LS protocols without either fixed length tokens or heavy manual configurations. Christian Huitema PS. But maybe I am just one of those dumb engineers who do not understand the underlying mathematics of networks and who have been befuddled by the terminology associated with computer networks... From owner-Big-Internet@munnari.oz.au Sat Feb 6 01:21:28 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA27176; Sat, 6 Feb 1993 01:21:40 +1100 (from owner-Big-Internet) Return-Path: Received: from babyoil.ftp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27173; Sat, 6 Feb 1993 01:21:28 +1100 (from kasten@ftp.com) Received: by ftp.com id AA12318; Fri, 5 Feb 93 09:21:25 -0500 Date: Fri, 5 Feb 93 09:21:25 -0500 Message-Id: <9302051421.AA12318@ftp.com> To: Christian.Huitema@sophia.inria.fr Subject: Re: EGP/IGP split (was Metro Addressing Summary) From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: big-internet@munnari.oz.au > > My wife must be right -- I certainly have a problem with my English. For I > certainly did not meant to mandate, advise, or whatever, a fixed number of > hierarchies in the routing. In fact, the SIP spec, to which I contributed, > specifies an undefined number of hierarchically organized 'clusters'. I wasn't sure, which is why I prefaced my note as I did. > What I observed was that the current IP architecture does have an EGP/IGP split, > and so does the current CLNP architecture, and a couple of others probably > too. There was in fact one big rationale for this -- mapping the network > structure to the "organisation" structure, and having special optimisations > within an organisation's network where all the resources are owned by one > single entity. This mapping, while useful, is something that I feel that we should not mandate in the architecture. We can allow it. Perhaps we should encourage it in our engineering decisions since this mapping might, in fact, be the one that is used 75% of the time. Mandating such a scheme means that some people, for whom a there might be a better scheme, would lose. > We have a challenge here. I can easily understand how a DV protocol, which is > only concerned with "local scope", could manage and aggregate variable length > submasks -- we might have to do some specification work though, e.g. how to > run a hierachy of BGP's and RIP's. Why I do not see clearly is whether we can > have a hierarchy of LS protocols without either fixed length tokens or heavy > manual configurations. We already do this. Suppose that NEARNET uses OSPF internally for their routing. OSPF would pass around routing information for 128.127, which is FTP's network. However, internal to FTP we have subnetted our net. We've already aggregated the topological information. OSPF treats all of FTP's networks as a single vertex on the graph, named 128.127. If the addressing was truly hierarchical (e.g. 128 meant nearnet and 128.127 meant FTP in NEARNET) then this could be continued up the hierarchy. If the NSFNET backbones did LS routing, then NEARNET would appear on their network as a single vertex, labelled 128. The complexity seems to me to be at the routers that are at the hierarchy border. In my example, the router that connects FTP to NEARNET would have to perform the correct aggregation -- keeping all of the various 128.127.x routes on the "FTP side" and only advertising up to the higher level of the hierarchy (NEARNET) 128.127. > But maybe I am just one of those dumb engineers who do not > understand the underlying mathematics of networks and who have been > befuddled by the terminology associated with computer networks... You and me both. But then, that's probably how we've managed to build the Internet -- we don't know what we are doing so we don't know when we are trying to do something that is impossible so we end up doing it. -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From owner-Big-Internet@munnari.oz.au Sat Feb 6 01:41:26 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA27757; Sat, 6 Feb 1993 01:41:54 +1100 (from owner-Big-Internet) Return-Path: Received: from [140.185.30.10] by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27743; Sat, 6 Feb 1993 01:41:26 +1100 (from jonson@server.af.mil) Received: by server.af.mil (5.59/25-eef) id AA02336; Fri, 5 Feb 93 08:28:04 CST From: Matt Jonson Message-Id: <9302051428.AA02336@server.af.mil> Subject: Re: Metro Addressing Summary To: martillo@nero.clearpoint.com (Joachim Carlo Santos Martillo Ajami) Date: Fri, 5 Feb 93 8:28:02 CST Cc: Christian.Huitema@sophia.inria.fr, tli@cisco.com, big-internet@munnari.oz.au, martillo@nero.clearpoint.com In-Reply-To: <9302041916.AA06051@nero.clearpoint.com>; from "Joachim Carlo Santos Martillo Ajami" at Feb 4, 93 2:16 pm X-Mailer: ELM [version 2.3 PL11] > Subject: Metro Addressing Summary > > As the 802 'address' does not, in fact, identify a point on the > network topology, it is not a true address. If I unplug my PC from the > IP Subnet to which it is now attached, carry the PC to California, and > plug it back in, the PC has changed its position on the network > topology, however it will keep the same 802 number. > > This belief is a common misconception among engineers who do not > understand the underlying mathematics of networks and who have been > befuddled by the terminology associated with computer networks. Since we are talking about an IP network topology, an 802 address *is* meaningless at the IP level. > If I take a Constellation Auriga (an EISA/ISA bus host resident bridge > router), put it into a PC, configure it with two logical subbridges > (Auriga IP interfaces), assign lb0 (logical subbridge 0) ip address > netid0.hostid0, configure the Auriga to run the standard ip routing > protocols, connect the PC ip interface to the same ip network as lb0 > (i.e. give the PC ip address netid0.hostid1), I can move my PC to > California connect lb1 to a local ip network running the standard ip > routing protocols, get lb1 a local ip network address (either by !!! > manual assignment, by listening and challenge, by a dynamic ip address > server if one is running or by some other procedure), and lo and > behold my PC has changed its position in the network layer network > topology and yet it has kept the same ip address and it talks to > everybody in the ip internetwork just fine. Sure looks to me like you're 1) Depending on IP routing protocols to communicate 2) changing an IP address so, you aren't bridging. In fact your example would work only because you have a portable IP router with a private IP network behind it. -- Lt Matthew W Jonson jonson@server.af.mil snail-mail: Network Systems Engineer 205-416-4075 SSC/SSDN USAF DDN Program Office AV: 596-4075 Gunter AFB, AL 36114 From owner-Big-Internet@munnari.oz.au Sat Feb 6 03:18:36 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA00843; Sat, 6 Feb 1993 03:18:51 +1100 (from owner-Big-Internet) Return-Path: Received: from vela.acs.oakland.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00840; Sat, 6 Feb 1993 03:18:36 +1100 (from bill.simpson@um.cc.umich.edu) Received: from via.ws04.merit.edu by vela.acs.oakland.edu with SMTP id AA04564 (5.65c+/IDA-1.4.4); Fri, 5 Feb 1993 11:18:13 -0500 Date: Fri, 5 Feb 93 10:41:07 EDT From: "William Allen Simpson" Message-Id: <901.bill.simpson@um.cc.umich.edu> To: big-internet@munnari.oz.au Reply-To: bsimpson@morningstar.com Subject: Number Allocation Summary > From: Dave Crocker > Sorry to be so negative. I think that the discussion need higher > bandwidith, lower latencies, and fewer participants. By the time the > "discussion" gets to a list like this, I think it needs to be fairly > well fleshed out, written down, and offered more as a detailed > proposal than as assorted "thoughts". > Which is what I did in my summary. This allowed specific challenges to a proposed plan. The result is that we have CLEAR AGREEMENT from the principles from three of the four number space allocation schemes (Geographic, Provider, and EndPoint) on several elements. That is, that the upper most "allocation" can be aggregated at 1) planetary 2) continental There is less agreement on where the allocation divisions are placed at the international (or inter-regional) level. However, there seems to be a consensus that this can remain a regional issue. There is no agreement as to whether metropolitan should preceed or follow provider, except that IP4 class C numbering doesn't have enough space for the metro division. Finally, there is agreement that there may be exceptions, but workable solutions have been proposed for handling those exceptions (for example, a provider which has a non-interconnected intercontinental link which doesn't conform to the numbering space for that continent). We achieved this by agreeing that the number space represents only an allocation/administration method, and is not tied to any particular routing technique. The result is that the various techniques can all proceed with testing while using the same numbering space. I consider this a real advance. Bill.Simpson@um.cc.umich.edu From owner-big-internet@munnari.oz.au Sat Feb 6 05:01:26 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03548; Sat, 6 Feb 1993 05:01:31 +1100 (from owner-big-internet) Return-Path: Received: from inet-gw-1.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27415; Sat, 6 Feb 1993 01:28:40 +1100 (from oran@sneezy.lkg.dec.com) Received: by inet-gw-1.pa.dec.com; id AA06243; Fri, 5 Feb 93 06:28:33 -0800 Received: by sneezy.lkg.dec.com (5.65/DEC-Ultrix/4.3) id AA16008; Fri, 5 Feb 1993 09:28:31 -0500 To: "Milo S. Medin" (NASA ARC NSI Office) Subject: Re: Ethernet IDs as EIDs (was: Metro Addressing Summary) In-Reply-To: <9302050014.AA02399@dscs.arc.nasa.gov> References: <9302050014.AA02399@dscs.arc.nasa.gov> Cc: big-internet@munnari.oz.au X-Mailer: Poste 2.1 From: David Oran Date: Fri, 5 Feb 93 09:28:27 -0500 Message-Id: <930205092827.586@sneezy.lkg.dec.com.-v> Encoding: 30 TEXT, 6 TEXT SIGNATURE > 2) Some hosts (ie Sun's) have the ethernet address stored on the CPU board, > not the interfaces, so that a multihomed Sun would have the same MAC address > on both ethernet interfaces. > Are you saying the ID ROMs are *only* on the CPU module and not on the Ethernet interfaces as well? That would be a dangerous situation. What if you happen to plug both interfaces into the same cable, or worse, into two segments on opposite sides of a MAC Bridge? If the ROMs are on both the interfaces and the CPU, then Sun actually did the "right thing", something I've had mixed success in getting DEC to do. This allows you to have the best of both worlds - an automatic, manufacturer-assigned EID, *and* independence from a particular Datalink Layer address. Perhaps those who argue strenuously that Ethernet MAC addresses weren't designed to be used as EIDs ought to dig out the paper by Bob Printis of Xerox PARC which he wrote *before* the 10megabit Ethernet shipped which talked about the 48bit numbers as *host ids*, which, by lucky coincidence, could also be used as MAC addresses. (I believe it was published in the proceedings of the 6th Data Comm. symposium - the one on Cape Cod in 1983). But, then again, some of us old farts labor under the disadvantage of knowing the history of all this stuff... -+-+-+-+-+-+-+ David R. Oran Phone: + 1 508 486-7377 Digital Equipment Corporation Fax: + 1 508 486-5279 LKG 1-2/A19 Email: oran@lkg.dec.com 550 King Street Littleton, MA 01460 From owner-Big-Internet@munnari.oz.au Sat Feb 6 06:09:26 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA05964; Sat, 6 Feb 1993 06:09:34 +1100 (from owner-Big-Internet) Return-Path: Received: from MITCHELL.CIT.CORNELL.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05961; Sat, 6 Feb 1993 06:09:26 +1100 (from jch@nr-tech.cit.cornell.edu) Received: from MITCHELL.CIT.CORNELL.EDU by mitchell.cit.cornell.edu (4.1/1.34/Honig-1.3) id AA29284; Fri, 5 Feb 93 14:08:01 EST Message-Id: <9302051908.AA29284@mitchell.cit.cornell.edu> To: David Oran Cc: big-internet@munnari.oz.au Subject: Re: Ethernet IDs as EIDs (was: Metro Addressing Summary) In-Reply-To: Message from David Oran on Fri, 05 Feb 1993 09:28:27 -0500.<930205092827.586@sneezy.lkg.dec.com.-v> Organization: Information Technologies/Network Resources; Cornell University, Ithaca, NY X-Mailier: MH-E [version 3.7+] MH [version 6.8] Date: Fri, 05 Feb 1993 14:08:00 -0500 From: Jeffrey C Honig > > > 2) Some hosts (ie Sun's) have the ethernet address stored on the CPU board, > > not the interfaces, so that a multihomed Sun would have the same MAC address > > on both ethernet interfaces. > > > Are you saying the ID ROMs are *only* on the CPU module and not on > the Ethernet interfaces as well? > > That would be a dangerous situation. What if you happen to plug > both interfaces into the same cable, or worse, into two segments > on opposite sides of a MAC Bridge? Then you have to manually change one of the MAC addresses (ifconfig le1 ether xx:xx:xx:xx:xx:xx). But the default is to use the MAC address stored in ROM on the CPU module for all interfaces (at least all ethernet interfaces I haven't seen a Sun FDDI interface). Jeff From owner-Big-Internet@munnari.oz.au Sat Feb 6 06:35:47 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA06807; Sat, 6 Feb 1993 06:35:58 +1100 (from owner-Big-Internet) Return-Path: Received: from iitmax.acc.iit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06804; Sat, 6 Feb 1993 06:35:47 +1100 (from nelsgar@elof.iit.edu) Received: from elof.iit.edu by iitmax.acc.iit.edu with SMTP id AA28241 (5.64+/IDA/NIU-1.3.1 for big-internet@munnari.oz.au); Fri, 5 Feb 93 13:34:59 -0600 Received: by elof.iit.edu (NX5.67c/NX3.0S) id AA02985; Fri, 5 Feb 93 13:34:57 -0600 Date: Fri, 5 Feb 93 13:34:57 -0600 From: Gary Nelson Message-Id: <9302051934.AA02985@elof.iit.edu> To: bill.simpson@um.cc.umich.edu, kasten@ftp.com, tli@cisco.com Subject: Re: Metro Addressing Summary Cc: big-internet@munnari.oz.au I think consideration should be given to wireless internet services where the concept of an d endpoint is an individual not a place. The personal Communications Services crowd expects to issue a personal telephone number that is valid for a lifetime. No telling where this concept will lead us - smartchip implanted under the skin of the left hand at birth. In this context, MAC addresses are like the serial number on an automobile that an individual owns for a while and then sells or discards. Not the material for an endpoint identifier. A personal endpoint identifier is more like a social security number. Best gn From owner-Big-Internet@munnari.oz.au Sat Feb 6 06:57:43 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA07459; Sat, 6 Feb 1993 06:57:55 +1100 (from owner-Big-Internet) Return-Path: Received: from OPAL.ACC.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AB07454; Sat, 6 Feb 1993 06:57:43 +1100 (from art@opal.acc.com) Received: by opal.acc.com (4.1/SMI-4.0) id AA24461; Fri, 5 Feb 93 11:59:46 PST Date: Fri, 5 Feb 93 11:59:46 PST From: art@opal.acc.com (Art Berggreen) Message-Id: <9302051959.AA24461@opal.acc.com> To: oran@sneezy.lkg.dec.com Subject: Re: Ethernet IDs as EIDs (was: Metro Addressing Summary) Cc: big-internet@munnari.oz.au >> >Are you saying the ID ROMs are *only* on the CPU module and not on >the Ethernet interfaces as well? > >That would be a dangerous situation. What if you happen to plug >both interfaces into the same cable, or worse, into two segments >on opposite sides of a MAC Bridge? What do bridges do if a Decnet router gets two Ethernet interfaces plugged into the same cable? The same MAC address will show up on all interfaces. Same is probably true of many XNS and IPX systems. Art From owner-Big-Internet@munnari.oz.au Sat Feb 6 08:47:02 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA10642; Sat, 6 Feb 1993 08:47:22 +1100 (from owner-Big-Internet) Return-Path: Received: from Sun.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10623; Sat, 6 Feb 1993 08:47:02 +1100 (from Bob.Gilligan@Eng.Sun.COM) Received: from Eng.Sun.COM (zigzag-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA24992; Fri, 5 Feb 93 13:46:53 PST Received: from bigriver.Eng.Sun.COM (bigriver-248) by Eng.Sun.COM (4.1/SMI-4.1) id AB12472; Fri, 5 Feb 93 13:49:41 PST Received: from kandinsky.Eng.Sun.COM by bigriver.Eng.Sun.COM (4.1/SMI-4.1) id AA22290; Fri, 5 Feb 93 13:46:46 PST Date: Fri, 5 Feb 93 13:46:46 PST From: Bob.Gilligan@Eng.Sun.COM (Bob Gilligan) Message-Id: <9302052146.AA22290@bigriver.Eng.Sun.COM> To: big-internet@munnari.oz.au Subject: Re: Ethernet IDs as EIDs (was: Metro Addressing Summary) Content-Length: 1618 > From: David Oran > Date: Fri, 5 Feb 93 09:28:27 -0500 > . . . > > 2) Some hosts (ie Sun's) have the ethernet address stored on the > > CPU board, not the interfaces, so that a multihomed Sun would have > > the same MAC address on both ethernet interfaces. > > > Are you saying the ID ROMs are *only* on the CPU module and not on > the Ethernet interfaces as well? That is correct. All Sun machines store a single ethernet address in the NVRAM on the CPU board. All of the SunOS ethernet drivers pick this address up at boot time and store it in a per-interface data structure. > That would be a dangerous situation. What if you happen to plug > both interfaces into the same cable, or worse, into two segments > on opposite sides of a MAC Bridge? We have been shipping systems like this for 10 years and haven't received many complaints. Generally speaking, people who setup multihomed IP hosts connect the interfaces to different IP subnets. > Date: Fri, 05 Feb 1993 14:08:00 -0500 > From: Jeffrey C Honig > . . . > Then you have to manually change one of the MAC addresses (ifconfig > le1 ether xx:xx:xx:xx:xx:xx). But the default is to use the MAC > address stored in ROM on the CPU module for all interfaces (at least > all ethernet interfaces I haven't seen a Sun FDDI interface). That's correct. Each interface starts off using the ethernet address from the NVRAM, but you can change the ethernet address per-interface if you want to. This has a variety of application. We use "ifconfig ... ether ..." in our DECNET product, for example. From owner-Big-Internet@munnari.oz.au Sat Feb 6 08:51:23 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA10775; Sat, 6 Feb 1993 08:51:48 +1100 (from owner-Big-Internet) Return-Path: Received: from nissan.cc.iastate.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10766; Sat, 6 Feb 1993 08:51:23 +1100 (from grpjl@iastate.edu) Received: by iastate.edu with sendmail-5.57/4.7 id ; Fri, 5 Feb 93 15:51:05 -0600 Message-Id: <9302052151.AA12662@iastate.edu> To: big-internet@munnari.oz.au Subject: The big picture Date: Fri, 05 Feb 93 15:51:05 CST From: Paul Lustgraaf I think some folks may be losing sight of the big picture. The hierarchy we use for addresses JUST DOESN'T MATTER. No USER is ever going to have to type in (or even know) what his machines's address is, that should all be determined automatically. The USER will only have to know one thing: the NAME of the machine he is trying to connect to. Only people who run routers and name servers should even know what kind of addressing is being used. Its all very dynamic. The process should work something like this: 1. My machine boots up, finds an interface, asks it what its MAC address is. 2. My machine then fires off a broadcast using the DHCP/BOOTP protocol or something like it which asks for an address. 3. The ROUTER fills in the network location information and forwards the request to a server. 4. This server program is a combination DHCP/BOOTP and DNS server. Using either information pre-entered by the manager (for well-known or mobile hosts) or some sort of dynamic allocation, it records the network address of this host and returns a reply giving the machine its name. Note that the manager needs to know only the MAC address of the machine in order to assign a name, something every good manager should record anyway. 5. If the machine is moved, the server notes the fact by comparing the new address to the address in its records and sends a forwarding address (with an time-to-live value) to the OLD router. This enables name server caches to continue to work. This scheme has several good effects: 1. Machine setup is much easier for both the user and the manager. 2. Mobile machines can be handled quite well. 3. It makes user education much easier. We no longer have to teach them about network addresses at all! Only about names, which, of course, have been designed for humans to deal with. 4. If our company changes location or picks another provider, all we have to do is tell our ROUTERS and NAME servers and reboot our machines. No sweat. I look forward to comments on this issue. Paul Lustgraaf "Its easier to apologize than to get permission." Network Specialist Grace Hopper Iowa State University Computation Center grpjl@iastate.edu Ames, IA 50011 515-294-0324 From owner-Big-Internet@munnari.oz.au Sat Feb 6 09:35:44 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA11937; Sat, 6 Feb 1993 09:35:54 +1100 (from owner-Big-Internet) Return-Path: Received: from optics.wc.novell.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11929; Sat, 6 Feb 1993 09:35:44 +1100 (from minshall@wc.novell.com) Received: from by wc.novell.com (4.1/smi4.1.1.v91190) id AB22984; Fri, 5 Feb 93 14:31:52 PST Date: Fri, 5 Feb 93 14:31:52 PST Message-Id: <9302052231.AB22984@wc.novell.com> To: art@opal.acc.com (Art Berggreen) From: minshall@wc.novell.com X-Sender: minshall@optics.wc.novell.com Subject: Re: Ethernet IDs as EIDs (was: Metro Addressing Summary) Cc: big-internet@munnari.oz.au >What do bridges do if a Decnet router gets two Ethernet interfaces >plugged into the same cable? The same MAC address will show up on >all interfaces. Same is probably true of many XNS and IPX systems. Well, IPX uses as its node address on a given network its MAC address on that network. As a side note, we have customers who like to *locally* administer all their IEEE addresses (and we provide facilities for this). Greg Minshall minshall@wc.novell.com Novell, Inc. +1 510 975-4507 From owner-Big-Internet@munnari.oz.au Sat Feb 6 16:09:52 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA23593; Sat, 6 Feb 1993 16:10:00 +1100 (from owner-Big-Internet) Return-Path: Received: from thumper.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23587; Sat, 6 Feb 1993 16:09:52 +1100 (from tsuchiya@thumper.bellcore.com) Received: from chiya.bellcore.com by thumper.bellcore.com (4.1/4.7) id for big-internet@munnari.oz.au; Sat, 6 Feb 93 00:09:43 EST Received: by chiya.bellcore.com (4.1/4.7) id for grpjl@iastate.edu; Sat, 6 Feb 93 00:09:42 EST Date: Sat, 6 Feb 93 00:09:42 EST From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Message-Id: <9302060509.AA22405@chiya.bellcore.com> To: big-internet@munnari.oz.au, grpjl@iastate.edu Subject: Re: The big picture Pip's autoconfiguration works almost exactly as you describe. The main difference perhaps being that it isn't necessary to reboot hosts just because the domain got a new prefix. I agree with your comments, and this is why I think htat the argument that geographical is better because it results in fewer (not none, but fewer) address changes is just smoke. PX From owner-Big-Internet@munnari.oz.au Sat Feb 6 17:13:46 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA25382; Sat, 6 Feb 1993 17:13:55 +1100 (from owner-Big-Internet) Return-Path: Received: from Valinor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25379; Sat, 6 Feb 1993 17:13:46 +1100 (from vaf@Valinor.Stanford.EDU) Received: by Valinor.Stanford.EDU (5.65/inc-1.0) id AA14608; Fri, 5 Feb 93 22:13:39 -0800 Date: Fri, 5 Feb 93 22:13:38 PST From: Vince Fuller To: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Cc: big-internet@munnari.oz.au, grpjl@iastate.edu Office: Spruce Hall F15, (415) 723-6860 Usmail: Pine Hall 115, Stanford, CA, 94305-4122 Subject: Re: The big picture In-Reply-To: Your message of Sat, 6 Feb 93 00:09:42 EST Message-Id: Pip's autoconfiguration works almost exactly as you describe. The main difference perhaps being that it isn't necessary to reboot hosts just because the domain got a new prefix. Good. I would consider it entirely unacceptable for an organization to have to reboot every system they have just because they decided to change providers (assuming that topology-based "addresses" are used). Consider also a truly mobile network (i.e. an airplane, a train, or a travelling circuis) - should all of the hosts on such a network have to renumber just because the network is on the move (this is a slightly lame argument that geographically-based "addresses" don't work either). I agree with your comments, and this is why I think htat the argument that geographical is better because it results in fewer (not none, but fewer) address changes is just smoke. I agree. As Noel keeps saying, decoupling the endpoint-ID function from the addressing function of what we now call "IP addresses" is a fundamentally important concept. Once that is done, the who argument of geography- vs. provider-based "addresses" is irrelevant, since *addresses* can become an exact representation of topological location. --Vince From owner-big-internet@munnari.oz.au Sat Feb 6 21:31:27 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA02113; Sat, 6 Feb 1993 21:31:32 +1100 (from owner-big-internet) Return-Path: Received: from interlock.ans.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10570; Sat, 6 Feb 1993 08:44:51 +1100 (from dennis@ans.net) Received: by interlock.ans.net id AA31358 (InterLock SMTP Gateway 1.1 for big-internet@munnari.oz.au); Fri, 5 Feb 1993 16:43:54 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 5 Feb 1993 16:43:54 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 5 Feb 1993 16:43:54 -0500 From: Dennis Ferguson Message-Id: <199302052143.AA28208@foo.ans.net> To: kasten@ftp.com Cc: Christian.Huitema@sophia.inria.fr, big-internet@munnari.oz.au Subject: Re: EGP/IGP split (was Metro Addressing Summary) In-Reply-To: (Your message of Fri, 05 Feb 93 14:21:25 GMT.) <9302051421.AA12318@ftp.com.ans-relay> Date: Fri, 05 Feb 93 16:43:59 -0500 Frank, >> We have a challenge here. I can easily understand how a DV protocol, which is >> only concerned with "local scope", could manage and aggregate variable length >> submasks -- we might have to do some specification work though, e.g. how to >> run a hierachy of BGP's and RIP's. Why I do not see clearly is whether we can >> have a hierarchy of LS protocols without either fixed length tokens or heavy >> manual configurations. > > We already do this. Suppose that NEARNET uses OSPF internally for > their routing. OSPF would pass around routing information for > 128.127, which is FTP's network. However, internal to FTP we have > subnetted our net. We've already aggregated the topological > information. OSPF treats all of FTP's networks as a single vertex on > the graph, named 128.127. If the addressing was truly hierarchical > (e.g. 128 meant nearnet and 128.127 meant FTP in NEARNET) then this > could be continued up the hierarchy. If the NSFNET backbones did LS > routing, then NEARNET would appear on their network as a single > vertex, labelled 128. What you are describing here is not a "hierarchy of LS protocols", but rather just the two-layer IGP/EGP split. From the point-of-view of the IGP there is an internal topology of routers (nodes) and physical links with external address information grafted on to the nodes at the edges. From the point-of-view of the EGP the nodes, if anything at all, are the clumps of topology routed by a single (or a set of coordinated) IGP(s) and the links are the EGP connections between them. You don't really go "up" or "down" any hierarchy when you pass from FTP's network to NEARnet to the NSFnet, you just cross from one node to another in the EGP topology. And, in fact, even the above doesn't describe it right. The ability to aggregate address information across the EGP connections when the addressing exhibits good locality is a direct consequence of the fact that routing at the EGP level is distance-vector (or -vector, at least), and only concerns itself with determining the next hop to a destination rather than the full path. With distance-vector routing things that are "far away" can look "fuzzier" than things which are "closer" without necessarily affecting the actual routes you compute. You don't see "nodes" and "links", but rather just address ranges and next-hops. This isn't globally hierarchical routing per se, but rather locally hierarchical with the hierarchy you see centered on where you are. The fact that aggregation can be done (and redone) on the current network across EGP links is a consequence of the fact that we do distance-vector routing at the EGP level. I agree with Christian that a good distance vector protocol (where "good" means stateful, reliable updates, a method better than Bellman-Ford to avoid loops, i.e. a DV protocol done with the same quality of protocol machinery that modern LS protocols have) with hierarchical information hiding could probably be designed to do all routing on the current network. While "EGP boundaries" might still exist in function you wouldn't need a separate protocol at all. DV protocols are a good match for the hop-by-hop forwarding we do now since they directly compute the things you want to put in your forwarding table, i.e. what routes are available and which neighbours are they available through. LS protocols, on the other hand, are kind of wierd things to be using on the current network since they tell you all kinds of information which is of absolutely no use to you when all you can put in your forwarding table is an address-and-mask and corresponding next hop neighbour. The fact that you can tell the entire path a packet following a route will take does you no good at all when all you have control over is which neighbour you will send the packet to. The ability to compute many different routes to the same destination is utterly useless if you are constrained to only choose the routes your immediate neighbours will be using. The fact that LS protocols provide you with all sorts of information you really don't need to know is also the reason it is hard to aggregate anything within an LS-routed topology, and is probably what makes LS protocols relatively expensive. (Note that this is not to suggest that you should be replacing OSPF with RIP all over since, LS or not, OSPF is a very good routing protocol and RIP is not. The DV protocol you might choose instead of OSPF doesn't exist.) In any case, if one were going to redesign the routing protocol support for a new IP from scratch, I think one would need to ask whether the information one can obtain from a LS routing protocol is going to be useful, and particularly if the potential usefulness of that information made it worth the cost of maintaining it in the protocol. If so I think you would want to look hard at how to modify your forwarding procedures to make use of it (this is sort of the approach that IDPR, the extraordinary-policy-routing part of SDRP, and Nimrod take), and you will work obscenely hard to keep the thing scalable. If you are happy with the hop-by-hop approach of the current Internet then you'd be better off building a good quality DV system since it is simpler and will scale better. KISS. My personal feeling is biased by a suspicion (though not one that I would bet the farm on) that the router-and-circuit construction of the current Internet may begin to yield in places in favour of building IP networks over top of really large routed or switched subnets a la SMDS or ATM, so that you end up with a lot of routers as potential immediate next-hop neighbours. You can provide better support for policy-based routing with hop-by-hop forwarding if you have a big variety of next hops to choose from, and if this is sufficient for your needs the economy of a DV routing protocol when moving address information may be a virtue. Of course the fact is that we have some really good LS IGP's now, but no decent DV IGP, and that the current system of grafting together separate IGP's with a -vector EGP is not terrible, so it might be better not to spend a lot of work fixing that which may not be too seriously broken. >> But maybe I am just one of those dumb engineers who do not >> understand the underlying mathematics of networks and who have been >> befuddled by the terminology associated with computer networks... > > You and me both. Me too. I'm often surprised when it works at all. Dennis Ferguson From owner-Big-Internet@munnari.oz.au Sun Feb 7 00:19:04 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA07018; Sun, 7 Feb 1993 00:19:19 +1100 (from owner-Big-Internet) Return-Path: Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07008; Sun, 7 Feb 1993 00:19:04 +1100 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <12956>; Sat, 6 Feb 1993 05:18:40 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Sat, 6 Feb 1993 05:18:33 -0800 To: Dennis Ferguson Cc: big-internet@munnari.oz.au, deering@parc.xerox.com Subject: Re: EGP/IGP split (was Metro Addressing Summary) In-Reply-To: Your message of "Fri, 05 Feb 93 13:43:59 PST." <199302052143.AA28208@foo.ans.net> Date: Sat, 6 Feb 1993 05:18:28 PST Sender: Steve Deering From: Steve Deering Message-Id: <93Feb6.051833pst.12171@skylark.parc.xerox.com> > ... The fact that LS protocols provide you with all sorts of > information you really don't need to know is also the reason it is hard > to aggregate anything within an LS-routed topology,... In what sense is it hard? A couple of well-known LS protocols -- OSPF and ISIS -- support two-level hierarchies, with Level 1 info being aggregated for distribution within Level 2 routing. Would there be any fundamental difficulty in making them n-level, rather than just two-level? Steve From owner-Big-Internet@munnari.oz.au Sun Feb 7 04:52:25 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12722; Sun, 7 Feb 1993 04:52:34 +1100 (from owner-Big-Internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12719; Sun, 7 Feb 1993 04:52:25 +1100 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA11594; Sat, 6 Feb 93 12:52:04 -0500 Date: Sat, 6 Feb 93 12:52:04 -0500 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9302061752.AA11594@ginger.lcs.mit.edu> To: dennis@ans.net, kasten@ftp.com Subject: Re: EGP/IGP split (was Metro Addressing Summary) Cc: Christian.Huitema@sophia.inria.fr, big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu The ability to aggregate address information across the EGP connections when the addressing exhibits good locality is a direct consequence of the fact that routing at the EGP level is distance-vector (or - vector, at least) ... With distance-vector routing things that are "far away" can look "fuzzier" than things which are "closer" without necessarily affecting the actual routes you compute. ... The fact that aggregation can be done (and redone) on the current network across EGP links is a consequence of the fact that we do distance-vector routing at the EGP level. Sorry, you are confused. Destination Vector (DV) algorithms of all kinds do not have any inherent fundamental advantage over Map Distribution (MD) algorithms when it comes to abstraction. The only slight advantage they have is that since DV algorithms are always computing the 'best' routes to all destinations as a fundemental part of the operation of their distributed algorithms, you have a litle more information already available when it comes to making abstraction decisions. Doing abstraction in MD architectures is simply something that most people have less experience with, which is why it seems less plausible. (I use to think the same thing myself about 10 years back.... :-) Everyone knows how abstraction in DV systems works since they do it every day with subnets and RIP. Abstraction in MD systems is very similar to DV in its effects and limitations, but the mechanisms whereby it happens are very different. Instead of lumping together routing table entries, you have to lump together pieces of the topology. When you do it (what I call abstraction action boundaries) can be very similar to the way DV does it, but the deployed Internet DV technology has a really brain-dead algorithm for when to do abstracation; it does it at the abstraction naming boundaries (i.e. you collapse subnet routes into a net as you leave the net, not some hopes later). I can imagine much better algorithms for use with DV (N hops away, or when all the next-hops for the sub-components of the thing you are going to abstract have the same net hop, etc, etc.) When it comes to the fundamental limits of abstraction (e.g. can you throw away some detail in the routing information, and still get absolutely optimal routing), both systems seem to have much the same limits, actually. There are *no* algorithms which are guaranteed to always produce optimal routing with less routing info.... The only difference is that MD systems have a lot more flexibility in how they do abstraction, particularly if they are source-routed. I agree with Christian that a good distance vector protocol ... with hierarchical information hiding could probably be designed to do all routing on the current network. It might, but it depends on what your design goals are. Lots of different kinds of 'policy routing' requirements more or less require a source routed MD architecture, as you will see if you examine the 'Unified' routing architeture of Estrin, Rekhter, et al. Yakov's no fan of LS (I hope I haven't misrepresented you here, Yakov :-); if it's there, you'd better believe there's a good reason. DV protocols are a good match for the hop-by-hop forwarding we do now since they directly compute the things you want to put in your forwarding table, i.e. what routes are available and which neighbours are they available through. True, but they use a distributed algorithm to do it. I am always suspicious of distributed algorithms, since they are harder to stabilize with broken implementations (a fact of life, sigh), etc, etc. LS algorithms can easily compute routing tables (on demand, actually, a feature that nobody has ever made use of, but which could have substantial computational savings). In addition, I'm not sure that HbH forwarding is the wave of the future, but let's not get into that now. LS protocols, on the other hand, are kind of wierd things to be using on the current network since they tell you all kinds of information which is of absolutely no use to you when all you can put in your forwarding table is an address-and-mask and corresponding next hop neighbour. Have you heard of policy routing? In a world with lots of policies, you need a lot more than a table with address-and-mask and next hop. The fact that you can tell the entire path a packet following a route will take does you no good at all when all you have control over is which neighbour you will send the packet to. The ability to compute many different routes to the same destination is utterly useless if you are constrained to only choose the routes your immediate neighbours will be using. Well, yes, exactly, which is why most designers of new routing architectures have gone down the 'source-routed' path, rather than hop-by-hop. The fact that LS protocols provide you with all sorts of information you really don't need to know is also the reason it is hard to aggregate anything within an LS-routed topology, and is probably what makes LS protocols relatively expensive. Leaving aside the 'hard to aggregate point', which is confused, LS algorithms are more expensive along some axes, but cheaper along others. The axes along which LS algorithms are more expensive are that a) they are more complex, and take more space to implement, b) they take more space to hold their databases (especially if you are computing a complete routing table), and c) they can be more computationally expensive. The axes along which they are cheaper are a) they take less line bandwidth, and b) they stabilize in a bounded and faster time than DV algorithms. (Spare me the comments about Jose's work; if you read the fine print it bears all these points out.) Yes, LS algorithms do have more information available, but whether that is a bug or a feature depends on whether or not you consider they advantages they have important. The DV protocol you might choose instead of OSPF doesn't exist. There was a DV-IGP WG in the IETF for a while. It never produced a protocol; perhaps it should be spun up again? I think one would need to ask whether the information one can obtain from a LS routing protocol is going to be useful, and particularly if the potential usefulness of that information made it worth the cost of maintaining it in the protocol. ... you will work obscenely hard to keep the thing scalable. I must confess I'm a little confused by this. What are the facets of a hierarchical MD architecture that will make it scale poorly? It can handle abstraction just fine (as demonstrated by IS-IS, OSPF, etc...), and abstraction is *the* tool you need to make routing scale. the router-and-circuit construction of the current Internet may begin to yield in places in favour of building IP networks over top of really large routed or switched subnets a la SMDS or ATM This old chestnut again. The problems of large scale routing are the problems of large scale routing, and you don't make them go away by shoving them under the layer 2 rug. Since you have to have functional, global, layer 3 routing to stitch together a global Internet of different technologies, you're better off pulling all the routing up into layer 3. Otherwise, you get the IGP/EGP split sort of problems, but an order of magnitude worse, since half the routing is in one layer and half in another. You can provide better support for policy-based routing with hop-by-hop forwarding if you have a big variety of next hops to choose from How is it that you propose to decide which traffic gets sent to which next hop? Noel From owner-Big-Internet@munnari.oz.au Sun Feb 7 06:01:03 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA14815; Sun, 7 Feb 1993 06:01:18 +1100 (from owner-Big-Internet) Return-Path: Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14810; Sun, 7 Feb 1993 06:01:03 +1100 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <13156>; Sat, 6 Feb 1993 11:00:41 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Sat, 6 Feb 1993 11:00:35 -0800 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.oz.au, deering@parc.xerox.com Subject: Re: EGP/IGP split (was Metro Addressing Summary) In-Reply-To: Your message of "Sat, 06 Feb 93 09:52:04 PST." <9302061752.AA11594@ginger.lcs.mit.edu> Date: Sat, 6 Feb 1993 11:00:29 PST Sender: Steve Deering From: Steve Deering Message-Id: <93Feb6.110035pst.12171@skylark.parc.xerox.com> > ... LS algorithms can easily compute routing tables (on demand, actually, > a feature that nobody has ever made use of, but which could have substantial > computational savings). FYI, my LS multicast routing algorithm, embodied in the multicast extensions to OSPF, does on-demand computation of (multicast) routing table entries from the LS database. It does that because it would be too expensive to compute all possible multicast trees (#sources x #multicast-groups) in advance. Steve From owner-big-internet@munnari.oz.au Sun Feb 7 07:45:44 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17130; Sun, 7 Feb 1993 07:45:52 +1100 (from owner-big-internet) Return-Path: Received: from interlock.ans.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10109; Sun, 7 Feb 1993 02:26:16 +1100 (from dennis@ans.net) Received: by interlock.ans.net id AA12973 (InterLock SMTP Gateway 1.1 for big-internet@munnari.oz.au); Sat, 6 Feb 1993 10:25:08 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Sat, 6 Feb 1993 10:25:08 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Sat, 6 Feb 1993 10:25:08 -0500 From: Dennis Ferguson Message-Id: <199302061525.AA83570@foo.ans.net> To: Steve Deering Cc: big-internet@munnari.oz.au Subject: Re: EGP/IGP split (was Metro Addressing Summary) In-Reply-To: (Your message of Sat, 06 Feb 93 05:18:28 PST.) <93Feb6.051833pst.12171@skylark.parc.xerox.com> Date: Sat, 06 Feb 93 10:25:12 -0500 Steve, >> ... The fact that LS protocols provide you with all sorts of >> information you really don't need to know is also the reason it is hard >> to aggregate anything within an LS-routed topology,... > > In what sense is it hard? A couple of well-known LS protocols -- OSPF and > ISIS -- support two-level hierarchies, with Level 1 info being aggregated > for distribution within Level 2 routing. Would there be any fundamental > difficulty in making them n-level, rather than just two-level? You can aggregate between areas in both directions (IS-IS implicitly aggregates to a default in the level 2->level 1 direction), but this is not aggregation "within an LS-routed topology". Each area is a separate chunk of topology, and routers in neighbouring areas view their neighbours as address information grafted on the edges of their own topology. You know the topology within your own area, but only the next hop for everything else. The level 1/level 2 distinction is essentially a loop avoidance discipline for the inter-area vector routing. Look, if everyone ran OSPF as their IGP if would be quite possible to eliminate the use of an EGP protocol everywhere by building border routers capable of running two instances of backbone-level OSPF, having the router participate in both networks' OSPF, and simply moving routes between each instance of the protocol. There would be no difficulty aggregating across this border. But note that such a router would not look dissimilar, from the outside, to two separate routers connected by an instance of the EGP (indeed it would be wise to make it look *exactly* like two routers connected by an instance of the EGP, since the EGP processing we do now is necessary for inter-AS loop avoidance). We've eliminated the external protocol on the wire but what we end up with is identical to what we have now, a two-layer hierarchy with LS-routing at the inter-router level, -vector routing at the inter-SPF-area level, and with all aggregation being done at the -vector level. I would assert that the inter-area routing which IS-IS and OSPF do is not materially different from the above, with the exception that the loop control discipline for the vector routing is different. We always fall back to hop-by-hop routing when aggregation needs to be done. Dennis Ferguson From owner-big-internet@munnari.oz.au Sun Feb 7 11:46:53 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22541; Sun, 7 Feb 1993 11:47:15 +1100 (from owner-big-internet) Return-Path: Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14356; Sun, 7 Feb 1993 05:47:08 +1100 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <13148>; Sat, 6 Feb 1993 10:46:30 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Sat, 6 Feb 1993 10:46:18 -0800 To: Dennis Ferguson Cc: big-internet@munnari.oz.au, deering@parc.xerox.com Subject: Re: EGP/IGP split (was Metro Addressing Summary) In-Reply-To: Your message of "Sat, 06 Feb 93 07:25:12 PST." <199302061525.AA83570@foo.ans.net> Date: Sat, 6 Feb 1993 10:46:11 PST Sender: Steve Deering From: Steve Deering Message-Id: <93Feb6.104618pst.12171@skylark.parc.xerox.com> Dennis, I usually find your messages to be models of clarity and illumination, but this time I am completely in the dark as to what special semantics you attach the notion of "distance-vector". Perhaps this is the kind of understanding that can only be conveyed by drawing pictures on a whiteboard, but I'll press on in prose form, in the hope that I find the light switch. > You can aggregate between areas in both directions (IS-IS implicitly > aggregates to a default in the level 2->level 1 direction), but this > is not aggregation "within an LS-routed topology". Each area is a > separate chunk of topology, and routers in neighbouring areas view > their neighbours as address information grafted on the edges of their > own topology. You know the topology within your own area, but only > the next hop for everything else. The level 1/level 2 distinction is > essentially a loop avoidance discipline for the inter-area vector routing. A different, equally-valid, view is that level-1 routing computes routes across a topology of interconnected subnetworks, whereas level-2 routing computes routes across a topology of interconnected clouds (level-1 areas). ISIS requires that level-2 neighbors be joined by single subnetworks, rather than multi-hop clouds, but those subnetworks may be viewed simply as degenerate clouds. OSPF adopts the more general model, with its support for "virtual links" (or whatever they are called) between level-2 routers, across level-1 areas. In this view, level-1 clouds do not just appear on the fringes of the level-2 topology, but rather level-1 clouds are the *only* kind of links present in the level-2 topology. (Yes, I know that this view is not elucidated in the ISIS or OSPF specs -- in particular, they do not label those subnetworks that serve only to connect level 2 routers as distinct areas, but being a degenerate case, they do not need their own area labels. I also note that level 2 routers must also participate in level 1 routing in each of the level-1 areas to which they are directly attached.) Now this sure looks to me like aggregation/information-hiding "within an LS-routed topology" -- each level-1 area is LS-routed internally, and the interconnection of level-1 clouds making up the level-2 topology is in turn LS-routed. There is no "inter-area vector routing" occurring. Furthermore, I don't see any fundamental reason why this couldn't be extended to support level-3 routing among level-2 cloud-clusters, and level 4 routing among level-3 cloud-cluster-clusters, and so on. With somehwere between 4 and 6 levels of LS routing, you could cover the entire future Internet with a single "instance" of OSPF. I'm not quite sure how that would differ from the "multiple instances" model that you described as follows: > Look, if everyone ran OSPF as their IGP if would be quite possible to > eliminate the use of an EGP protocol everywhere by building border routers > capable of running two instances of backbone-level OSPF, having the router > participate in both networks' OSPF, and simply moving routes between each > instance of the protocol. I guess the difference is in whether "moving routes between each instance of the protocol" is done as result of just running one level higher of OSPF routing, vs. doing vector routing or static routing or something else between each OSPF instance. I still don't see that the inter-OSPF routing has to be vector-based. > ... But note that such a router would not look dissimilar, from > the outside, to two separate routers connected by an instance of the EGP > (indeed it would be wise to make it look *exactly* like two routers > connected by an instance of the EGP, since the EGP processing we do now > is necessary for inter-AS loop avoidance). We've eliminated the external > protocol on the wire but what we end up with is identical to what we > have now, a two-layer hierarchy with LS-routing at the inter-router level, > -vector routing at the inter-SPF-area level, and with all > aggregation being done at the -vector level. I think you are muddying things up with another issue: do clouds meet in the middle of a box or in the middle of a wire? For clouds that meet in the middle of wires, you can always model them as meeting in the middle of boxes by either (a) treating the wire as a separate "cloudlet" that separates two or more clouds (this is the model I adopted above, when I said that direct links between level-2 ISIS/OSPF routers should be viewed as degenerate areas), or (b) treating the boxes attached to the wire as "half-boxes", linked by a private, internal communication channel. Now, I don't know if, when you use the term "an EGP", you are referring to a protocol run between such half-boxes (in which case, the EGP could be eliminated if you adopted the cloudlet model), or you are simply referring to whatever protocol is used to route among ADs (in which case, you might use the term "EGP" for level-3 of a hypothetical 3-level OSPF used between multiple ADs). What we have now in the Internet is *not* a two-level hierarchy -- if anyone is running a two-level instance of OSPF within their AD, then we have at least a three-level hierarchy, and aggregation is being done at the LS level as well as the something-vector level. At the lowest level, aggregation is occurring by virtue of the assumed contiguity of addresses on the same subnet, which is neither LS-based or vector-based. The fact that the top level is currently a mixture of vector-based routing and static routing doesn't seem to me to be an architectural imperative. Steve From owner-big-internet@munnari.oz.au Sun Feb 7 13:13:43 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA24474; Sun, 7 Feb 1993 13:14:06 +1100 (from owner-big-internet) Return-Path: Message-Id: <9302070214.24474@munnari.oz.au> Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22668; Sun, 7 Feb 1993 11:56:08 +1100 (from yakov@watson.ibm.com) Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R2) with BSMTP id 5385; Sat, 06 Feb 93 19:56:02 EST Date: Sat, 6 Feb 93 19:56:02 EST From: yakov@watson.ibm.com To: deering@parc.xerox.com Cc: big-internet@munnari.oz.au Subject: EGP/IGP split (was Metro Addressing Summary) Ref: Your note of Sat, 06 Feb 93 10:25:12 -0500 I would suggest that folks who advocate using LS hop-by-hop forwarding for inter-domain routing would consider how such a scheme would address the following problems: (a) transit policies, where a domain may want to restrict its transit traffic (b) dissimilar route selection policies, where different domains, when presented with the same set of routes would select different one (c) support for information aggregation when the overall inter-domain topology can't be constrained to pure "core" model (ala EGP2). I would be quite interested hearing specific proposals on how the above issues can be addressed (please add the estimated overhead). Yakov. From owner-big-internet@munnari.oz.au Sun Feb 7 20:56:29 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA05227; Sun, 7 Feb 1993 20:56:31 +1100 (from owner-big-internet) Return-Path: Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29318; Sun, 7 Feb 1993 16:35:24 +1100 (from tli@cisco.com) Received: by lager.cisco.com; Sat, 6 Feb 1993 21:35:08 -0800 Date: Sat, 6 Feb 1993 21:35:08 -0800 From: Tony Li Message-Id: <199302070535.AA05355@lager.cisco.com> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: dennis@ans.net, kasten@ftp.com, Christian.Huitema@sophia.inria.fr, big-internet@munnari.oz.au Subject: Re: EGP/IGP split (was Metro Addressing Summary) Sorry, you are confused. So stipulated. ;-) Destination Vector (DV) algorithms of all kinds do not have any inherent fundamental advantage over Map Distribution (MD) algorithms when it comes to abstraction. Well, I can't speak to true MD algorithms. As far as I know, they only exist in your neurons. ;-) But we can look at existing LS implementations. These have the requirement that abstraction only happen at particular boundaries, either between areas or on the border of the link state system. This lack of flexibility IS an inherent disadvantage when compared to an algorithm which allows arbitrary abstraction at any point in the system. Doing abstraction in MD architectures is simply something that most people have less experience with, which is why it seems less plausible. (I use to think the same thing myself about 10 years back.... :-) True. As always, I'm ready to be educated. Please point me to the approrpiate documents... To the best of MY knowledge, there is no way to aggregate within an area with existing link states. ... the deployed Internet DV technology has a really brain-dead algorithm for when to do abstracation; it does it at the abstraction naming boundaries (i.e. you collapse subnet routes into a net as you leave the net, not some hopes later). I can imagine much better algorithms for use with DV (N hops away, or when all the next-hops for the sub-components of the thing you are going to abstract have the same net hop, etc, etc.) True. Or the one that we're trying to deploy which is just to let us poor humans deal with it. Evaluating hops is something that we're trying to get away from. It's not relevant. Calculating the next hop for all of your aggregatable items is computationally expensive. The only difference is that MD systems have a lot more flexibility in how they do abstraction, particularly if they are source-routed. I think that this is a dangerous comparison as you invite us to compare LS with source routing vs. DV/PV with HbH routing. I think that we need to be very clear in that LS does inherently have more information available. This information has ALREADY been abstracted away by the DV/PV protocol. Is this relevant? If both are doing HbH, then probably not. You have no way of using the additional information. Let's just burn that RAM. Yes, this information can be exploited if you are doing source routing. Fine, now let's consider an SDRP-style protocol with dynamic information retrieval on top of a PV protocol. [I will not claim that this is counts as MD, but I would still like to know if you think so or not, Noel.] Conceptually, this style of protocol can acquire all of the information that a LS algorithm would carry, but would assume the PV style of abstraction as its baseline. Is it better to be pro-active about abstraction or not? I believe that we've already had this discussion. It depends on whether or not the bulk of the traffic is source routed or HbH. I believe we agreed that it was not at all clear... In addition, I'm not sure that HbH forwarding is the wave of the future, but let's not get into that now. Ok. True, but they use a distributed algorithm to do it. I am always suspicious of distributed algorithms, since they are harder to stabilize with broken implementations (a fact of life, sigh), etc, etc. Harsh reality with broken LS implementations is that they don't stabilize either. In fact, one of the interesting things that happen with broken LS implementations is that since all routers perform the exact same computation, they execute the exact same code path in near-perfect synchrony. When that code path is defective, you now have the possibility of a distributed, synchronized, catastrophic, system-wide, router crash. This is not just a theoretical possibility. ;-( LS protocols, on the other hand, are kind of wierd things to be using on the current network since they tell you all kinds of information which is of absolutely no use to you when all you can put in your forwarding table is an address-and-mask and corresponding next hop neighbour. Have you heard of policy routing? In a world with lots of policies, you need a lot more than a table with address-and-mask and next hop. Yes, we've heard of policy routing. But Dennis was talking about the _current_ network. Current policy routing is accomplished by configuration. The fact that you can tell the entire path a packet following a route will take does you no good at all when all you have control over is which neighbour you will send the packet to. Well, not really. You can decide that you dislike some component of that path and not use that next hop. Leaving aside the 'hard to aggregate point', which is confused, LS algorithms are more expensive along some axes, but cheaper along others. The axes along which LS algorithms are more expensive are that a) they are more complex, and take more space to implement, b) they take more space to hold their databases (especially if you are computing a complete routing table), and c) they can be more computationally expensive. The axes along which they are cheaper are a) they take less line bandwidth, and b) they stabilize in a bounded and faster time than DV algorithms. (Spare me the comments about Jose's work; if you read the fine print it bears all these points out.) Let's just say I'm not convinced about ANY of this, and yes, I've read the fine print. I must confess I'm a little confused by this. What are the facets of a hierarchical MD architecture that will make it scale poorly? It can handle abstraction just fine (as demonstrated by IS-IS, OSPF, etc...), and abstraction is *the* tool you need to make routing scale. True. But does the abstraction have to be manually configured? I view this as the #1 problem with existing routing: too much to configure. Some day the size of the network will exceed the capacities of those who really understand how inter-as routing works now. That day, the Internet fails. Lemme throw down a real gauntlet: The real scaling problem is human bandwidth. Until we can design a routing protocol that requires NO human intervention, then routing cannot scale. So how do we do _automatic_ abstraction? Tony From owner-Big-Internet@munnari.oz.au Mon Feb 8 08:52:35 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA20044; Mon, 8 Feb 1993 08:52:52 +1100 (from owner-Big-Internet) Return-Path: Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20035; Mon, 8 Feb 1993 08:52:35 +1100 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14072>; Sun, 7 Feb 1993 13:52:22 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Sun, 7 Feb 1993 13:52:15 -0800 To: big-internet@munnari.oz.au Cc: deering@parc.xerox.com Subject: Re: Metro Addressing Date: Sun, 7 Feb 1993 13:52:14 PST Sender: Steve Deering From: Steve Deering Message-Id: <93Feb7.135215pst.12171@skylark.parc.xerox.com> Noel started this thread by saying: > induce a little life....> He certainly succeeded. Sadly, much of the discussion has been a rehash of discussions we've already been through on this list, at least three times in the last year. Here's a response to many of the messages; it's rather long, and probably of interest only to hard-core big-internet readers. Let me preface my comments by noting the following: - My comments are in the context of my specific geographical addressing and routing proposal, which I dubbed "metro-based" (nee "City Codes"). It is not necessarily the same as Christian's, or Bill Simpson's, or anyone else's model of metro-based addressing, and it is definitely not the same as the current U.S. or international telephone addressing model. - I use the term "address" for those identifiers that are carried in the destination address field of conventional (inter)network- layer or link-layer datagram protocols, such as IPv4, SIP, CLNP, XNS, AppleTalk, Ethernet, etc. It is the identifier upon which routing decisions are made. This is looser than Noel's definition, in that it includes NSAP addresses (which nominally identify points within boxes, rather than those boxes' network interfaces) and Ethernet addresses (which are completely unconstrained by topology). It is more restrictive than Pip's FTIFs, in that it does not include source routes or route fragments or virtual circuit identifiers. - When talking about an address or a part of an address being "hierarchical" or "flat", I am referring to hierarchical structure for the purpose of route information aggregation, *not* for the purpose of address allocation. For example, Ethernet addresses are flat for routing purposes, even though they have hierarchical structure (org. ID in high-order 24 bits) for allocation purposes. - Please remember that metro-based addressing is independent of SIP. SIP need not use metro-based addresses; protocols other than SIP could use -- and might benefit from using -- metro-based addresses. Noel wrote: > As far as I understand it, the chief point of metro addressing is to > allow customers to switch from one service provider to another within a > 'metro' while keeping the same 'address'... > ...Thus, the 'addresses' in this system have basically the same > operational characteristics as NSAP's, in that they consist of a 'high-order' > part which has topological significance (the metro identifier), and a part > which does not (the subscriber within the metro). (There may be a 'low order' > part within the subscriber info which has topological significance within > the subsciber, but we can ignore that at the metro level routing.) > Am I on track so far? If by "having topological significance", you mean "consisting of more than one hierarchical level", then yes, you are on track. You have chosen to divide the hierarchical components of a metro-based address into "parts" as follows: country + metro + subscriber + subnet + host \_____________________/ \______________/ \___________________/ high-order part middle part low-order part The middle part has no "topological significance", in that it has no further hierarchical structure. However, the same could be said, tautologically, for any other single component of the address, e.g., the metro ID or the subnet ID. Or do you mean something more when you say part of an address "has topological significance"? > The routing at the metro level is thus forced to track all the > subscribers individually. "Track" is an imprecise concept. Every router operating at the metro level (that is, intra-metro, inter-subscriber) must be able to route to any subscriber in the metro, and there is no information in the addresses to facilitate aggregation of subscribers. That does not, however, necessarily mean that every such router needs a table entry for every subscriber in the metro (e.g., the routers belonging to one provider may have entries only for that provider's own subscribers, plus a metro-default route pointing to a place where all of the providers in the metro interconnect), nor does it necessarily mean that changes of subscriber connectivity have to be detected with the same time granularity that routing protocols typically use for detecting topology changes (e.g., subscribers might be limited to changing attachment points or providers no more rapidly than, say, once a day), nor does it necessarily mean that a router has to keep entries for all of its subscribers in memory (e.g., a router's in-memory routing table might be just a cache of those subscribers actively receiving traffic via that router). But we've been over this before, Noel. > So here's what I don't get. Isn't this an expensive way to provide > service mobility? If you must have a 'name' other than the DNS name which > doesn't change when you move around in the network, wouldn't another > namespace, and a translation from that namespace to a topologically > significant name (used by the routing) be a better engineering solution to > this problem? That depends on the expense of the additional-namespace alternative, and on important factors other than expense, such as robustness, responsiveness, scalability, and administrative overhead. > Routing is an inherently more expensive construct than a name > translation. Yes, if operated at the same scale. But you are advocating global name translation as an alternative to local (intra-metro) routing, and that is *not* inherently cheaper. In order to scale, the DNS has to do aggressive caching with long timeouts. To support low-latency (e.g., 24-hour) directory updates, you would have to reduce the timeouts or add callbacks, and if the rate of provider-switching is high, that could well turn out to be prohibitively expensive in a Really Big Internet. Furthermore, the costs of the directory approach are much harder to predict, because they depend on future traffic patterns (how many cached copies is an update likely to have to invalidate, and how distant will those copies be from the master copy?), which makes the directory approach riskier than the routing approach. Also, routing is inherently more robust than the directory approach: unreachability of a piece of the directory does not prevent communication. If for no other reason than that, if a routing solution is tractable, it may be preferable to a directory solution. > I'm simply not tracking on this metro addressing thing; perhaps someone can > explain where I went wrong? Is it any clearer now? Christian wrote: > There are many ways to solve this problem. One first, obvious, solution, is > to consider a "provider monopoly" on one geographical area. In this case, > the "geographical" address end up having a very reasonable topological > significance. That is not what I am proposing with metro-based addressing. In fact, it is precisely to facilitate unfettered competition in the local provision of IP service that I started flogging the idea of metro-based addressing for internets. Unfortunately, most of the rest of Christian's message was completely confusing to me. Paul wrote: > I agree that life [under metro-based addressing] is a little easier for the > subscriber because of address changes, but really designing for address > changes is quite easy. Make hosts have a notion of the "provider prefix". > Spread provider prefix information around in intra-domain routing (the > routers need to know them anyway). Have a simple configuration protocol > similar to ES-IS to reassign prefixes to hosts en masse. Of course you must > also update DNS, but this is not that big a deal....... You keep saying that, and I hope you are right, but no one can judge whether or not it really is "utterly simple" (as you said in another message) until we read the spec. The TUBA folks have also been claiming that auto- reconfiguration of addresses is a solved problem for CLNP (and that it ought to be one of the mandatory IPNext features), but when I went to the X3S3.3 meeting last month and asked which standards or drafts I should read to understand how CLNP, ES-IS, IS-IS, etc. do auto-reconfiguration, the only answer I got was "read the DECNET Phase V documents"! (By the way, does anyone know where I can FTP those documents from?) You and Ross and others may well have worked out complete auto-reconfiguration schemes in your heads, but let us see them written down, and maybe even implemented, before you ask us to accept that it is trivial, scalable, and correct. After all, Shortcut Routing with backwards learning seemed pretty straightforward when you first explained it to us, but it turned out to have a number of subtle failure modes that took months for you and others to identify, such that you are now (quite properly, in my opinion) backing away from the backwards learning aspect. Similarly, there may well be subtle weaknesses in your auto-reconfig scheme. Certainly your dismissal of DNS updates as "not that big a deal" appears to be excessively cavalier, given that the DNS has not been designed for low-latency updates and it has not been shown that you can add that capability without significantly reducing its scalability. You should also, of course, demand to see a written specification for metro- based routing before taking my word for it that it would work. But at least I have not been asserting without proof that it is "utterly simple" and dismissing alternative proposals as "just smoke". Noel wrote, in response to Dan Hitchcock: > It is also not necessarily true that the address space in the metro needs > to be flat. > > But if I can move to a different subscriber in the metro (i.e. change the > place where I am connected to the network) without anything in my address > changing, doesn't this mean that the addressing within the metro is flat? Under my proposal, addressing of sites/subscribers within a metro is indeed flat. Noel wrote, in response to Christian: > So, yes, providers could have to maintain some information on their > previous customers. But only what is needed to issue the "cluster has > moved" ICMP, which is probably a fairly static information. > > Depending on which percentage of the customers have moved, this could be a > very large databse. I.e. if more than a few percentage of customers have > *ever* switched to a different provider, every time someone tries to contact > them their old provider is going to have to send out an ICMP (since > presumably your initial metro-local address contains the identity of your > original provider). If you do metro-based addressing, the "cluster has moved" messages are used only for subscribers moving to different metros. There is no provider identity in the addresses themselves. Furthermore, providers are not expected to provide this service for their former customers forever; it is only a short-term service, to tide things over until the directory entries for the cluster, including all of the cached copies, have been updated or invalidated (a week or two, perhaps). If you are doing provider- based addressing, the "cluster has moved" message can also serve to keep existing connections/sessions/associations operating across a change of provider that does not involve moving to a new metro, but again that would not be expected to be a long-term service; attempts to send to the old address after the redirection service is terminated would elicit an ICMP "destination unreachable -- no such address", which could trigger a DNS lookup to get the new address (which has now had time to make it into the DNS). After some further time has elapsed (e.g., a couple of years)), the provider would be free to reassign the old address to a new subscriber. > Plus to which, why are providers going to want to provide this service for > customers who aren't paying them any money any more? That's a good question. I assume that providers might charge for this service, but at a rate less than the full subscription rate. Maybe it will become a competitive necessity to provide the service, e.g., sites will refuse to subscribe to any provider that does not offer free or cheap redirection service for a short period after service termination. Maybe it will be required by the local Public Utilities Commission or equivalent. I dunno. In another message, Paul responded to Christian with the following: > > We could consider that the sequence "packet in, ICMP out" is not much more > > costly than a DNS transaction, and also that it is common to two problems > > -- provider swapping and mobile hosts. Which is why I prefer this to DNS > > based solutions. > > So, is this ICMP going to be part of SIP or not? I was under > the impression before that the SIP solution to provider-orientation > problems was to solve it in backbone routing, and not burden > the user with it at all. And, I am under the impression that > a NON-goal of SIP is to deal with multiple providers for a single > subscriber (ie, provider selection on the source end or the > destination end). Now I'm beginning to hear something different. I hope I corrected those misimpressions in my message of last week. > If SIP is really not going to deal with provider issues, > then it can remain simple and people can decide whether they > prefer simpler-but-less-functional to more-complex-but-more-functional > (ie, SIP/CLNP vs. Pip). SIP deals with provider issues. Perhaps the comparison will be between simple-and-functional vs. more-complex-and-of-unknown-correctness. This sort of sniping, especially when based on ignorance, is not particularly helpful. John Curran wrote, in response to Christian: > ] Experience will tell, but I believe that companies will more often swap > ] between MCI, ATT and Sprint than move their buildings around the city. So I > ] believe that the first order problem is to facilitate provider swapping. > ] Also, one could observe that "keeping your address when moving to another > ] building" is also a problem for provider addresses, so is not a real strong > ] argument in the provider vs geographical debate. > > It does depend how how "small" the regions are. This past summer, we've had > more than a dozen NEARnet members move within New England. All of this was > done without addressing changes, whereas under metro-based addresses most > would had to change. (In the same time, we've had only a handful of cross- > provider changes). Yes, that is what I would expect in the current Internet, given that the burden of changing addresses is a significant deterrent to your customers switching to another provider. Do you have significant competition in your market, such that there are service-competitive alternatives for your customers to choose among? Anyway, I don't think "more than a dozen moves" vs. "a handful of cross-provider changes" can be read as a significant prediction of the behavior of an Internet in which many, many more small businesses and households are consumers of commercial, competitive Internet service. In response to the following comment by Christian... > Experience will tell, but I believe that companies will more often swap > between MCI, ATT and Sprint than move their buildings around the city. So I > believe that the first order problem is to facilitate provider swapping. ...Dennis wrote a long message explaining how the US phone numbering scheme is really a provider-based scheme, and how if you wanted to connect directly to MCI, ATT, or Sprint, you would have to get a new phone number, and how you would have to change your number when you changed providers, and so on. That's all true, but irrelevant. Metro-based addressing is intended to *fix* that problem; I won't be surprised if the local phone companies are also eventually forced to give up their monopoly over the phone numbers in an area code, to allow phone-number-portability among multiple, competing local phone companies. (Or, they'll end up giving everyone an 800 number as an "EID" and try to build a huge "database in the sky" to maintain the mappings from EID to current phone number, which will turn out to be a performance bottleneck and a fertile source of customer complaints, but an enormous source of employment for telephone system programmers a operators.) Robert Ullman wrote: > There are more assumptions I see flying around, unmarked as assumptions. > For example: "most sites will have one provider" That is not an assumption of the metro-based addressing scheme. Bill Simpson wrote: > When Steve made up his plan, he seems to have used the broader > "Consolidated MSAs" rather than "Primary MSAs". These details need to > be worked out. I think that primary areas will be a more accurate > prediction of where metro exchanges are likely to be needed. Yes, I used the Consolidated MSAs. I think that the bigger the geographical area covered, the better, as long as the routing and administration remains tractable. The bigger the metro, the larger the number of physical moves that can be accommodated without an address change, and the fewer MIXes (Metropolitan Internet Exchanges, where the providers interconnect) have to be established. I believe the routing would be tractable up to tens of millions of sites per metro area, using existing technology, so I favor using the mega-metros. Thank-you very much for digging up the more recent census data, Bill. Are you volunteering to expand my tentative assignment of US metro codes, based on the more complete data? > Are we agreed that (whether for actual routing or Endpoint Identifier), > it is reasonable to design the numbering space in the following order? > > 1) planetary body in the solar system > 2) continent on the planetary body > 3) political boundary within a continent > 4) metropolitan statistical area > 5) provider > 6) site I don't see any convincing reason for partitioning the address space by planet or continent, whether for routing or for allocation purposes. There are few enough countries (fewer than 300) that we don't have to aggregate them, and each additional level of hierarchy creates greater, undesirable wastage of the address space. I'm not even sure that partitioning by country is necessary, although the current SIP geographical addressing plan does have country as the top level. There will be fewer than 10,000 metros, so they could be handled "flat" with the same routers we are currently using in the Internet backbones. However, there may be valid political reasons for partitioning by country, for allocation purposes if not routing purposes. Note that for countries that subsequently fragment, we wouldn't have to assign new country IDs, but could simply replace the original country entry in the routing tables with the set of metro entries belonging to the resulting pieces. In the limit of all countries breaking into their consituent city-states, we'd still be under 10,000 entries. The last two levels -- provider and site -- make sense, but note that for metro-based addresses, any provider subdivision would be for address allocation purposes only, not for routing. Frank K. wrote: > (where to satellites and space shuttles and the like fall in this > scheme? do they qualify as planetary bodies? How about moons > and asteroids and comets....) Under metro-based addressing, the geographical information in an address identifies the point (i.e., metro) at which the site attaches to the fixed, public infrastructure, because that is the information the public backbone routers need to do scalable routing. Thus, the address(es) of a geosynchronous satellite would depend on where its ground station(s) were attached to the public Internet. Space shuttles and airliners and ships would be treated either as mobile hosts/subnets frequently changing their points of attachment to the public Internet, or, if they are serviced by a wide-area private terrestrial network, as hosts/subnets whose mobility is invisible outside the private net and whose addresses depend on were the private net attaches to the public Internet. Moons and planets (other than Earth) with permanent settlements would probably get their own metro IDs. Asteroids and comets would be treated like satellites. Satisfied? Henning wrote: > Also, while I may or may not know what metropolitan area my town belongs > to (is every town assigned to one? what about sparsely populated areas > such as North Dakota or Alaska?), I definitely do know my area code. So what? You won't have to know or remember what metro area your computer belongs to; your computer will know, and your site administrator or your service provider will tell you, if you really care. It's not like you have to dial it or anything! > Clearly, area codes change relatively frequently (as do metropolitan areas, > if maybe less so). We could use the current assignment as the basis > for Internet assignment, or, once renumbering hosts has become trivial, > follow the area code splits, as they can be expected to roughly trace > telecom/internet density. Area code splits are an undesirable artifact of the 7-decimal-digit limitation on local phone numbers in the North American Numbering Plan. There is no reason why we should codify that mistake into the future Internet addressing plan. Furthermore, area codes are already finer-grain than necessary in some regions; for example, the SF Bay Area has three area codes, but we would really only need and want one metro code for the Bay Area, for reasons discussed above. If we don't adopt the area code number plan exactly (and I think we should not), or if we start with it but do *not* follow future area code splits, I think the result -- a numbering plan that would be almost, but not exactly, the same as telephone area codes -- would lead to much more confusion than having an entirely separate address space. Lars Poulson responded to Frank K. as follows: > >How would this be handled when we get a European office, with a private > >T1 to our right-coast office, and an EARN connection? > > I would expect the following addresses (in some numeric realization): > Earth.NoAm.Usa.Ca.Sfo.FTP > Earth.NoAm.Usa.Ma.Bos.FTP > Earth.Europe.UK.Lon.FTP > > The routing along the intra-company links would be a routing policy > within your own routers. > > In fact, this is likely to lead to much more cost-effective routing than > any current scheme. Exactly. (Except that I don't think the addresses need to have the planet and continent prefixes, as I discussed above.) Tony Li wrote: > ... I think that we SHOULD point out that the ability to > renumber, whether for the case of host relocation or provider change > is a very strong requirement for IP7. The desired property is that manual renumbering be unnecessary. How this is accomplished -- whether by automatic renumbering mechanisms or by schemes that allow hosts to keep the same addresses when they relocate or change providers -- should *not* be specified in the requirements document. After all, we don't yet know if automatic renumbering protocols will work in a sufficently robust and scalable way. Dave Crocker wrote: > One item concerning the range of schemes that are being contemplated: > Since addressing is such a core part of the technology, models which > substantially differ from those that have already been in use carry > with them, in my opinion, inherently large risk. Since they haven't > been used before -- or haven't been used in any large scale -- we can't > claim to understand their physics. Yes, But the model we have experience with -- flat routing among IP "networks" -- is broken, and that is why we are in this mess! We have to do something new, so the risk is inevitable. Dennis wrote: > Routing relationships define topology, not circuitry. Oh, please don't do that! Let's stick with using the word "topology" in its classic, graph-theoretic sense, as simply the interconnection relationship among the nodes and edges (routers, hosts, and links) in the global Internet, i.e., the circuitry. Any properties attached to the nodes or edges, such as routing metrics, or administrator ID, or interior/exterior status, or geographical location or whatever, is information externally applied to the topology, *not* part of the topology itself. We are trying to explore *new*, *improved* routing relationships that can be instantiated on the topology; if you define topology as the existing routing relationships, then discussion has to stop until we come up with a new word for topology! > If geographical assignment of addresses is required we are going to either > have to restructure the way IP service is provisioned in geographical > areas or invent new routing protocols. Roughly correct. The way I would put it is: geographical addressing would require greater connectivity among competing providers than is currently the case, and (by the time we reach the stage of more than about 10,000 Internet subscribers in a metro area) modifications to existing routing protocols. > ...At the current state of the art the assertion of a causal connection > between geography and topology made above is simply false. Agreed. We are proposing to change, maybe even advance :-), the state of the art. Noel wrote: > ... "EIDs" name computational 'objects' engaged in end-end communications, > which have next to no relationship to the network communications substrate. They also do not have a one-to-one relationship to boxes, as you have observed, but others seem less aware of. I would expect you to advocate an EID space that has room for thousands or more EIDs per host, and that are capable of migrating from host to host, but for some reason you fail to stress that to people who think an EID is a shorthand for a domain name, or who think an IEEE 802.1 address would be suitable as an EID. If there really is a need for an extra name space, it is certainly not at the same granularity as an address or a domain name. I think VMTP got it right with its "entity IDs" that correspond to processes or threads, which are indeed fundamental computational objects. (But they are of no concern to the internet layer, whose job it is to deliver packets from box to box.) Frank K. wrote: > Never meant to imply that the DNS suggested network addressing > hierarchies had a relationship. What I said (or meant to say) was > that as we did for DNS, where we defined the top levels of the > hierarchy very early on, delegated authority and let the delegated > authorities define their own sub-hierarchies, we ought to do the same > for hierarchical addressing (e.g. if the address begins with 0x00, > the address is under the "metro/geographic" hierarchy, if 0x02, it is > under the "service provider" hierarchy, and so on). That is the approach taken in the SIP addressing plan. Noel responded to Bill Simpson as follows: > The format proposed [for SIP addresses] is not rigid. It is variable > based on the size of the blocks. > > Yes, but is is flexible enough to be able to aggregate portions of the > network topology about which you wish to make policy statements? No. It is not intended that SIP addresses shall encode policy considerations, any more than postal addresses or phone numbers encode policy considerations. Finally, a number of contributors continue to refer to something called "topologically-based" addressing, and apparently metro-based addressing and provider-based addressing are *not* considered to be "topologically- based": Tony: "Again, I'm not convinced that it should be provider based so much as topologically based..." "Please note that this would NOT preclude pure topological addressing." Noel: "You seem to be assuming that provider addressing is *the* alternative to metro addressing. I'm not sure I agree, even if by 'provider addressing' you really mean 'network topology addressing'." John: "Geographically-based addresses require the same concessions, but cannot provide the optimum aggregation available with topologically- based assignments. Vince: Once that is done [separating EID from address], the whole argument of geography- vs. provider-based "addresses" is irrelevant, since *addresses* can become an exact representation of topological location. What exactly is "pure topological addressing"? In the context of hierarchical addressing (as opposed to, say, strict source routing), I don't think there is any such thing. A topology is just a mesh. It has no "pure" or "natural" or "inherent" hierarchical structure; any such structure is imposed on it using criteria external to the topology itself, such as: who owns or administers the nodes and links, or what metrics have been assigned to the links, or where the nodes are located geographically, or any number of other criteria. If I draw an arbitrary topology, I challenge anyone to tell me what its natural hierarchical structure is, or what "purely topological" addresses should be assigned to each of the nodes or links. For hierarchical routing to work, the region of the topology named by an address prefix must be internally-connected. (Note in passing that tunneling is always available as a method of connecting otherwise disconnected pieces of topology). Each of the addressing hierarchies normally discussed on this list -- metro-based, provider-based, and subscriber-based (or whatever the current IPv4 hierarchy is called) -- are required to satisfy the topological- connectedness requirement on prefixes, and in that sense they are all equally "topologically-based". Other than that, I have no idea what people mean when they talk about "topologically-based addressing", and I sure would like to get that cleared up. Steve From owner-big-internet@munnari.oz.au Mon Feb 8 11:07:11 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA24518; Mon, 8 Feb 1993 11:07:17 +1100 (from owner-big-internet) Return-Path: Received: from zephyr.isi.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19870; Mon, 8 Feb 1993 08:46:28 +1100 (from estrin@ISI.EDU) Received: by zephyr.isi.edu (5.65c/5.61+local-10) id ; Sun, 7 Feb 1993 13:46:48 -0800 Date: Sun, 7 Feb 1993 13:46:48 -0800 Message-Id: <199302072146.AA02482@zephyr.isi.edu> From: estrin@usc.edu (Deborah Estrin) Sender: estrin@ISI.EDU To: yakov@watson.ibm.com Cc: deering@parc.xerox.com, big-internet@munnari.oz.au In-Reply-To: yakov@watson.ibm.com's message of Sat, 6 Feb 93 19:56:02 EST <9302070214.24474@munnari.oz.au> Subject: EGP/IGP split (was Metro Addressing Summary) Reply-To: estrin@usc.edu From: yakov@watson.ibm.com Ref: Your note of Sat, 06 Feb 93 10:25:12 -0500 I would suggest that folks who advocate using LS hop-by-hop forwarding for inter-domain routing would consider how such a scheme would address the following problems: (a) transit policies, where a domain may want to restrict its transit traffic (b) dissimilar route selection policies, where different domains, when presented with the same set of routes would select different one (c) support for information aggregation when the overall inter-domain topology can't be constrained to pure "core" model (ala EGP2). I would be quite interested hearing specific proposals on how the above issues can be addressed (please add the estimated overhead). Yakov. I think yakovs point c is a showstopper all by itself, even if you want to ignore policy (as Steve is sometimes inclined to do :}) From owner-big-internet@munnari.oz.au Mon Feb 8 11:37:26 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA25288; Mon, 8 Feb 1993 11:37:37 +1100 (from owner-big-internet) Return-Path: Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22981; Mon, 8 Feb 1993 10:26:05 +1100 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14139>; Sun, 7 Feb 1993 15:25:48 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Sun, 7 Feb 1993 15:25:36 -0800 To: yakov@watson.ibm.com Cc: big-internet@munnari.oz.au, deering@parc.xerox.com Subject: Re: EGP/IGP split (was Metro Addressing Summary) In-Reply-To: Your message of "Sat, 06 Feb 93 16:56:02 PST." <93Feb6.165602pst.13336@alpha.xerox.com> Date: Sun, 7 Feb 1993 15:25:27 PST Sender: Steve Deering From: Steve Deering Message-Id: <93Feb7.152536pst.12171@skylark.parc.xerox.com> > I would suggest that folks who advocate using LS hop-by-hop > forwarding for inter-domain routing... Yakov, I am not necessarily advocating LS hop-by-hop forwarding for inter-domain routing; I am just trying to learn why it wouldn't work. > ...would consider how such a scheme would address the following problems: > > (a) transit policies, where a domain may want to restrict its > transit traffic > (b) dissimilar route selection policies, where different > domains, when presented with the same set of routes > would select different one Presumably, whatever policy rules are installed in any particular domain-boundary router could simply be added to the link-state database record for that router, and disseminated in the normal LS way. Then any router operating on that database could take those into account when computing routes. I don't know how well that approach would scale, but it at least sounds do-able. Besides, as Deborah noted, I'm not particularly concerned with providing fully-general policy-constrained routing. I'm concerned with routing among a large number of competitive, commercial providers who *want* to carry everyone's traffic. Other than first-hop provider selection, I don't see an absolute requirement that the basic routing mechanisms in the future public Internet handle general policy constraints. Those who have political concerns about how their packets get between A and B can use source routing. > (c) support for information aggregation when the overall > inter-domain topology can't be constrained to pure > "core" model (ala EGP2). The inter-domain routing is performed over a topology consisting of "clouds", where each domain is a cloud, represented as a single node in the inter-domain LS database (and thus aggregated). The topology of clouds can be arbitrary, i.e., it is not limited to being a tree or having a single "core". For greater aggregation, domains can be clustered into larger clouds (e.g., all domains in a single metro area, or all domains served by a single provider), and higher-level LS routing can be performed among the larger clouds, again interconnected in an arbitrary topology. And so on. Steve From owner-Big-Internet@munnari.oz.au Mon Feb 8 14:11:58 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA00264; Mon, 8 Feb 1993 14:12:18 +1100 (from owner-Big-Internet) Return-Path: Received: from Sun.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00245; Mon, 8 Feb 1993 14:11:58 +1100 (from Tom.Kessler@Eng.Sun.COM) Received: from Eng.Sun.COM (zigzag-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA13016; Sun, 7 Feb 93 19:11:42 PST Received: from bigriver.Eng.Sun.COM (bigriver-248) by Eng.Sun.COM (4.1/SMI-4.1) id AA23787; Sun, 7 Feb 93 19:14:58 PST Received: from hacketorium.Eng.Sun.COM by bigriver.Eng.Sun.COM (4.1/SMI-4.1) id AA03734; Sun, 7 Feb 93 19:11:40 PST Date: Sun, 7 Feb 93 19:11:40 PST From: Tom.Kessler@Eng.Sun.COM (Tom Kessler) Message-Id: <9302080311.AA03734@bigriver.Eng.Sun.COM> Received: by hacketorium.Eng.Sun.COM (5.0/SMI-SVR4) id AA16224; Sun, 7 Feb 93 19:12:35 PST To: Jeffrey C Honig Cc: David Oran , big-internet@munnari.oz.au In-Reply-To: <9302051908.AA29284@mitchell.cit.cornell.edu> Subject: Re: Ethernet IDs as EIDs (was: Metro Addressing Summary) Content-Length: 959 Sadly enough almost all Sun's (since late 1982 or so) have the MAC address on the motherboard of the machine *only*. The ethernet cards, FDDI, and etc. all expect to have ifconfig set a MAC address on them. Long ago we (Sun) decided to interpret the MAC address as an EID as a lot of the early literature implied. The fact that it adds a noticeable cost to give each card its own MAC address certainly swung things in that direction. Also with our network implementation it doesn't make sense to plug to interfaces into the same wire or on both sides of bridge (assuming your bridge is up to snuff) so we've always discouraged our customers from doing this. As Jeff mentioned you *can* set the MAC address on a Sun using ifconfig (e.g. our decnet interoperability products have done this for a long time) but somewhere you have to get another MAC address. Rightly or wrongly, I expect it would be very difficult to change the way this is done. From owner-big-internet@munnari.oz.au Mon Feb 8 16:11:46 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA04177; Mon, 8 Feb 1993 16:11:49 +1100 (from owner-big-internet) Return-Path: Message-Id: <9302080511.4177@munnari.oz.au> Received: from research.att.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00706; Mon, 8 Feb 1993 14:24:52 +1100 (from hgs@research.att.com) Received: by inet; Sun Feb 7 22:23 EST 1993 Date: Sun, 7 Feb 93 22:23:55 EST From: hgs@research.att.com (Henning G. Schulzrinne) To: big-internet@munnari.oz.au Subject: metro addressing Cc: deering@parc.xerox.com Apparently, I didn't express myself clearly enough in proposing an NANP area-code based rather than MSA-based allocation. The algorithm could be: metro codes (with numbers different from area codes) are based on the reach of current area codes; if an area code splits, the new area code is simply added to the existing metro region. Example: say, previously western Massachusetts had area code 413. The extent of this area code is defined as one internet 'metro' area. When the area splits (into 413 and 508) nothing changes except that we add 508 to the area covered by the 'metro' area. Thus, there never is any confusion as to where a subscriber belongs or how large a region is (except that I can look it up in any phonebook). The only thing that needs updating is the table used by whoever assigns Internet numbers of which 'metro' areas and which area codes they contain. Naturally, if it is decided for aggregation reasons that San Francisco should have one 'metro' code, nothing prevents us from lumping these three area codes into one 'metro' code. As I mentioned earlier, the number of area codes and MSAs is already within a factor of 1.5 of each other, hardly a significant difference. Basing the metro codes on MSA or any other non-telecom designation has some subtle disadvantages. With area codes, a subscriber that stays put never changes his or her area (using the algorithm above); just the list of area codes mapped to 'metro' codes changes trivially. However, at any time the MSAs that a particular location belongs to can change (as they have recently in the New York area, suddenly adding several counties to the New York City MSA). Thus, the assignment algorithm based on MSAs would have to say 'the assignment is based on MSAs as of February 8, 1993 as specified by the Foo federal agency in the xyz issue of the Federal Register'. This in itself wouldn't be too bad as we could keep a list of all counties within the U.S. and simply map them to SIP metro codes. This, however, should be clearly specified in any spec. (I'm assuming that counties are never split between MSAs or that towns never change county, but somebody may want to check that.) Given the current LATA assignment (which are unlikely to change in the near future at least), the area-code based assignment also has a natural affinity to telecom provisioning. This may make it easier for the RBOCs to enter the Internet provider arena. Since divestiture, my employer obviously doesn't care about that one way or another... (This mapping between the first level of topological aggregation and existing telecom infrastructure may become more important as household Internet service comes into existence. Given the existing telecom infrastructure, I wouldn't be surprised if the RBOCs would play a role in that. We can't just assume the model of effective telephone company bypass that exists today for large customers.) Also, it appears likely that ATM-based public nets will maintain E.164 (telephone number-based) addresses. Clearly, either MSA based (or, rather, in the long term, list-of-county based) or area-code based assignment would work. Re-using an existing very well known numbering scheme with obvious relationship to existing and probable future telecom infrastructure (or 'topology', if that sounds more related to routing) just strikes me as 'simpler'. What is so special about MSAs that I'm missing here? (Or is the Census Bureau or your local county about to offer Internet service? :-)) --- Henning From owner-Big-Internet@munnari.oz.au Mon Feb 8 16:13:53 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA04256; Mon, 8 Feb 1993 16:14:20 +1100 (from owner-Big-Internet) Return-Path: Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04250; Mon, 8 Feb 1993 16:13:53 +1100 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14332>; Sun, 7 Feb 1993 21:13:20 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Sun, 7 Feb 1993 21:13:09 -0800 To: John Curran Cc: big-internet@munnari.oz.au, deering@parc.xerox.com Subject: Re: Metro Addressing In-Reply-To: Your message of "Sun, 07 Feb 93 19:27:22 PST." <93Feb7.192757pst.14282@alpha.xerox.com> Date: Sun, 7 Feb 1993 21:12:57 PST Sender: Steve Deering From: Steve Deering Message-Id: <93Feb7.211309pst.12171@skylark.parc.xerox.com> > ] Yes, that is what I would expect in the current Internet, given that the > ] burden of changing addresses is a significant deterrent to your customers > ] switching to another provider. > > I don't follow this: currently, there is _no_ requirement to change > addresses when changing providers, so a deterrent does not exist. Oops! Right you are. Temporary lapse on my part. (At least, I *hope* it's temporary.) > ] ..., I have no idea what people mean when they talk about > ] "topologically-based addressing", and I sure would like to get that > ] cleared up. > > It is "the use of addresses corresponding to a particular hierarchy > derived from an otherwise mesh topology". In other words, select an > arbitrary "top", and assign addresses downward in sync with topology. Could you be more specific about what it means to assign addresses downward? How many levels of hierarchy are you going to have, or is that something derived from the topology itself, and if so, how? What criteria do you use to decide whether two neighboring nodes are in the same or different clusters (i.e., have the same or a different prefix)? Steve From owner-big-internet@munnari.oz.au Mon Feb 8 17:41:29 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA07023; Mon, 8 Feb 1993 17:41:33 +1100 (from owner-big-internet) Return-Path: Message-Id: <9302080641.7023@munnari.oz.au> Received: from nic.near.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00831; Mon, 8 Feb 1993 14:27:38 +1100 (from jcurran@nic.near.net) To: Steve Deering Cc: big-internet@munnari.oz.au Subject: Re: Metro Addressing In-Reply-To: Your message of Sun, 07 Feb 93 13:52:14 -0800. <93Feb7.135215pst.12171@skylark.parc.xerox.com> Date: Sun, 07 Feb 93 22:27:22 -0500 From: John Curran -------- ] From: Steve Deering ] Subject: Re: Metro Addressing ] Date: Sun, 7 Feb 1993 13:52:14 PST ] ] > [Noel] ] > So here's what I don't get. Isn't this an expensive way to provide ] > service mobility? If you must have a 'name' other than the DNS name which ] > doesn't change when you move around in the network, wouldn't another ] > namespace, and a translation from that namespace to a topologically ] > significant name (used by the routing) be a better engineering solution to ] > this problem? ] ] That depends on the expense of the additional-namespace alternative, and on ] important factors other than expense, such as robustness, responsiveness, ] scalability, and administrative overhead. Agreed. The addition of an EID namespace requires an extraordinary amount of work, and the requirements for the distributed directory exceed existing practice. This is why I am not advocating my tune draft as a possible IPv7 solution: the timeline for gaining sufficient trial experience will easily exceed current estimates of route congestion. (This is also why I am very interested in the impact of CIDR deployment on the timeline.) Using an EID space to address the problem will definitely require research, and the current solution process is emphasizing implementation and use of proven technology. (Nothing wrong with that...) ] That's a good question. I assume that providers might charge for this service, ] but at a rate less than the full subscription rate. Maybe it will become a ] competitive necessity to provide the service, e.g., sites will refuse to ] subscribe to any provider that does not offer free or cheap redirection ] service for a short period after service termination. Maybe it will be ] required by the local Public Utilities Commission or equivalent. I dunno. It's likely that providers would offer the service; you'd actually be amazed the level of cooperation that exists among most providers. W.r.t to the local PUC: first, you go explain it to them, then you get to do cost accounting for it... (No thanks, I'd rather just offer it for free :-) ] John Curran wrote, in response to Christian: ] ] > It does depend how how "small" the regions are. This past summer, we've had ] > more than a dozen NEARnet members move within New England. All of this was ] > done without addressing changes, whereas under metro-based addresses most ] > would had to change. (In the same time, we've had only a handful of cross- ] > provider changes). ] ] Yes, that is what I would expect in the current Internet, given that the ] burden of changing addresses is a significant deterrent to your customers ] switching to another provider. I don't follow this: currently, there is _no_ requirement to change addresses when changing providers, so a deterrent does not exist. I was simply pointing out that while provider changes occur, they are an order of magnitude less frequent than corporate Brownian motion. ] Do you have significant competition in your market, such that there are s ] service-competitive alternatives for your customers to choose among? I'm the wrong person to ask (;-), but let's say that there are other providers in our service area of varying costs and ability. ] Anyway, I don't think "more than a dozen moves" vs. "a handful of ] cross-provider changes" can be read as a significant prediction of the ] behavior of an Internet in which many, many more small businesses and ] households are consumers of commercial, competitive Internet service. Agreed. However, it's the only data that we have at present. I am not advocating provider-based addresses (I'd prefer the long-term work into eid-based transport) but simply pointing out that changing metro areas occurs frequently enough to be a consideration. ] Tony Li wrote: ] ] > ... I think that we SHOULD point out that the ability to ] > renumber, whether for the case of host relocation or provider change ] > is a very strong requirement for IP7. ] ] The desired property is that manual renumbering be unnecessary. How this is ] accomplished -- whether by automatic renumbering mechanisms or by schemes ] that allow hosts to keep the same addresses when they relocate or change ] providers -- should *not* be specified in the requirements document. Full agreement here. The desired property (but not mechanism) should be in the requirements. ] Dave Crocker wrote: ] ] > One item concerning the range of schemes that are being contemplated: ] > Since addressing is such a core part of the technology, models which ] > substantially differ from those that have already been in use carry ] > with them, in my opinion, inherently large risk. Since they haven't ] > been used before -- or haven't been used in any large scale -- we can't ] > claim to understand their physics. ] ] Yes, But the model we have experience with -- flat routing among IP ] "networks" -- is broken, and that is why we are in this mess! ] We have to do something new, so the risk is inevitable. Understanding the amount of time that we have is essential to balancing the risk of new technology. ] They also do not have a one-to-one relationship to boxes, as you have ] observed, but others seem less aware of. I would expect you to advocate an ] EID space that has room for thousands or more EIDs per host, and that are ] capable of migrating from host to host, but for some reason you fail to ] stress that to people who think an EID is a shorthand for a domain name, or ] who think an IEEE 802.1 address would be suitable as an EID. If there really ] is a need for an extra name space, it is certainly not at the same ] granularity as an address or a domain name. I think VMTP got it right ] with its "entity IDs" that correspond to processes or threads, which are ] indeed fundamental computational objects. (But they are of no concern to ] the internet layer, whose job it is to deliver packets from box to box.) There is still much discussion over EID properties, and the requirements seem to vary slightly from proposal to proposal. If you always use EID's in conjuction with existing Internet transport protocols such as TCP and UDP, then the presence of port numbers obviates the need for more detailed EIDs. Yes, it would be possible to totally redefine these at the same time as IPv7, but we've got enough compatibility problems as it is. ] Finally, a number of contributors continue to refer to something called ] "topologically-based" addressing, and apparently metro-based addressing ] and provider-based addressing are *not* considered to be "topologically- ] based": ] ... ] John: "Geographically-based addresses require the same concessions, but ] cannot provide the optimum aggregation available with topologically- ] based assignments. ] ] ..., I have no idea what people mean when they talk about ] "topologically-based addressing", and I sure would like to get that ] cleared up. It is "the use of addresses corresponding to a particular hierarchy derived from an otherwise mesh topology". In other words, select an arbitrary "top", and assign addresses downward in sync with topology. Renumber when topology changes. This may sound quite absurd, but the actual Internet topology does resemble a hierarchy at the customer interface, and will probably continue to do so in the future. Customers are inherently "downstream" and hence addressing in that manner is quite functional. /John From owner-big-internet@munnari.oz.au Mon Feb 8 20:05:40 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA10844; Mon, 8 Feb 1993 20:05:52 +1100 (from owner-big-internet) Return-Path: Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05307; Mon, 8 Feb 1993 16:47:50 +1100 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14357>; Sun, 7 Feb 1993 21:47:23 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Sun, 7 Feb 1993 21:47:13 -0800 To: hgs@research.att.com (Henning G. Schulzrinne) Cc: big-internet@munnari.oz.au, deering@parc.xerox.com Subject: Re: metro addressing In-Reply-To: Your message of "Sun, 07 Feb 93 19:23:55 PST." <93Feb7.192410pst.14274@alpha.xerox.com> Date: Sun, 7 Feb 1993 21:47:12 PST Sender: Steve Deering From: Steve Deering Message-Id: <93Feb7.214713pst.12171@skylark.parc.xerox.com> OK, Henning, now I understand better what you had in mind. The use of the Metro Census Areas is just to identify the major population centers in the country. The operative word is "centers" -- the exact boundaries don't matter, and would be fuzzy. A site's metro-based address prefix would be determined from the metro center in which it is attached to its provider(s) (or the metro center in which it is most likely to attach, if it is not yet attached), *not* from the geographical location of the site itself. For example, if a site in San Francisco chooses, for whatever reasion, to get a leased line to a provider in Los Angeles, the site will be assigned a Los Angeles metro prefix. So, the fact that MSA boundaries will vary over time is not important. The problem is to identify a set of points (metro centers), not a set of metro boundaries. I believe MSAs are a better starting point than area codes, because area codes are too fine grain in the major metros. Steve From owner-big-internet@munnari.oz.au Mon Feb 8 21:23:00 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12744; Mon, 8 Feb 1993 21:23:09 +1100 (from owner-big-internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07687; Mon, 8 Feb 1993 18:03:26 +1100 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA03094; Mon, 8 Feb 93 02:03:11 -0500 Date: Mon, 8 Feb 93 02:03:11 -0500 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9302080703.AA03094@ginger.lcs.mit.edu> To: peter@goshawk.lanl.gov Subject: Re: re routing difference between phone and internet Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu Yah, I suppose it sort of is 'dynamic within policy constraints'. It's just that the constraints are stated in such a clumsy way (in terms of which providers they can come through, rather than giving their public key, or something) that I think of it as semi-static routing. Noel From owner-big-internet@munnari.oz.au Mon Feb 8 22:58:16 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15117; Mon, 8 Feb 1993 22:58:21 +1100 (from owner-big-internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05010; Mon, 8 Feb 1993 16:39:46 +1100 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA02610; Mon, 8 Feb 93 00:35:31 -0500 Date: Mon, 8 Feb 93 00:35:31 -0500 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9302080535.AA02610@ginger.lcs.mit.edu> To: deering@parc.xerox.com, dennis@ans.net Subject: Re: EGP/IGP split (was Metro Addressing Summary) Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu You can aggregate between areas in both directions, ... but this is not aggregation "within an LS-routed topology". Nope. OSPF does do topology abstraction, it is just that the abstraction model is pretty simplistic (to reduce the complexity of the protocol, mainly), and it is not discussed in high-level terms as an abstraction model, but rather somewhat mechanistically, in terms of what nodes show up in the graph, how the algorithms work, etc, etc. (I use the term abstraction, rather than aggregation, since the latter applies principally to DV systems.) Each area is a separate chunk of topology, and routers in neighbouring areas view their neighbours as address information grafted on the edges of their own topology. You know the topology within your own area, but only the next hop for everything else. Yup. Like I said, it's a very simple abstraction model, as simple in its own way as the abstraction model used in, e.g., RIP, where subnet routes never show outside a network. To start, remember that the OSPF network graph includes two kidns of nodes, network nodes and router nodes; a simplified graph will still contain both, but will have gotten rid of some of each. The model is simply that, outside an area, the *only* topology representation for that area is (effectively) as a single node to which all the border routers of that area have a link. (I know, he has a different metric for each network inside the area; think about the case where an area has only a single network, for clarity. The model generalizes to multiple networks easily.) However, it's not even this powerful, since John Moy decided not to allow those border routers to communicate through the area unless you explicitly configure a virtual link. So, it is effectively modelled as N separate but identical nodes, one copy for each border router which connects to that area. It would have been possible to model an area in a number of different ways, but each has disadvantages, and John decided to skip the whole issue by picking the extremely simplistic model he did. For instance, he could have modelled an area as a single 'area node' to which each border router is then connected. The bug with this is that it is impossible to assign a single metric to the link from a border router to the area node which will, when pairwise combined with the metrics for the other border routers of that area, correctly reproduce the actual metric for the path across the area between that pair. If he modelled an area a N^2 connections between all the border routers, plus connections from each border router to an area node, he would have got the right metrics, but at the cost of a (usually) more complex representation than what he started with. You can build more complex abstractions of areas in OSPF than the one you describe, by use of the 'virtual link' facility, but the basic model is the simplistic one you describe. In effect, he punted the abstraction algorithm issue (which is a difficult one with no easy solution), since he wanted something which was automatic, simple, and worked, and made anything more complex an issue for manual configuration, outside the scope of the protocol. Noel From owner-big-internet@munnari.oz.au Mon Feb 8 23:56:31 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA16712; Mon, 8 Feb 1993 23:56:34 +1100 (from owner-big-internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07315; Mon, 8 Feb 1993 17:51:13 +1100 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA02812; Mon, 8 Feb 93 01:50:48 -0500 Date: Mon, 8 Feb 93 01:50:48 -0500 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9302080650.AA02812@ginger.lcs.mit.edu> To: jnc@ginger.lcs.mit.edu, tli@cisco.com Subject: Re: EGP/IGP split (was Metro Addressing Summary) Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu So stipulated. ;-) I know, I know, I should count to 1 million first.... :-) Well, I can't speak to true MD algorithms. As far as I know, they only exist in your neurons. I use the term Map Distribution rather than Link State or Shortest Path First, since to many people those terms imply something like the New ARPANet algorithm, or IS-IS/OSPF (i.e. hop-by-hop routed, with calculation of the complete routing table every time a topology change happens, which causes a completely flooded update). Map Distribution just means what it says; all algorithms that work by distributing topology maps (partial or complete). All SPF algorithms are MD algorithms; IDPR is also an MD algorithm... But we can look at existing LS implementations. These have the requirement that abstraction only happen at particular boundaries, either between areas or on the border of the link state system. This lack of flexibility IS an inherent disadvantage when compared to an algorithm which allows arbitrary abstraction at any point in the system. ... To the best of MY knowledge, there is no way to aggregate within an area with existing link states. True, but as you point out, this is only in existing LS systems. It's not a funamental limit of all MD systems. Please point me to the approrpiate documents... Sorry, don't know of any. Baruch Awerbach at MIT has started thinking about the effects of abstraction on routing optimality, but the only paper I can find from him is one on DV stuff. The only difference is that MD systems have a lot more flexibility in how they do abstraction, particularly if they are source-routed. I think that this is a dangerous comparison as you invite us to compare LS with source routing vs. DV/PV with HbH routing. What I was meaning to get at was that in the same way that routing information distribution and route calculation are clearly separated in LS systems (allowing route calculation on demand), as compared to the way the two are intimately intermingled in DV, you get *something* of the same separation of abstraction issues in MD systems, although it's not as complete, obviously. It's difficult to measure how much better MD systems are, since the abstraction proceeds on different objects (topology as opposed to routing table entries). Still, you do have the *opportunity* to bypass the remote abstraction process if you want in SR-MD, whereas you really can't in HbH-DV. LS does inherently have more information available. This information has ALREADY been abstracted away by the DV/PV protocol. Is this relevant? If both are doing HbH, then probably not. You have no way of using the additional information. Well, there are a few advantages, but obviously not as many. There is the issue of less bandwidth/faster response time for LS, but more important is support for delayed route computation. If you had a routing architecture with N different TOS types, which can be combined in N! ways, and which can be fully expressed in packets, you would only want to compute various TOS combination routes on demand; you'd never need them all. This would only be possible with LS-HbH. Still, in general, I agree with you; MD with HbH is far less interesting than MD-SR. Fine, now let's consider an SDRP-style protocol with dynamic information retrieval on top of a PV protocol. [I will not claim that this is counts as MD, but I would still like to know if you think so or not, Noel.] Yes, if you distibute topology information (and it can be on demand as well as automatically), it's an MD system. I believe that we've already had this discussion. It depends on whether or not the bulk of the traffic is source routed or HbH. I believe we agreed that it was not at all clear... Yes, it's an engineering issue as to whether you have a PV-HbH/MD-SR mix (Unified), or just pure MD-SR (Nimrod), and my decision factors include things like guesses about trafic mix, feelings about robustness, etc, but these are engineering issues, and a long way from whether or not MD system can do abstraction! Harsh reality with broken LS implementations is that they don't stabilize either. In fact, one of the interesting things that happen with broken LS implementations is that since all routers perform the exact same computation, they execute the exact same code path in near-perfect synchrony. When that code path is defective, you now have the possibility of a distributed, synchronized, catastrophic, system-wide, router crash. Yes, but isn't this HbH-MD? SR-MD systems (particulary those with Byzantize robustness techniques of the type outlines by Radia Perlman) would probably be a little more bullet-proof.... The axes along which they are cheaper are a) they take less line bandwidth, and b) they stabilize in a bounded and faster time than DV algorithms. (Spare me the comments about Jose's work; if you read the fine print it bears all these points out.) Let's just say I'm not convinced about ANY of this, and yes, I've read the fine print. OK, here's an example, from "Dynamics of Distributed Shortest Path Routing Algorithms", Zaumen and Garcia-Luna, which modelled operation of DUAL (their optimized DV algorithm), vanilla DV (ignored hereafter since it's awful), and a Link State algorithm in several real topologies (ARPANet, MILNet, and several smaller nets), with various simulated random failures. In both Node-failure and Link-failure cases, for all the topologies, DUAL takes, on average, more time and more packets to respond than a LS algorithm. In addition, the standard deviation is smaller for LS; i.e. the use of these resources is more bounded. These differences are larger on the larger nets (MILNet) than on the smaller ones. Don't get me wrong, DUAL has some interesting ideas on how to prevent even transient loops (which could be applied to LS, as the original "Unified Approach to Loop Free Routing Using DV or LS" paper showed), etc, but LS algorithms do have *some* advantages. But does the abstraction have to be manually configured? I view this as the #1 problem with existing routing: too much to configure. ... The real scaling problem is human bandwidth. Until we can design a routing protocol that requires NO human intervention, then routing cannot scale. So how do we do _automatic_ abstraction? Sadly, I don't think there is a completely automatic algorithm. As I indicated in my previous message about OSPF, automatic algorithms have problems, even in the simplistic case with no policies. Also, there are too many cost/benefit tradeoffs to be made, and those are inherently policy decisions. Humans are *always* going to want to toy with the routing, which is why I think we need a design that allows them to do so. I like MD-SR since the abstraction is a bit more uncoupled there (and thus easier to play with) than in DV-HbH. Noel From owner-big-internet@munnari.oz.au Tue Feb 9 00:08:21 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17465; Tue, 9 Feb 1993 00:08:26 +1100 (from owner-big-internet) Return-Path: Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10364; Mon, 8 Feb 1993 19:46:25 +1100 (from tli@cisco.com) Received: by lager.cisco.com; Mon, 8 Feb 1993 00:45:50 -0800 Date: Mon, 8 Feb 1993 00:45:50 -0800 From: Tony Li Message-Id: <199302080845.AA17282@lager.cisco.com> To: jnc@ginger.lcs.mit.edu Cc: jnc@ginger.lcs.mit.edu, tli@cisco.com, big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu In-Reply-To: Noel Chiappa's message of Mon, 8 Feb 93 01:50:48 -0500 <9302080650.AA02812@ginger.lcs.mit.edu> Subject: EGP/IGP split (was Metro Addressing Summary) Map Distribution just means what it says; all algorithms that work by distributing topology maps (partial or complete). All SPF algorithms are MD algorithms; IDPR is also an MD algorithm... By this definition, SDRP with dynamic topology discovery should be considered a MD algorithm, although it is based on a PV. In fact, I'm not convinced that a PV algorithm itself is not part of MD: the result is a source tree of the topology. Thus, the space of MD would seem to be that of all routing protocols less distance vector. PV with aggregation gets to be really fun: you get topology to the point of aggregation. But we can look at existing LS implementations. These have the requirement that abstraction only happen at particular boundaries, either between areas or on the border of the link state system. This lack of flexibility IS an inherent disadvantage when compared to an algorithm which allows arbitrary abstraction at any point in the system. ... To the best of MY knowledge, there is no way to aggregate within an area with existing link states. True, but as you point out, this is only in existing LS systems. It's not a funamental limit of all MD systems. Ok, but what remains in this space? PV, SDRP with dynamic discovery, and ...? What I was meaning to get at was that in the same way that routing information distribution and route calculation are clearly separated in LS systems (allowing route calculation on demand), as compared to the way the two are intimately intermingled in DV, you get *something* of the same separation of abstraction issues in MD systems, although it's not as complete, obviously. It's difficult to measure how much better MD systems are, since the abstraction proceeds on different objects (topology as opposed to routing table entries). Still, you do have the *opportunity* to bypass the remote abstraction process if you want in SR-MD, whereas you really can't in HbH-DV. Agreed. Still, in general, I agree with you; MD with HbH is far less interesting than MD-SR. Wow! ;-) ;-) ;-) Harsh reality with broken LS implementations is that they don't stabilize either. In fact, one of the interesting things that happen with broken LS implementations is that since all routers perform the exact same computation, they execute the exact same code path in near-perfect synchrony. When that code path is defective, you now have the possibility of a distributed, synchronized, catastrophic, system-wide, router crash. Yes, but isn't this HbH-MD? SR-MD systems (particulary those with Byzantize robustness techniques of the type outlines by Radia Perlman) would probably be a little more bullet-proof.... I think that HbH/SR is irrelevant in this particular instance. The point is that when all elements of a system are identical and are synchronized, then the same bug manifests itself identically throughout the system. I believe that Radia's techniques don't help here at ALL. The axes along which they are cheaper are a) they take less line bandwidth, and b) they stabilize in a bounded and faster time than DV algorithms. (Spare me the comments about Jose's work; if you read the fine print it bears all these points out.) Let's just say I'm not convinced about ANY of this, and yes, I've read the fine print. OK, here's an example, from "Dynamics of Distributed Shortest Path Routing Algorithms", Zaumen and Garcia-Luna, which modelled operation of DUAL (their optimized DV algorithm), vanilla DV (ignored hereafter since it's awful), and a Link State algorithm in several real topologies (ARPANet, MILNet, and several smaller nets), with various simulated random failures. In both Node-failure and Link-failure cases, for all the topologies, DUAL takes, on average, more time and more packets to respond than a LS algorithm. In addition, the standard deviation is smaller for LS; i.e. the use of these resources is more bounded. These differences are larger on the larger nets (MILNet) than on the smaller ones. I think it only fair in this case to point out that these papers are discussing theoretical cases. I think that for the real world, it is much more relevant to compare the instantiations of these routing algorithms. Don't get me wrong, DUAL has some interesting ideas on how to prevent even transient loops (which could be applied to LS, as the original "Unified Approach to Loop Free Routing Using DV or LS" paper showed), etc, but LS algorithms do have *some* advantages. No argument. But are we past the point of relevance once we get here? Once we get past the _really awful_ protocols, does it have any operational impact any more? But does the abstraction have to be manually configured? I view this as the #1 problem with existing routing: too much to configure. ... The real scaling problem is human bandwidth. Until we can design a routing protocol that requires NO human intervention, then routing cannot scale. So how do we do _automatic_ abstraction? Sadly, I don't think there is a completely automatic algorithm. As I indicated in my previous message about OSPF, automatic algorithms have problems, even in the simplistic case with no policies. Also, there are too many cost/benefit tradeoffs to be made, and those are inherently policy decisions. Humans are *always* going to want to toy with the routing, which is why I think we need a design that allows them to do so. I like MD-SR since the abstraction is a bit more uncoupled there (and thus easier to play with) than in DV-HbH. Violent agreement on all counts. And I have no objections to playing with routing. But I would like the default to be to do something intelligent. And in this case, that should be some form of abstraction. I can imagine implementations of BGP4 for example that would take two adjacent NLRI and aggregate them if the first 6 ASs were identical... The goal, I think is that we only have to play with routing if we find that we have the time/motivation to do so and that the automatic mode scales well. Tony From owner-big-internet@munnari.oz.au Tue Feb 9 00:33:50 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA18061; Tue, 9 Feb 1993 00:33:54 +1100 (from owner-big-internet) Return-Path: Received: from itd.nrl.navy.mil by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14236; Mon, 8 Feb 1993 22:21:54 +1100 (from atkinson@itd.nrl.navy.mil) Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA29953; Mon, 8 Feb 93 06:21:39 EST Date: Mon, 8 Feb 93 06:21:39 EST From: atkinson@itd.nrl.navy.mil (Ran Atkinson) Message-Id: <9302081121.AA29953@itd.nrl.navy.mil> To: big-internet@munnari.oz.au Subject: Re: Metro Addressing If I might inject a little dissent here, I don't think that metro-based addressing works at all well for organisations that have significant private networks. For example, GE has net 3 and you may rest assured that they have a VERY large private network that runs worldwide. Similarly the DISA runs several large private networks for the DoD and parts of the Navy run significant private networks (again, both are worldwide). I can actually think of a lot of commercial organisations that have multiple locations and have (and desire to continue to have) private networks that will be unhappy at having to conform to a metro-based address plan. For example, the organisation might want to organise its subnets based on internal organisation rather than on geography. Many firms do not desire that folks outside their firm be aware of much information about their internal hosts, even though those hosts might be reachable. Also, many firms have security concerns that are not fully addressed with existing implementations of IP/CLNP and are not sure they want to pay more for security protocols and might prefer to just run their own private net with firewalls for security. While I recognise the appeal of metro-based addressing, I would suggest that we also need to permit a significant number of private networks to continue to exist outside the metro addressing plan. I think this probably leads to the conclusion that the address space needs to be partitioned roughly 4 ways (at least): IPv4 addressing, metro addressing, private network addressing, and multicast addressing. Ran atkinson@itd.nrl.navy.mil P.S. I am not personally a fan of metro addressing, but it is clear that many folks think they are in favor of it so I continued to include it in the 4-way partitioning... From owner-Big-Internet@munnari.oz.au Tue Feb 9 00:40:33 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA18238; Tue, 9 Feb 1993 00:40:48 +1100 (from owner-Big-Internet) Return-Path: Message-Id: <9302081340.18238@munnari.oz.au> Received: from nic.near.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18215; Tue, 9 Feb 1993 00:40:33 +1100 (from jcurran@nic.near.net) To: Steve Deering Cc: big-internet@munnari.oz.au Subject: Re: Metro Addressing In-Reply-To: Your message of Sun, 07 Feb 93 21:12:57 -0800. <93Feb7.211309pst.12171@skylark.parc.xerox.com> Date: Mon, 08 Feb 93 08:40:21 -0500 From: John Curran -------- ] From: Steve Deering ] Subject: Re: Metro Addressing ] Date: Sun, 7 Feb 1993 21:12:57 PST ] ] Could you be more specific about what it means to assign addresses downward? ] How many levels of hierarchy are you going to have, or is that something ] derived from the topology itself, and if so, how? What criteria do you use ] to decide whether two neighboring nodes are in the same or different ] clusters (i.e., have the same or a different prefix)? Good questions... I'll answer with NSAP assignments since we don't have any IPvN around: The levels are derived from the topology itself. Financial considerations decide where a connection is made into the topology, and hence the address assignment. Within a provider, the ability to carry additional routing information is require when a site moves, but such information remains internal to the provider, and only a route for the address prefix of the provider is exchanged with others. I presented this at one of the NOOP wg meetings, and while it is functional, it has the very undesirable properties of requiring the routing exchange of site prefixes when sites change providers, _or_ mandating renumbering at such time. It works fine for now (but that's because no one in the "extensive" OSI deployment has moved yet... :-) /John From owner-Big-Internet@munnari.oz.au Tue Feb 9 02:02:17 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA20240; Tue, 9 Feb 1993 02:02:25 +1100 (from owner-Big-Internet) Return-Path: Received: from babyoil.ftp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20236; Tue, 9 Feb 1993 02:02:17 +1100 (from kasten@ftp.com) Received: by ftp.com id AA28737; Mon, 8 Feb 93 10:02:23 -0500 Date: Mon, 8 Feb 93 10:02:23 -0500 Message-Id: <9302081502.AA28737@ftp.com> To: dennis@ans.net Subject: Re: EGP/IGP split (was Metro Addressing Summary) From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: Christian.Huitema@sophia.inria.fr, big-internet@munnari.oz.au Dennis, After re-reading my note and your comments, I agree with you in that what we have _today_ is not quite a hierarchy of LS protocols. I also see that I did not state my point as clearly as I intended. In my example, I should have said something like "if FTP used OSPF for its internal subnet routing" The problem is that today we can not go higher than two levels of routing since that is all that we have hierarchy for in the IPv4 address. If we had more hierarchy available in the address then each level of the hierarchy could treat the networks at lower-hierarchical levels as single vertices on the network topology, (even though those vertices expand into their own networks). Similarly, the higher level of the hierarchy would look like the default route. > > We already do this. Suppose that NEARNET uses OSPF internally for > > their routing. OSPF would pass around routing information for > > 128.127, which is FTP's network. However, internal to FTP we have > > subnetted our net. We've already aggregated the topological > > information. OSPF treats all of FTP's networks as a single vertex on > > the graph, named 128.127. If the addressing was truly hierarchical > > (e.g. 128 meant nearnet and 128.127 meant FTP in NEARNET) then this > > could be continued up the hierarchy. If the NSFNET backbones did LS > > routing, then NEARNET would appear on their network as a single > > vertex, labelled 128. > > What you are describing here is not a "hierarchy of LS protocols", but > rather just the two-layer IGP/EGP split. From the point-of-view of > the IGP there is an internal topology of routers (nodes) and physical > links with external address information grafted on to the nodes at > the edges. From the point-of-view of the EGP the nodes, if anything > at all, are the clumps of topology routed by a single (or a set of > coordinated) IGP(s) and the links are the EGP connections between them. > You don't really go "up" or "down" any hierarchy when you pass from FTP's > network to NEARnet to the NSFnet, you just cross from one node to another > in the EGP topology. - Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From owner-big-internet@munnari.oz.au Tue Feb 9 02:11:39 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA20432; Tue, 9 Feb 1993 02:11:43 +1100 (from owner-big-internet) Return-Path: Message-Id: <9302081511.20432@munnari.oz.au> Received: from research.att.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18314; Tue, 9 Feb 1993 00:44:13 +1100 (from hgs@research.att.com) Received: by inet; Mon Feb 8 08:43 EST 1993 Date: Mon, 8 Feb 93 08:43:48 EST From: hgs@research.att.com (Henning G. Schulzrinne) To: deering@parc.xerox.com Subject: MSAs Cc: big-internet@munnari.oz.au Steve, a couple of points. 1) You keep bringing up that area codes are too fine-grained particularly in metropolitan areas. As I said earlier, there is nothing to prevent Internet numbering space designers to lump several telephone area codes into one 'Internet area code'. Actually, a LATA typically already combines several area codes in the big-city cases, so it might be a good starting point. 2) The major issue is the that the metro area of the attachment point may or MAY NOT have any relationship to existing wires. The existing (telephone-derived) wires are as far as I know oriented around the LATA boundaries, which form the rough equivalent of the continental divide, i.e., subscriber wires on one side of the boundary flow towards switching facilities in the 'center' of that LATA, while those just on the other side flow towards a different set of switching centers in the adjacent LATA. Using your attachment point model, there appear to be two options: A) use the physical location of the demarc (which may be different from the street address of the subscriber) B) use the location of the first-level switching office/POP/mux. etc. Option A: --------- If you define the attachment point address based on its physical location, you have the problem that such attachment points within the same MSA (i.e., with the same metro address) may be connected only several levels up the wiring hierarchy. Scenario: Say IBM Yorktown and AT&T Murray Hill both attach to the provider network (via the phone company) within the NYC MSA; thus, they both get the same metro code. Assume that IBM is within one LATA (wired by NYTel) and AT&T within another (served by NJ Bell), thus their wires point in completely different directions, go to different POPs, etc. Option B: --------- Now, if you define attachment point 'electrically', i.e., which telco office does the wire that starts at my demarc in my basement end up in, you are basically back to LATA/area-code-based assignment, with the MSA just a smokescreen. (As you would probably just look at the area code of the subscriber's phone number to determine that, at least for all but the largest customers.) Executive Summary ----------------- In short: with proper aggregation, LATAs/area-codes divide the U.S. into about the same number of chunks as MSAs. LATA-based assignment is reflected in physical (wiring) topology that matters, MSA-based assignment is not. Henning P.S. Below is the current LATA table; as you can see, San Francisco is one LATA :-) You'll also find that many LATAs almost coincide with MSAs (at least in where they are centered). The misspellings are straight from the source. AK ALASKA 832 AL BIRMINGHAM 476 AL HUNTSVILLE 477 AL MONTGOMERY 478 AL MOBILE 480 AR FORT SMITH 526 AR LITTLE ROCK 528 AR PINE BLUFF 530 AZ PHOENIX 666 AZ TUCSON 668 AZ NAVAJO RESERVATION 980 CA SAN FRANCISCO 722 CA CHICO 724 CA SACRAMENTO 726 CA FRESNO 728 CA LOS ANGELES 730 CA SAN DIEGO 732 CA BAKERSFIELD 734 CA MONTEREY 736 CA STOCKTON 738 CA SAN LUIS OBISPO 740 CA PALM SPRINGS 973 CO DENVER 656 CO COLORADO SRPINGS 658 CT CONNECTICUT 920 DC WASHINGTON 236 FL PENSACOLA 448 FL PANAMA CITY 450 FL JACKSONVILLE 452 FL GAINESVILLE 454 FL DAYTONA BEACH 456 FL ORLANDO 458 FL SOUTHEAST 460 FL FORT MYERS 939 FL GULF COST 952 FL TALLAHASSEE 953 GA ATLANTA 438 GA SAVANNAH 440 GA AUGUSTA 442 GA ALBANY 444 GA MACON 446 HI HAWAII 834 IA SIOUX CITY 630 IA DES MOINES 632 IA DAVENPORT 634 IA CEDAR RAPIDS 635 ID IDAHO 652 ID COEUR D'ALENE 960 IL CHICAGO 358 IL ROCKFORD 360 IL CAIRO 362 IL STERLING 364 IL FORREST 366 IL PEORIA 368 IL CHAMPAIGN 370 IL SPRINGFIELD 372 IL QUINCY 374 IL MATTOON 976 IL GALESBURG 977 IL OLNEY 978 IN EVANSVILLE 330 IN SOUTH BEND 332 IN AUBURN/HUNTINGTON 334 IN INDIANAPOLIS 336 IN BLOOMINGTON 338 IN RICHMOND 937 IN TERRE HAUTE 938 KS WICHITA 532 KS TOPEKA 534 KY LOUISVILLE 462 KY OWENSBORO 464 KY WINCHESTER 466 LA SHREVEPORT 486 LA LAFAYETTE 488 LA NEW ORLEANS 490 LA BATON ROUGE 492 MA WESTERN MASSACHUSETT 126 MA EASTERN MASSACHUSETT 128 MD BALTIMORE 238 MD HAGERSTOWN 240 MD SALISBURY 242 ME MAINE 120 MI DETROIT 340 MI UPPER PENINSULA 342 MI SAGINAW 344 MI LANSING 346 MI GRAND RAPIDS 348 MN ROCHESTER 620 MN DULUTH 624 MN ST CLOUD 626 MN MINNEAPOLIS 628 MO ST LOUIS 520 MO WESTPHALIA 521 MO SPRINGFIELD 522 MO KANSAS CITY 524 MS JACKSON 482 MS BILOXI 484 MT GREAT FALLS 648 MT BILLINGS 650 MT KALISPELL 963 NC ASHEVILLE 420 NC CHARLOTTE 422 NC GREENSBORO 424 NC RALEIGH 426 NC WILMINGTON 428 NC FAYETTEVILLE 949 NC ROCKY MOUNT 951 ND FARGO 636 ND BISMARCK 638 NE OMAHA 644 NE GRAND ISLAND 646 NE LINCOLN 958 NH NEW HAMPSHIRE 122 NJ ATLANTIC COSTAL 220 NJ DELAWARE VALLEY 222 NJ NORTH JERSEY 224 NM NEW MEXICO 664 NV RENO 720 NV PAHRUMP 721 NY NEW YORK METRO 132 NY POUGHKEEPSIE 133 NY ALBANY 134 NY SYRACUSE 136 NY BINGHAMTON 138 NY BUFFALO 140 NY FISHERS ISLAND 921 NY ROCHESTER 974 OH CLEAVELAND 320 OH YOUNGSTOWN 322 OH COLUMBUS 324 OH AKRON 325 OH TOLEDO 326 OH DAYTON 328 OH CINCINNATI BELL 922 OH MANSFIELD 923 OK OKLAHOMA CITY 536 OK TULSA 538 OR EUGENE 670 OR PORTLAND 672 PA CAPITAL 226 PA PHILADELPHIA 228 PA ALTOONA 230 PA NORTHEAST 232 PA PITTSBURG 234 PA ERIE 924 PR PUERTO RICO 820 RI RHODE ISLAND 130 SC GREENVILLE 430 SC FLORENCE 432 SC COLUMBIA 434 SC CHARLESTON 436 SD SOUTH DAKOTA 640 TN MEMPHIS 468 TN NASHVILLE 470 TN CHATTANOOGA 472 TN KNOXVILLE 474 TN BRISTOL 956 TX EL PASO 540 TX MIDLAND 542 TX LUBBOCK 544 TX AMARILLO 546 TX WICHITA FALLS 548 TX ABILENE 550 TX DALLAS 552 TX LONGVIEW 554 TX WACO 556 TX AUSTIN 558 TX HOUSTON 560 TX BEAUMONT 562 TX CORPUS CHRISTI 564 TX SAN ANTONIO 566 TX BROWNSVILLE 568 TX HEARNE 570 TX SAN ANGELO 961 US MIDWAY/WAKE 836 UT UTAH 660 UT NAVAJO RESERVATION 981 VA ROANOKE 244 VA CULPEPER 246 VA RICHMOND 248 VA LYNCHBURG 250 VA NORFOLK 252 VA HARRISONBURG 927 VA CHARLOTTESVILLE 928 VA EDINBURG 929 VI US VIERGIN ISLANDS 822 VT VERMONT 124 WA SEATTLE 674 WA SPOKANE 676 WI NORTHEASST 350 WI NORTHWEST 352 WI SOUTHWEST 354 WI SOUTHEAST 356 WV CHARLESTON 254 WV CLARKSBURG 256 WV BLUEFIELD 932 WY WYOMING 654 From owner-Big-Internet@munnari.oz.au Tue Feb 9 02:35:59 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21183; Tue, 9 Feb 1993 02:36:07 +1100 (from owner-Big-Internet) Return-Path: Received: from IETF.CNRI.RESTON.VA.US by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21175; Tue, 9 Feb 1993 02:35:59 +1100 (from cclark@CNRI.Reston.VA.US) Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa10357; 8 Feb 93 10:04 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; From: Internet-Drafts@CNRI.Reston.VA.US Cc: big-internet@munnari.oz.au Reply-To: Internet-Drafts@CNRI.Reston.VA.US Subject: ID ACTION:draft-ullmann-rap-00.txt Date: Mon, 08 Feb 93 10:04:28 -0500 Sender: cclark@CNRI.Reston.VA.US Message-Id: <9302081004.aa10357@IETF.CNRI.Reston.VA.US> --NextPart A New Internet Draft is available from the on-line Internet-Drafts directories. Title : RAP: Internet Route Access Protocol Author(s) : R. Ullmann Filename : draft-ullmann-rap-00.txt Pages : 19 RAP is a general protocol for distributing routing information at all levels of the Internet, from private LANs to the widest-flung international carrier networks. It does not distinguish between "interior" and "exterior" routing (except as resticted by specific policy), and therefore is not as restricted nor complex as those protocols that have strict level and area definitions in their models. The protocol encourages the widest possible dissemination of topology information, aggregating it only when limits of thrust, bandwidth, or administrative policy require it. Thus RAP permits aggressive use of resources to optimize routes where desired, without the restrictions inherent in the simplifications of other models. While RAP uses IPv7 addressing internally, it is run over both IPv4 and IPv7 networks, and shares routing information between them. A IPv4 router will only be able to activate and propagate routes that are defined within the local AD, loading the version 4 subset of the address into the local IP forwarding database. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and password "guest". After logging in, Type "cd internet-drafts". "get draft-ullmann-rap-00.txt". Internet-Drafts directories are located at: o East Coast (US) Address: nnsc.nsf.net (128.89.1.178) o West Coast (US) Address: ftp.nisc.sri.com (192.33.33.22) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o Europe Address: nic.nordu.net (192.36.148.17) Internet-Drafts are also available by mail. Send a message to: mail-server@nisc.sri.com. In the body type: "SEND draft-ullmann-rap-00.txt". For questions, please mail to internet-drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the Internet Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mail-server@nisc.sri.com" Content-Type: text/plain SEND draft-ullmann-rap-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ullmann-rap-00.txt"; site="nnsc.nsf.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain --OtherAccess-- --NextPart-- From owner-Big-Internet@munnari.oz.au Tue Feb 9 03:02:52 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21849; Tue, 9 Feb 1993 03:03:04 +1100 (from owner-Big-Internet) Return-Path: Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21841; Tue, 9 Feb 1993 03:02:52 +1100 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <12013>; Mon, 8 Feb 1993 08:01:51 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Mon, 8 Feb 1993 08:01:42 -0800 To: atkinson@itd.nrl.navy.mil (Ran Atkinson) Cc: big-internet@munnari.oz.au, deering@parc.xerox.com Subject: Re: Metro Addressing In-Reply-To: Your message of "Mon, 08 Feb 93 03:21:39 PST." <9302081121.AA29953@itd.nrl.navy.mil> Date: Mon, 8 Feb 1993 08:01:39 PST Sender: Steve Deering From: Steve Deering Message-Id: <93Feb8.080142pst.12171@skylark.parc.xerox.com> > If I might inject a little dissent here, I don't think that metro-based > addressing works at all well for organisations that have significant private > networks. Agreed, at least for the short term. Metro-based addressing is aimed at solving the scaling problem for routing in The Public Internet (in a way that does not require renumbering for sites that switch providers in the same metro, blah, blah, blah...). Private networks do not have the same scaling problem -- they don't have to route to 10^9 sites -- and are welcome to use whatever internal addressing plan they wish. Those hosts within the private net that are to be reachable from the public net will, however, have to have addresses taken from the address spaces of the metro(s) in which the private net attaches to the public net, perhaps in addition to their internal addresses. (The metro numbers of those hosts do not have to bear any relationship to the geographical locations of the hosts themselves, so their location need not be "revealed" by the addresses.) This is analagous to the private phone systems that many large corporations maintain; for example, my office telephone has two phone numbers, one from the 415 area code (so people can phone me from outside of Xerox), and one with a private prefix (so Xeroids anywhere in the corporation can phone me over the facilities leased by Xerox for its private use). Now, since every phone in the corporation has a number from the public numbering space (I assume), the internal routing could, in theory, have been based on the public numbers (the phone switches would just have to know the public prefixes for all Xerox sites, and route internally on those, rather than the private prefixes). If the Internet evolved to a similar state, in which large private nets would naturally connect to the public Internet at each of their sites, then private nets could work fine with metro-based addressing alone (except for those orgaizations who don't want to reveal what cities their externally-reachable hosts are in). > While I recognise the appeal of metro-based addressing, I would > suggest that we also need to permit a significant number of private > networks to continue to exist outside the metro addressing plan. I > think this probably leads to the conclusion that the address space > needs to be partitioned roughly 4 ways (at least): IPv4 addressing, > metro addressing, private network addressing, and multicast > addressing. Agreed. Steve From owner-Big-Internet@munnari.oz.au Tue Feb 9 03:02:53 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21845; Tue, 9 Feb 1993 03:03:01 +1100 (from owner-Big-Internet) Return-Path: Received: from iitmax.acc.iit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21842; Tue, 9 Feb 1993 03:02:53 +1100 (from nelsgar@elof.iit.edu) Received: from elof.iit.edu by iitmax.acc.iit.edu with SMTP id AA13683 (5.64+/IDA/NIU-1.3.1 for big-internet@munnari.oz.au); Mon, 8 Feb 93 10:02:41 -0600 Received: by elof.iit.edu (NX5.67c/NX3.0S) id AA01894; Mon, 8 Feb 93 10:02:39 -0600 Date: Mon, 8 Feb 93 10:02:39 -0600 From: Gary Nelson Message-Id: <9302081602.AA01894@elof.iit.edu> To: deering@parc.xerox.com, jcurran@nic.near.net Subject: Re: Metro Addressing Cc: big-internet@munnari.oz.au This message begins to address the mobility issues. ROAMING will become a fact of life. The addressing scheme wants to be flexible enough to accomodate mobile datacom users who roam - gn From owner-big-internet@munnari.oz.au Tue Feb 9 03:04:21 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21865; Tue, 9 Feb 1993 03:04:27 +1100 (from owner-big-internet) Return-Path: Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20820; Tue, 9 Feb 1993 02:23:53 +1100 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <11847>; Mon, 8 Feb 1993 07:23:19 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Mon, 8 Feb 1993 07:23:08 -0800 To: John Curran Cc: big-internet@munnari.oz.au, deering@parc.xerox.com Subject: Re: Metro Addressing In-Reply-To: Your message of "Mon, 08 Feb 93 05:40:21 PST." <93Feb8.054047pst.11722@alpha.xerox.com> Date: Mon, 8 Feb 1993 07:23:00 PST Sender: Steve Deering From: Steve Deering Message-Id: <93Feb8.072308pst.12171@skylark.parc.xerox.com> > The levels are derived from the topology itself. > Financial considerations decide where a connection is > made into the topology, and hence the address > assignment. > Within a provider, the ability to carry additional > routing information is require when a site > moves, but such information remains internal > to the provider, and only a route for the > address prefix of the provider is exchanged > with others. John, There still isn't enough detail there for me to understand exactly how you assign addresses or how you derive the number of levels from the topology, but if you can talk about "the address prefix of the provider", then your scheme is at least partly "provider-based". It is certainly not "purely topological", because the addressing is based on criteria other than purely topological considerations, such as who owns the wires (or who owns the wires to which a site first connected). Steve From owner-Big-Internet@munnari.oz.au Tue Feb 9 03:05:12 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21888; Tue, 9 Feb 1993 03:05:18 +1100 (from owner-Big-Internet) Return-Path: Received: from thumper.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21885; Tue, 9 Feb 1993 03:05:12 +1100 (from tsuchiya@thumper.bellcore.com) Received: from chiya.bellcore.com by thumper.bellcore.com (4.1/4.7) id for big-internet@munnari.oz.au; Mon, 8 Feb 93 11:05:05 EST Received: by chiya.bellcore.com (4.1/4.7) id for big-internet@munnari.oz.au; Mon, 8 Feb 93 11:05:04 EST Date: Mon, 8 Feb 93 11:05:04 EST From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Message-Id: <9302081605.AA24229@chiya.bellcore.com> To: big-internet@munnari.oz.au Subject: Re: Metro Addressing > Paul wrote: > > > I agree that life [under metro-based addressing] is a little easier for the > > subscriber because of address changes, but really designing for address > > changes is quite easy. Make hosts have a notion of the "provider prefix". > > Spread provider prefix information around in intra-domain routing (the > > routers need to know them anyway). Have a simple configuration protocol > > similar to ES-IS to reassign prefixes to hosts en masse. Of course you must > > also update DNS, but this is not that big a deal....... > > You keep saying that, and I hope you are right, but no one can judge whether > or not it really is "utterly simple" (as you said in another message) until Yes, of course you are right..... > ................You and Ross and others may well > have worked out complete auto-reconfiguration schemes in your heads, but let us > see them written down, and maybe even implemented, before you ask us to accept > that it is trivial, scalable, and correct. After all, Shortcut Routing with I'll concede that I have too easily dismissed auto-configuration as a "done deal" in my messages......though I still think we will find it to be pretty straight-forward.... But, I don't think it is necessary to show that it is easy or hard (I'm convinced that it is doable if nothing else.....). The fact is, we'll need it. I think the probability that subscribers will have to change addresses from time to time, no matter what scheme we end up with, is high. We might find that there wasn't enough hierarchy in our addresses some day, for instance. So, the argument is more like "since we'll have address prefix autoconfiguration anyway, the isn't much point to striving for an address assignment scheme whose main advantage is preventing address prefix changes". > backwards learning seemed pretty straightforward when you first explained it to > us, but it turned out to have a number of subtle failure modes that took months > for you and others to identify, such that you are now (quite properly, in my > opinion) backing away from the backwards learning aspect. Similarly, there may Well, I hate to take up people's time defending myself in a public forum on an unrelated topic, but...... The original shortcut spec discussed almost all of the failure modes for backwards learning, and in fact had explicit mechanisms for dealing with them. I don't recall to what extent I realized it at the time, but the mechanisms were basically forward-learning. Those mechanisms were removed by IPLPDN people because the failure mode wasn't worth the complexity of solving...... Also, part of my backing away from backwards learning has to do with the fact that shortcut has been extended to connection-oriented subnets, where the advantages are quick shortcut learning are less.... > well be subtle weaknesses in your auto-reconfig scheme. Certainly your > dismissal of DNS updates as "not that big a deal" appears to be excessively > cavalier, given that the DNS has not been designed for low-latency updates and > it has not been shown that you can add that capability without significantly > reducing its scalability. It is unfortunate that DNS doesn't have nicer characteristics with regard to controlling caching (for instance, being able to flush the caches, or at least go around them when they are known to be out of date). Pip gets around this by allowing cacheing and on-demand flushing of DNS-learned information in Pip inself (something called the Pip header server, which fronts DNS.....) > > You should also, of course, demand to see a written specification for metro- > based routing before taking my word for it that it would work. But at least > I have not been asserting without proof that it is "utterly simple" and > dismissing alternative proposals as "just smoke". > Alright alright..... I apologize for the hyperbole...... It's not very useful..... PX From owner-Big-Internet@munnari.oz.au Tue Feb 9 03:14:53 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22054; Tue, 9 Feb 1993 03:16:06 +1100 (from owner-Big-Internet) Return-Path: Received: from iitmax.acc.iit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22010; Tue, 9 Feb 1993 03:14:53 +1100 (from nelsgar@elof.iit.edu) Received: from elof.iit.edu by iitmax.acc.iit.edu with SMTP id AA03476 (5.64+/IDA/NIU-1.3.1 for big-internet@munnari.oz.au); Mon, 8 Feb 93 10:14:33 -0600 Received: by elof.iit.edu (NX5.67c/NX3.0S) id AA01982; Mon, 8 Feb 93 10:14:32 -0600 Date: Mon, 8 Feb 93 10:14:32 -0600 From: Gary Nelson Message-Id: <9302081614.AA01982@elof.iit.edu> To: big-internet@munnari.oz.au, grpjl@iastate.edu Subject: Re: The big picture Good work. I agree that "the hierarchy we use in addresses JUST DOESN'T MaTTER." It may matter for simplifying access to the infrastructure of the network - routers, ATM cross connects, edge nodes, or whatever. best wishes gn From owner-big-internet@munnari.oz.au Tue Feb 9 03:41:13 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22632; Tue, 9 Feb 1993 03:41:21 +1100 (from owner-big-internet) Return-Path: Received: from iitmax.acc.iit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20799; Tue, 9 Feb 1993 02:23:04 +1100 (from nelsgar@elof.iit.edu) Received: from elof.iit.edu by iitmax.acc.iit.edu with SMTP id AA24754 (5.64+/IDA/NIU-1.3.1 for big-internet@munnari.oz.au); Mon, 8 Feb 93 09:22:45 -0600 Received: by elof.iit.edu (NX5.67c/NX3.0S) id AA01636; Mon, 8 Feb 93 09:22:38 -0600 Date: Mon, 8 Feb 93 09:22:38 -0600 From: Gary Nelson Message-Id: <9302081522.AA01636@elof.iit.edu> To: deering@parc.xerox.com, hgs@research.att.com Subject: Re: metro addressing Cc: big-internet@munnari.oz.au I'll try this again. I've been kibbitzing this game for a while, and have made an observation that I'll repeat here. Wireless or mobile datacomm will become a reality. The personal communications community is moving away from permanaet location-based addressing to "individual perosbnal ids" that stay with individuals, not geographical locations. Appartently the concept of EIDs is to identify a piece of equipment. What is the effect of having that piece of equipment in your shirt pocket as you fly from Boston to San Francisco? It is common practice in the telecom business to identify the location of, sya a central office, by its coordinates - a sort of flat earth model - this is usually called the VH coordinates for vertical, horizontal. I have read a great deal of info in this kibbitzing process aboit the "telcos" and RBOCs, and so forth. The telco number plans are considered inflexible when compared with the needs of customer mobility. My point in making this observation is simply to point out that what I think I am reading sounds like we are putting a lot of stock in the telco numbering system which identifies telephones at the ends of wires. It is not easy for such a system to make the transition to mobility. If mobility is trivial in your systems, then great - I'll be quiet. If mobility needs further consideration, then now is the tiome to do it. gn From owner-Big-Internet@munnari.oz.au Tue Feb 9 03:57:32 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA23106; Tue, 9 Feb 1993 04:04:25 +1100 (from owner-Big-Internet) Return-Path: Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23030; Tue, 9 Feb 1993 03:57:32 +1100 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <12024>; Mon, 8 Feb 1993 08:56:57 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Mon, 8 Feb 1993 08:56:47 -0800 To: John Curran Cc: big-internet@munnari.oz.au, deering@parc.xerox.com Subject: Re: Metro Addressing In-Reply-To: Your message of "Mon, 08 Feb 93 08:25:20 PST." <93Feb8.082556pst.12031@alpha.xerox.com> Date: Mon, 8 Feb 1993 08:56:44 PST Sender: Steve Deering From: Steve Deering Message-Id: <93Feb8.085647pst.12171@skylark.parc.xerox.com> > So, "topologically-based addresses" (in my use of the expression) can be > rephrased of as provider-based addresses with mandatory renumbering. John, OK, your rephrasing makes sense; I hope you will use the new term from now on, rather than the less informative and less accurate term "topologically- based addressing". Thanks for the clarification. Steve From owner-big-internet@munnari.oz.au Tue Feb 9 07:42:09 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA26770; Tue, 9 Feb 1993 07:44:17 +1100 (from owner-big-internet) Return-Path: Message-Id: <9302082044.26770@munnari.oz.au> Received: from nic.near.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22258; Tue, 9 Feb 1993 03:25:36 +1100 (from jcurran@nic.near.net) To: Steve Deering Cc: big-internet@munnari.oz.au Subject: Re: Metro Addressing In-Reply-To: Your message of Mon, 08 Feb 93 07:23:00 -0800. <93Feb8.072308pst.12171@skylark.parc.xerox.com> Date: Mon, 08 Feb 93 11:25:20 -0500 From: John Curran -------- ] From: Steve Deering ] Subject: Re: Metro Addressing ] Date: Mon, 8 Feb 1993 07:23:00 PST ] ] There still isn't enough detail there for me to understand exactly how ] you assign addresses or how you derive the number of levels from the ] topology, but if you can talk about "the address prefix of the provider", ] then your scheme is at least partly "provider-based". It is certainly not ] "purely topological", because the addressing is based on criteria other ] than purely topological considerations, such as who owns the wires (or who ] owns the wires to which a site first connected). Apologies for my terse description. Let's try again with more content: When I refer to "topologically-based addreses", I am referring to addresses which are assigned in conjuction with the current network topology; these would generally by derived from the current provider's prefix. In a purely topology-based system, each network would have to be hierarchical in nature with one level per hierarchy. These addresses would be maintained as topologically-significant by mandating their change when the network attachment point changed. In reality, many of the changes in topology can be "hidden" from the next layer up in the hierarchy by carrying additional routing information internally. Such additional routing information does not have to be propogated. For example, if a site reorganized its internal network topology, this can be hidden from the provider if the site carries the additional routing information internally. Likewise, a site that moves across the state and connects into a provider at a different location could renumber, but would probably be handled by the provider carrying a site-specific prefix route which directed the traffic to the new attachment point. Such a change would not require any additional routing information to be carried by the providers transit networks. So, "topologically-based addresses" (in my use of the expression) can be rephrased of as provider-based addresses with mandatory renumbering. I do not think that anyone's proposing this as a solution, except in conjuction with dynamic renumbering or EID directory usage. Yes, topologically-based addresses only make sense at the fringes of the network; once you get closer in, the topology is indeed a mesh and no hierarchy can be presumed. /John From owner-Big-Internet@munnari.oz.au Tue Feb 9 10:49:35 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA01678; Tue, 9 Feb 1993 10:50:53 +1100 (from owner-Big-Internet) Return-Path: Received: from interlock.ans.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01596; Tue, 9 Feb 1993 10:49:35 +1100 (from dennis@ans.net) Received: by interlock.ans.net id AA25765 (InterLock SMTP Gateway 1.1 for big-internet@munnari.oz.au); Mon, 8 Feb 1993 18:48:32 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 8 Feb 1993 18:48:32 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 8 Feb 1993 18:48:32 -0500 From: Dennis Ferguson Message-Id: <199302082348.AA32031@foo.ans.net> To: Steve Deering Cc: yakov@watson.ibm.com, big-internet@munnari.oz.au Subject: Re: EGP/IGP split (was Metro Addressing Summary) In-Reply-To: (Your message of Sun, 07 Feb 93 23:25:27 GMT.) <93Feb7.152536pst.12171@skylark.parc.xerox.com.ans-relay> Date: Mon, 08 Feb 93 18:48:36 -0500 > Presumably, whatever policy rules are installed in any particular > domain-boundary router could simply be added to the link-state database > record for that router, and disseminated in the normal LS way. Then any > router operating on that database could take those into account when > computing routes. I don't know how well that approach would scale, but it > at least sounds do-able. [...] >> (c) support for information aggregation when the overall >> inter-domain topology can't be constrained to pure >> "core" model (ala EGP2). > > The inter-domain routing is performed over a topology consisting of "clouds", > where each domain is a cloud, represented as a single node in the inter-domain > LS database (and thus aggregated). The topology of clouds can be arbitrary, > i.e., it is not limited to being a tree or having a single "core". For > greater aggregation, domains can be clustered into larger clouds (e.g., all > domains in a single metro area, or all domains served by a single provider), > and higher-level LS routing can be performed among the larger clouds, again > interconnected in an arbitrary topology. And so on. Note that having policy rules in your link-state database means that domains with distinct policies must remain distinct in your database, i.e. you can only form larger clouds of topologically-connected entities with like policies. The problem with metro-based addressing in this regard is that, on the current network, even if the metro is fully interconnected internally the customers of different providers will have their routing determined using different policies. Since the only policy routing we do today is route filtering at provider boundaries, providers currently define policies. If you can't aggregate across policy boundaries you can't aggregate the metro addresses across providers. If you want to support metro addressing I think that you'll also need to resolve the issue of supporting divergent provider policies within the metro. Demanding that they just go away may not work as well as demanding that the metro be interconnected, since the existance of the former is often dictated by economics which are way beyond the control of both routing protocol designers and topology engineers. Dennis From owner-Big-Internet@munnari.oz.au Tue Feb 9 11:12:50 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA02328; Tue, 9 Feb 1993 11:16:48 +1100 (from owner-Big-Internet) Return-Path: Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02258; Tue, 9 Feb 1993 11:12:50 +1100 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <12249>; Mon, 8 Feb 1993 16:12:03 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Mon, 8 Feb 1993 16:11:59 -0800 To: Dennis Ferguson Cc: big-internet@munnari.oz.au, deering@parc.xerox.com Subject: Re: EGP/IGP split (was Metro Addressing Summary) In-Reply-To: Your message of "Mon, 08 Feb 93 11:36:43 PST." <199302081936.AA89012@foo.ans.net> Date: Mon, 8 Feb 1993 16:11:42 PST Sender: Steve Deering From: Steve Deering Message-Id: <93Feb8.161159pst.12171@skylark.parc.xerox.com> > Sorry. The clarification took a lot more text than the original > opague assertions. Dennis, Thanks for taking the time to compose that explanation. It did indeed clarify for me what you were trying to say, and I agree with everything you wrote. My faith in you is restored. :-) Steve From owner-big-internet@munnari.oz.au Tue Feb 9 17:22:04 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA13098; Tue, 9 Feb 1993 17:25:39 +1100 (from owner-big-internet) Return-Path: Received: from Sun.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28578; Tue, 9 Feb 1993 09:16:00 +1100 (from Tom.Kessler@Eng.Sun.COM) Received: from Eng.Sun.COM (zigzag-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AB19179; Mon, 8 Feb 93 14:15:10 PST Received: from bigriver.Eng.Sun.COM (bigriver-248) by Eng.Sun.COM (4.1/SMI-4.1) id AA06794; Mon, 8 Feb 93 14:18:21 PST Received: from hacketorium.Eng.Sun.COM by bigriver.Eng.Sun.COM (4.1/SMI-4.1) id AA26557; Mon, 8 Feb 93 14:14:53 PST Date: Mon, 8 Feb 93 14:14:53 PST From: Tom.Kessler@Eng.Sun.COM (Tom Kessler) Message-Id: <9302082214.AA26557@bigriver.Eng.Sun.COM> Received: by hacketorium.Eng.Sun.COM (5.0/SMI-SVR4) id AA17270; Mon, 8 Feb 93 14:15:49 PST To: atkinson@itd.nrl.navy.mil (Ran Atkinson) Cc: big-internet@munnari.oz.au In-Reply-To: <9302081121.AA29953@itd.nrl.navy.mil> Subject: Re: Metro Addressing Content-Length: 740 I think that for metro addressing to work well for large private internets that are connected in more than metro you need to treat all the hosts as multi-homed in terms of metro. You might think about having multiple logical network interfaces and you would choose which "interface" to use based on what gethostbyname() told you the destination was. When you look up the name from the outside you might see multiple SIP addresses for the host and you'd choose the one in the "nearest/most convenient" metro. Another possibility would be to assign a "virtual metro" id to these largish sort of networks. I would think that some heuristic like having more than 4 internet attachment points and more than 500 networks/subnets would work. From owner-big-internet@munnari.oz.au Tue Feb 9 20:45:21 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA18373; Tue, 9 Feb 1993 20:46:15 +1100 (from owner-big-internet) Return-Path: Received: from tengwar.itd.nrl.navy.mil by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03448; Tue, 9 Feb 1993 11:56:44 +1100 (from atkinson@tengwar.itd.nrl.navy.mil) Received: by tengwar.itd.nrl.navy.mil (16.8/16.2) id AA00652; Mon, 8 Feb 93 22:00:28 -0500 From: atkinson@tengwar.itd.nrl.navy.mil (Ran Atkinson) Message-Id: <9302082200.ZM650@tengwar.itd.nrl.navy.mil> Date: Mon, 8 Feb 1993 22:00:28 -0500 In-Reply-To: Tom.Kessler@Eng.Sun.COM (Tom Kessler) "Re: Metro Addressing" (Feb 8, 15:54) References: <9302082354.AA28658@bigriver.Eng.Sun.COM> Organization: Naval Research Laboratory X-Mailer: Z-Mail (2.1.0 10/27/92) To: big-internet@munnari.oz.au Subject: Re: Metro Addressing NRL are connected directly to SURAnet, FIXeast, NASA Science Internet, MILnet, and TWBnet right now. It is important that the operator of the private network can have his gateway routers advertise their private net connectivity in whatever manner suits the operator's needs. For example, NRL current lies to the outside world about its connectivity to MILnet and deprecates that gateway because it is MUCH lower bandwidth than say our SURAnet or NSI connectivity. That kind of administrative flexibility needs to be kept in all proposed new addressing schemes. Perhaps some obvious principles are worth mentioning (I don't think these are controversial or reflect any particular wisdom on my part) : 1) new addressing/routing schemes must not preclude current practices or be less flexible than current practices. 2) Private/public network gateways must not be required to perform address translations or modifications on traffic moving through those gateways. (at least not for metro addressing reasons, an IPv4--IPvN gateway a la IPAE might be acceptable for transitional purposes only). 3) Minimise the mucking around inside packets that is required of routers. The more mucking that has to be done to packets being routed, the slower the routing will be. I already have ATM networks in experimental use. If the trade press is to be believed, NASA/DOE will have ATM operational in a few months. In fast networks, I want my routers to be doing routing not dinking with gratuitous bit twiddling. 4) While metro addressing makes sense for the public (commercial ?) parts of the Internet, use of metro addressing must not be forced on others who don't choose to use it in their own networks. Ran atkinson@itd.nrl.navy.mil From owner-big-internet@munnari.oz.au Tue Feb 9 23:46:03 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22732; Tue, 9 Feb 1993 23:46:58 +1100 (from owner-big-internet) Return-Path: Received: from tengwar.itd.nrl.navy.mil by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03448; Tue, 9 Feb 1993 11:56:44 +1100 (from atkinson@tengwar.itd.nrl.navy.mil) Received: by tengwar.itd.nrl.navy.mil (16.8/16.2) id AA00652; Mon, 8 Feb 93 22:00:28 -0500 From: atkinson@tengwar.itd.nrl.navy.mil (Ran Atkinson) Message-Id: <9302082200.ZM650@tengwar.itd.nrl.navy.mil> Date: Mon, 8 Feb 1993 22:00:28 -0500 In-Reply-To: Tom.Kessler@Eng.Sun.COM (Tom Kessler) "Re: Metro Addressing" (Feb 8, 15:54) References: <9302082354.AA28658@bigriver.Eng.Sun.COM> Organization: Naval Research Laboratory X-Mailer: Z-Mail (2.1.0 10/27/92) To: big-internet@munnari.oz.au Subject: Re: Metro Addressing NRL are connected directly to SURAnet, FIXeast, NASA Science Internet, MILnet, and TWBnet right now. It is important that the operator of the private network can have his gateway routers advertise their private net connectivity in whatever manner suits the operator's needs. For example, NRL current lies to the outside world about its connectivity to MILnet and deprecates that gateway because it is MUCH lower bandwidth than say our SURAnet or NSI connectivity. That kind of administrative flexibility needs to be kept in all proposed new addressing schemes. Perhaps some obvious principles are worth mentioning (I don't think these are controversial or reflect any particular wisdom on my part) : 1) new addressing/routing schemes must not preclude current practices or be less flexible than current practices. 2) Private/public network gateways must not be required to perform address translations or modifications on traffic moving through those gateways. (at least not for metro addressing reasons, an IPv4--IPvN gateway a la IPAE might be acceptable for transitional purposes only). 3) Minimise the mucking around inside packets that is required of routers. The more mucking that has to be done to packets being routed, the slower the routing will be. I already have ATM networks in experimental use. If the trade press is to be believed, NASA/DOE will have ATM operational in a few months. In fast networks, I want my routers to be doing routing not dinking with gratuitous bit twiddling. 4) While metro addressing makes sense for the public (commercial ?) parts of the Internet, use of metro addressing must not be forced on others who don't choose to use it in their own networks. Ran atkinson@itd.nrl.navy.mil From owner-Big-Internet@munnari.oz.au Wed Feb 10 05:02:19 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22768; Tue, 9 Feb 1993 03:44:46 +1100 (from owner-Big-Internet) Return-Path: Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22757; Tue, 9 Feb 1993 03:44:06 +1100 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <12019>; Mon, 8 Feb 1993 08:43:34 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Mon, 8 Feb 1993 08:43:31 -0800 To: big-internet@munnari.oz.au Subject: Re: metro addressing Date: Mon, 8 Feb 1993 08:43:16 PST Sender: Steve Deering From: Steve Deering Message-Id: <93Feb8.084331pst.12171@skylark.parc.xerox.com> > If mobility is trivial in your systems, then great - I'll be quiet. If > mobility needs further consideration, then now is the time to do it. Mobility concerns are (or, at least can be) independent of the scalable routing concerns, and there are a number of solutions currently on the table in the Mobile IP Working Group. Whether sending to a stationary or a mobile device, the internet layer has to deliver packets to a particular point in the topology, i.e., whatever the "current location" of the device is. Assuming we can't do routing to all of the devices in the world using a flat address space, there will sometimes be a need for a mapping operation from some sort of device or person or process identifier to a current location address. That identifier may itself be an address (a "home location") or some other kind of name (such as an "EID"). When the phone companies introduce personal, portable, owned-for-life phone numbers, do you think they will route on them? Steve From owner-big-internet@munnari.oz.au Wed Feb 10 06:29:47 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA06556; Wed, 10 Feb 1993 06:30:22 +1100 (from owner-big-internet) Return-Path: Received: from thumper.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28410; Wed, 10 Feb 1993 02:07:30 +1100 (from tsuchiya@thumper.bellcore.com) Received: from chiya.bellcore.com by thumper.bellcore.com (4.1/4.7) id for big-internet@munnari.oz.au; Tue, 9 Feb 93 10:05:54 EST Received: by chiya.bellcore.com (4.1/4.7) id for jcurran@nic.near.net; Tue, 9 Feb 93 10:05:53 EST Date: Tue, 9 Feb 93 10:05:53 EST From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Message-Id: <9302091505.AA26212@chiya.bellcore.com> To: deering@parc.xerox.com, jcurran@nic.near.net Subject: Re: Metro Addressing Cc: big-internet@munnari.oz.au > > > So, "topologically-based addresses" (in my use of the expression) can be > > rephrased of as provider-based addresses with mandatory renumbering. > > John, > > OK, your rephrasing makes sense; I hope you will use the new term from now > on, rather than the less informative and less accurate term "topologically- > based addressing". Thanks for the clarification. > Does this mean that the term "metro-based addressing" will be changed to "metro-based addresses with mandatory interconnection"? Seriously, though, it seems to me that, over time, we will periodically be renumbering the internet, to reflect evolution of topology, routing practices, and so on. My strong speculation is that renumbering will eventually be mandatory under any scheme..... PX From owner-big-internet@munnari.oz.au Wed Feb 10 07:24:17 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA07830; Wed, 10 Feb 1993 07:25:09 +1100 (from owner-big-internet) Return-Path: Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01168; Wed, 10 Feb 1993 03:26:41 +1100 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <11893>; Tue, 9 Feb 1993 08:25:40 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Tue, 9 Feb 1993 08:25:27 -0800 To: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Cc: big-internet@munnari.oz.au, deering@parc.xerox.com Subject: Re: Metro Addressing In-Reply-To: Your message of "Tue, 09 Feb 93 07:05:53 PST." <9302091505.AA26212@chiya.bellcore.com> Date: Tue, 9 Feb 1993 08:25:15 PST Sender: Steve Deering From: Steve Deering Message-Id: <93Feb9.082527pst.12171@skylark.parc.xerox.com> > > > So, "topologically-based addresses" (in my use of the expression) can > > > be rephrased of as provider-based addresses with mandatory renumbering. > > > > OK, your rephrasing makes sense; I hope you will use the new term > > from now on, rather than the less informative and less accurate term > > "topologically-based addressing". > > Does this mean that the term "metro-based addressing" will be changed > to "metro-based addresses with mandatory interconnection"? Actually, I think the scheme that John has described is best called simply "provider-based addressing". I.e., the "mandatory renumbering" is implicit. Schemes which allow a site to keep its provider-based prefix when it moves to a different provider, or its metro-based prefix when it moves to a different metro, by paying all or some of the providers in the world to carry special-case routes for the site, would then warrant a qualifying clause, such as "provider/metro-based addressing with address portability". Similarly, "mandatory interconnection" is implicit. It is a not an attribute that distinguishes provider-based addressing from metro-based addressing, but rather is a property of all hierarchical routing schemes. With metro-based addressing, those objects identified by the same metro prefix must be internally-connected; with provider-based addressing, those objects identified by the same provider prefix must be internally-connected; with subscriber-based addressing (i.e., IPv4 addressing), those objects identified by the same subscriber prefix must be internally connected. What I am objecting to is the use of the term "topologically-based" as a property that distinguishes one scheme from another. All of the schemes under discussion are equally topologically-based. They have to be, for hierarchical routing to work. Where they differ is in the criteria used to partition the topology hierarchically for address-assignment purposes. Steve From owner-big-internet@munnari.oz.au Wed Feb 10 11:37:06 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15296; Wed, 10 Feb 1993 11:37:14 +1100 (from owner-big-internet) Return-Path: Received: from thumper.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04553; Wed, 10 Feb 1993 05:25:57 +1100 (from tsuchiya@thumper.bellcore.com) Received: from chiya.bellcore.com by thumper.bellcore.com (4.1/4.7) id for big-internet@munnari.oz.au; Tue, 9 Feb 93 13:25:38 EST Received: by chiya.bellcore.com (4.1/4.7) id for tsuchiya@thumper.bellcore.com; Tue, 9 Feb 93 13:25:36 EST Date: Tue, 9 Feb 93 13:25:36 EST From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Message-Id: <9302091825.AA26618@chiya.bellcore.com> To: deering@parc.xerox.com, tsuchiya@thumper.bellcore.com Subject: Re: Metro Addressing Cc: big-internet@munnari.oz.au > > What I am objecting to is the use of the term "topologically-based" as a > property that distinguishes one scheme from another. All of the schemes > under discussion are equally topologically-based. They have to be, for > hierarchical routing to work. Where they differ is in the criteria used > to partition the topology hierarchically for address-assignment purposes. > Yes, I agree. PX From owner-big-internet@munnari.oz.au Wed Feb 10 19:29:02 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA29323; Wed, 10 Feb 1993 19:29:15 +1100 (from owner-big-internet) Return-Path: Received: from p.lanl.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14573; Wed, 10 Feb 1993 11:16:22 +1100 (from peter@goshawk.lanl.gov) Received: from goshawk.lanl.gov by p.lanl.gov (5.65/1.14) id AA18481; Tue, 9 Feb 93 17:15:46 -0700 Received: from localhost.lanl.gov by goshawk.lanl.gov (4.1/5.17) id AA11720; Tue, 9 Feb 93 17:15:44 MST Message-Id: <9302100015.AA11720@goshawk.lanl.gov> To: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Cc: big-internet@munnari.oz.au Subject: Re: Metro Addressing In-Reply-To: Your message of Tue, 09 Feb 93 10:05:53 -0500. <9302091505.AA26212@chiya.bellcore.com> Date: Tue, 09 Feb 93 17:15:43 MST From: peter@goshawk.lanl.gov Paul, In fact, there needs to be a more serious dialogue on renumbering the IPv4 space! Why wait for a new protocol when we might test out ideas on the current Internet? The results could then be factored into a new protocol. (or be used to vindicate features in existing protocols :-) ). cheers, peter From owner-Big-Internet@munnari.oz.au Wed Feb 10 20:23:25 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA00986; Wed, 10 Feb 1993 20:24:02 +1100 (from owner-Big-Internet) Return-Path: Message-Id: <9302100924.986@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00969; Wed, 10 Feb 1993 20:23:25 +1100 (from J.Crowcroft@cs.ucl.ac.uk) Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 10 Feb 1993 09:22:58 +0000 To: big-internet@munnari.oz.au Subject: address rental... Date: Wed, 10 Feb 93 09:22:52 +0000 From: Jon Crowcroft just read the really excellent internet draft on CIDR assignment and aggreghation obvsoleteing 1338.. however, a nightware scenario presented itself where instead of generous souls returning large chunks of underutilissed strung-out IP address space, they rent it back (worse still, they could rent it to newcomers, and even extra-hop route it for newcomers, sort of badly warped version of two-tier) more power to CIDR please jon From owner-big-internet@munnari.oz.au Thu Feb 11 01:09:32 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA08407; Thu, 11 Feb 1993 01:10:05 +1100 (from owner-big-internet) Return-Path: Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24713; Wed, 10 Feb 1993 16:49:44 +1100 (from tli@cisco.com) Received: by lager.cisco.com; Tue, 9 Feb 1993 21:46:24 -0800 Date: Tue, 9 Feb 1993 21:46:24 -0800 From: Tony Li Message-Id: <199302100546.AA14787@lager.cisco.com> To: deering@parc.xerox.com, tsuchiya@thumper.bellcore.com Cc: big-internet@munnari.oz.au Subject: addressing Where they differ is in the criteria used to partition the topology hierarchically for address-assignment purposes. And this is a critical problem which you CANNOT architect at a global scale and dictate global usage which is appropriate in all situations. The addressing architecture must allow any level in the hierarchy to become flat (ala metro areas) and also must allow other elements at the same level to remain purely hierarchical. In other words, addressing MUST become a wholly local decision. Tony From owner-Big-Internet@munnari.oz.au Thu Feb 11 03:11:45 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA11312; Thu, 11 Feb 1993 03:12:09 +1100 (from owner-Big-Internet) Return-Path: Message-Id: <9302101612.11312@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11301; Thu, 11 Feb 1993 03:11:45 +1100 (from J.Crowcroft@cs.ucl.ac.uk) Received: from kant.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 10 Feb 1993 16:10:48 +0000 To: big-internet@munnari.oz.au Subject: Re: revised criteria list - cost of renumbering? In-Reply-To: Your message of "Tue, 03 Nov 92 13:04:38 PST." <9211032104.AA26996@aland.bbn.com> Date: Wed, 10 Feb 93 16:10:46 +0000 From: Jon Crowcroft of course, top of the list should be cost: since we are haeding largely for a cost revcovery network, the cost of transition should be estimated... if renumbering the inetent so CIDR buys us say x years, can be costed, we have a cost per year per architecture - something a new system must address too... i propose a CERT style collecton of experts are funded to write all the administrivia for ever version of every host o/s in existience on the Internet (not too hard to find out)< so that every site can be a) renumbered or b) charged for incurring routeing overhead to everyone else i estimate a cert/ripe style team providing 24*7 coverage for a year might cost around 5 million dollars - modest... anyone care to estimate the cost of replaceing same o/s IP implemwentations with CLNP, PIP, SIP or a.n.other? - clue: what did DARPA pay Berkeley for IPv4 for BSD? comments? jon From owner-big-internet@munnari.oz.au Thu Feb 11 15:00:24 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA29839; Thu, 11 Feb 1993 15:01:22 +1100 (from owner-big-internet) Return-Path: Received: from interlock.ans.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25702; Tue, 9 Feb 1993 06:37:51 +1100 (from dennis@ans.net) Received: by interlock.ans.net id AA07172 (InterLock SMTP Gateway 1.1 for big-internet@munnari.oz.au); Mon, 8 Feb 1993 14:36:39 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 8 Feb 1993 14:36:39 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 8 Feb 1993 14:36:39 -0500 From: Dennis Ferguson Message-Id: <199302081936.AA89012@foo.ans.net> To: Steve Deering Cc: big-internet@munnari.oz.au Subject: Re: EGP/IGP split (was Metro Addressing Summary) In-Reply-To: (Your message of Sat, 06 Feb 93 10:46:11 PST.) <93Feb6.104618pst.12171@skylark.parc.xerox.com> Date: Mon, 08 Feb 93 14:36:43 -0500 Steve, You are right, I am guilty of muddy writing. Let me see if I can extract myself gracefully. I have no argument at all with the fact that you can clump together large chunks of real topology into single topological elements in a higher-level topology, and use link state routing to compute routes at the higher level. The address information associated with the lower level chunks of topology can indeed be aggregated when presented to the higher level, and hence the address information associated with very high levels of the hierarchy may be well aggregated when propagated down to the lower levels. The "aggregation within an LS-routed topology" comment wasn't meant to deny this at all, but was rather just a statement of the fact that once you'd carefully configured what the elements of a particular topology were going to be (real links and routers, or aggregated clouds of something) no aggregation was possible at that level of the hierarchy. LS routing provides you with exactly as much detail about the most distant part of the topology it is computing routes for as it does about your immediate neighbours at that level even though, in some sense, the details about things distant matter less to you when your job is to compute an address-and-mask and associated next hop for your forwarding table. You can aggregate when moving information up and down through a hierarchical set of LS-routed topologies, but you can't aggregate within any particular level of the topology. You can aggregate the topology, but you can't aggregate within the link-state routing running over your (possibly aggregated) topology. So I certainly agree you could do this. It would probably be possible to build a hierarchical set of link state topologies with the highest level spanning the entire Internet. It just isn't clear to me that area routing in either ISIS or OSPF is a good example of the first two layers of this (i.e. I have no doubt that this could be done, I'm just not sure how much this has to do with anything which is done on the current network). > A different, equally-valid, view is that level-1 routing computes routes > across a topology of interconnected subnetworks, whereas level-2 routing > computes routes across a topology of interconnected clouds (level-1 areas). > ISIS requires that level-2 neighbors be joined by single subnetworks, rather > than multi-hop clouds, but those subnetworks may be viewed simply as > degenerate clouds. OSPF adopts the more general model, with its support for > "virtual links" (or whatever they are called) between level-2 routers, > across level-1 areas. In this view, level-1 clouds do not just appear on > the fringes of the level-2 topology, but rather level-1 clouds are the *only* > kind of links present in the level-2 topology. (Yes, I know that this view > is not elucidated in the ISIS or OSPF specs -- in particular, they do not > label those subnetworks that serve only to connect level 2 routers as > distinct areas, but being a degenerate case, they do not need their own area > labels. I also note that level 2 routers must also participate in level 1 > routing in each of the level-1 areas to which they are directly attached.) You can view things this way, and no doubt could do things this way, but there are a lot of warts when you look at the details of the actual protocols. The links could be level 1 areas, but they certainly couldn't be ISIS level 1 areas (nor one of the stub varieties of OSPF areas) since ISIS doesn't propagate external routing information into level 1. The only way an ISIS level 1 area could carry transit traffic between level 2 routers is if you encapsulated it, and this likely wouldn't scale to a lot of levels. This would suggest that, with ISIS certainly, level 1 areas are explicitly *not* designed to be links between level 2 routers. In addition, while OSPF allows virtual links between level 2 routers through level 1 areas (suggesting the level 1 areas are links at level 2), ISIS supports the exact opposite and permits virtual links between level 1 routers through level 2 areas to heal level 1 partitions (suggesting the level 2 area can also be a link at level 1), so the hierarchical relationship between level 1 and level 2 areas is not particularly well defined by who uses who as links at their level of the topology. OSPF doesn't do the latter, but it certainly could if it didn't aggregate level 1 address information before advertising it to level 2 (ISIS does this by encapsulation, which OSPF sensibly avoids). Of course I suspect that if you don't aggregate address information into level 2, OSPF will heal partitioned level 1 areas anyway even without an actual virtual link(?). And note that OSPF allows level 1 routers to be AS border routers, i.e. the routers which potentially are your level 3 routers need not participate in the level 2 topology. This also suggests that the relationship between OSPF level 1 and level 2 areas is not strictly hierarchical. > I usually find your messages to be models of clarity and illumination, > but this time I am completely in the dark as to what special semantics > you attach the notion of "distance-vector". Perhaps this is the kind > of understanding that can only be conveyed by drawing pictures on a > whiteboard, but I'll press on in prose form, in the hope that I find the > light switch. [...] > I guess the difference is in whether "moving routes between each instance of > the protocol" is done as result of just running one level higher of OSPF > routing, vs. doing vector routing or static routing or something else between > each OSPF instance. I still don't see that the inter-OSPF routing has to > be vector-based. I was looking at this differently when I made the comment. If level 1 areas are to carry level 2 transit traffic (i.e. be links in the level 2 topology) they need to know level 2 routes. In the current network we don't do encapsulation or route setup for this, so the level 1 areas need this information explicitly. The issue is, how could level 2 routing information be provided to the level 1 areas? It seems to me there are two ways to do this. One is that the level 2 routers could provide level 2 routing information to the level 1 routers by originating a copy of the level 2 link state database into the level 1 area. With this the level 1 routers could do an SPF computation over the level 1 topolgy to find routes to the level 2 exit routers, and then run the SPF over the level 2 topology to find the appropriate level 2 exit router to reach the desination. The level 1 routers would not participate in level 2 routing, but would determine routes from a knowlege of the level 2 topology. The other way to do this is for the level 2 routers to originate external routing information into the level 1 area as address-and-mask vectors with an associated metric. The level 1 routers would still find routes to the level 2 exit routers by running the SPF computation over the level 1 topology, but would select the appropriate level 2 exit router by selecting the router which had originated the minimum cost vector. It seems to me that the routing resulting from either of these methods would be equivalent, the only difference is how extra-area routing information is presented to the area. I actually don't think the method by which the higher level area determines routing within it's own level is particularly relevant, the question is how the information is propagated between areas. I would call the first method above "link-state" inter-area routing, and the second "distance-vector". I don't think this is attaching unconventional semantics to either "link-state" or "distance-vector". The fact is that OSPF uses the second method for propagating inter-area routing information. It seems to me that calling OSPF inter-area routing "distance-vector" is quite accurate. I think most of the above is factual. In not-so-factual terms, I think the misunderstanding I had when you asserted that OSPF was a two-level hierarchical LS-routed topology is that in my mind this conjures up a picture of the first method above, where all routing information is propagated through the hierarchy in the form of a multi-level link state topology and all routing is computed from this. OSPF inter-area routing doesn't work this way. I grant, however, that if the routes at both level 1 and level 2 are computed by a LS computation then this could be called a hierarchical LS-routed topology even if the results of the level 2 computation are only presented to level 1 as distance-vectors (if at all). In addition, while I have no doubt that a link state routing protocol which used level one topologies as the links to move traffic between level 2 routers could be developed, I think you're on thinner ice to assert that ISIS, or even OSPF, is such a protocol. I think it is fairly clear from the protocol descriptions that they both strongly assume that you will be building your level 2 topology, as well as your level 1, from real routers with physical subnets between them. ISIS level 1 areas are explicitly precluded from ever carrying transit traffic between level 2 routers, while OSPF does this only as a hand-configured exception rather than the normal way of doing things. It doesn't have to be this way, it just is this way with the protocols we currently have. Sorry. The clarification took a lot more text than the original opague assertions. Dennis Ferguson From owner-big-internet@munnari.oz.au Thu Feb 11 19:08:01 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AB07443; Thu, 11 Feb 1993 19:08:05 +1100 (from owner-big-internet) Return-Path: Received: from babyoil.ftp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14317; Thu, 11 Feb 1993 05:15:22 +1100 (from kasten@ftp.com) Received: by ftp.com id AA11458; Wed, 10 Feb 93 13:14:50 -0500 Date: Wed, 10 Feb 93 13:14:50 -0500 Message-Id: <9302101814.AA11458@ftp.com> To: tli@cisco.com Subject: Re: addressing From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: deering@parc.xerox.com, tsuchiya@thumper.bellcore.com, big-internet@munnari.oz.au > Where they differ is in the criteria used to partition the topology > hierarchically for address-assignment purposes. > > And this is a critical problem which you CANNOT architect at a global > scale and dictate global usage which is appropriate in all situations. > > The addressing architecture must allow any level in the hierarchy to > become flat (ala metro areas) and also must allow other elements at > the same level to remain purely hierarchical. > > In other words, addressing MUST become a wholly local decision. Tony, Would I be correct in extending your statement to say that we are really only able to define how to represent hierarchies in the addresses at this time, and not what those hierarchies actually are? -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From owner-big-internet@munnari.oz.au Thu Feb 11 19:46:43 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA08688; Thu, 11 Feb 1993 19:46:51 +1100 (from owner-big-internet) Return-Path: Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AB14572; Thu, 11 Feb 1993 05:26:17 +1100 (from tli@cisco.com) Received: by lager.cisco.com; Wed, 10 Feb 1993 10:25:47 -0800 Date: Wed, 10 Feb 1993 10:25:47 -0800 From: Tony Li Message-Id: <199302101825.AA11772@lager.cisco.com> To: kasten@ftp.com Cc: deering@parc.xerox.com, tsuchiya@thumper.bellcore.com, big-internet@munnari.oz.au In-Reply-To: (Frank Kastenholz's message of Wed, 10 Feb 93 13:14:50 -0500 <9302101814.AA11458@ftp.com> Subject: addressing > And this is a critical problem which you CANNOT architect at a global > scale and dictate global usage which is appropriate in all situations. > > The addressing architecture must allow any level in the hierarchy to > become flat (ala metro areas) and also must allow other elements at > the same level to remain purely hierarchical. > > In other words, addressing MUST become a wholly local decision. Would I be correct in extending your statement to say that we are really only able to define how to represent hierarchies in the addresses at this time, and not what those hierarchies actually are? Yup. Tony From owner-big-internet@munnari.oz.au Thu Feb 11 20:10:29 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA09286; Thu, 11 Feb 1993 20:10:35 +1100 (from owner-big-internet) Return-Path: Received: from thumper.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14647; Thu, 11 Feb 1993 05:29:54 +1100 (from tsuchiya@thumper.bellcore.com) Received: from chiya.bellcore.com by thumper.bellcore.com (4.1/4.7) id for big-internet@munnari.oz.au; Wed, 10 Feb 93 13:29:18 EST Received: by chiya.bellcore.com (4.1/4.7) id for tsuchiya@thumper.bellcore.com; Wed, 10 Feb 93 13:29:16 EST Date: Wed, 10 Feb 93 13:29:16 EST From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Message-Id: <9302101829.AA28293@chiya.bellcore.com> To: kasten@ftp.com, tli@cisco.com Subject: Re: addressing Cc: big-internet@munnari.oz.au, deering@parc.xerox.com, tsuchiya@thumper.bellcore.com > > Would I be correct in extending your statement to say that we are > really only able to define how to represent hierarchies in the > addresses at this time, and not what those hierarchies actually are? > > Yup. > > Tony But, we have to at least nail down the top of the hierarchy before we start significant deployment...... I have interpreted the whole geographic vs. provider to be an argument about what the top of the hierarchy should look like..... PX From owner-big-internet@munnari.oz.au Thu Feb 11 21:32:42 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA11490; Thu, 11 Feb 1993 21:32:48 +1100 (from owner-big-internet) Return-Path: Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15107; Thu, 11 Feb 1993 05:49:19 +1100 (from tli@cisco.com) Received: by lager.cisco.com; Wed, 10 Feb 1993 10:47:05 -0800 Date: Wed, 10 Feb 1993 10:47:05 -0800 From: Tony Li Message-Id: <199302101847.AA13137@lager.cisco.com> To: tsuchiya@thumper.bellcore.com Cc: kasten@ftp.com, tli@cisco.com, big-internet@munnari.oz.au, deering@parc.xerox.com, tsuchiya@thumper.bellcore.com In-Reply-To: Paul Tsuchiya's message of Wed, 10 Feb 93 13:29:16 EST <9302101829.AA28293@chiya.bellcore.com> Subject: addressing But, we have to at least nail down the top of the hierarchy before we start significant deployment...... I have interpreted the whole geographic vs. provider to be an argument about what the top of the hierarchy should look like..... I strongly disagree. The top of the hierarchy (above the metro area) looks the same in either case. The only thing that would have to be nailed down at this point is the top level. E.g.: I assume byte level granularity in addresses (if your particular protocol does otherwise, please generalize). The first byte will indicate the continent: 0 Europe 1 Asia 2 Africa 3 Antartica/Australia 4 South America 5 North America Remaining values of the first byte can be used for space exploration. ;-) Now, delegate the remaining bytes to the address allocation authorities for the respective continents. And give them good advice... Tony From owner-Big-Internet@munnari.oz.au Thu Feb 11 23:42:03 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15205; Thu, 11 Feb 1993 23:42:25 +1100 (from owner-Big-Internet) Return-Path: Received: from coombs.anu.edu.au by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15192; Thu, 11 Feb 1993 23:42:03 +1100 (from avalon@coombs.anu.edu.au) Received: by coombs.anu.edu.au (5.61/1.0) id AA16325; Thu, 11 Feb 93 23:41:12 +1100 From: avalon@coombs.anu.edu.au (Darren Reed) Message-Id: <9302111241.AA16325@coombs.anu.edu.au> Subject: Re: addressing To: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Date: Thu, 11 Feb 93 23:41:10 EST Cc: kasten@ftp.com, tli@cisco.com, big-internet@munnari.oz.au, deering@parc.xerox.com In-Reply-To: <9302101829.AA28293@chiya.bellcore.com>; from "Paul Tsuchiya" at Feb 10, 93 1:29 pm Reply-To: avalon@coombs.anu.edu.au X-Mailer: ELM [version 2.3 PL11] In some email I received from Paul Tsuchiya, Sie wrote: > > > Would I be correct in extending your statement to say that we are > > really only able to define how to represent hierarchies in the > > addresses at this time, and not what those hierarchies actually are? > > > > Yup. > > > > Tony > > But, we have to at least nail down the top of the hierarchy > before we start significant deployment...... > > I have interpreted the whole geographic vs. provider to be > an argument about what the top of the hierarchy should look > like..... > > PX Someone else suggested that the top hierarchy be created as needed with addressing built from the bottom up. This makes a lot of sense and should be easily achievable using PIP. Why create a top you don't need ? Or one that will need replacing ? It should also be possible to build down as well as up.. By not fixing to either geographic or provider, it should be possible to build a network which has logical levels only which form the top, bottom or middle and to distribute routing information according to where you are. This should allow both to be incorporated. If autoconfiguring of hosts is required, why not let routers anywhere in the routing tree autoconfigure to the position they are in when they boot ? Is it workable to have a router believe it is the top of the routing tree (however unbalanced it may be) ? Some sort of 'depth' discovery would be needed for each attached network. Is it possible for TUBA/SIP to deal with these sorts of situations ? Darren. From owner-Big-Internet@munnari.oz.au Fri Feb 12 03:21:20 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21930; Fri, 12 Feb 1993 03:21:54 +1100 (from owner-Big-Internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AB21918; Fri, 12 Feb 1993 03:21:20 +1100 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA17097; Thu, 11 Feb 93 11:21:02 -0500 Date: Thu, 11 Feb 93 11:21:02 -0500 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9302111621.AA17097@ginger.lcs.mit.edu> To: tli@cisco.com, tsuchiya@thumper.bellcore.com Subject: Re: addressing Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu I strongly disagree. The top of the hierarchy (above the metro area) looks the same in either case. ... The first byte will indicate the continent: ... Now, delegate the remaining bytes to the address allocation authorities for the respective continents. I assume by 'address' here you mean something like what I mean by 'address'; i.e. the thing the routers look at that tells you *where* in the network something is, right? OK. I am a multi-national, with offices in, say, the U.S. and France. It sounds like, under your plan, I'd give each offices addresses out of their continental spaces, and the internal company routing would have to track both subsets of the continental spaces directly, with 'defaults' for the rest of the continental stuff? In other words, the internal routing would just have to deal with the fact that there was no addressing aggregate for the company as a whole? In other words, you would not try and maximize the amount of aggregation, but simply take whatever you got accidentally through use of the continent system? What about, say, two large multi-nationals, with offices in many countries, which wanted to establish a direct link so they could do a joint venture. Each one would have to internally route all the little subpices of the address space which made up the other company? Noel From owner-Big-Internet@munnari.oz.au Fri Feb 12 09:12:27 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA29190; Fri, 12 Feb 1993 09:13:36 +1100 (from owner-Big-Internet) Return-Path: Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29161; Fri, 12 Feb 1993 09:12:27 +1100 (from tli@cisco.com) Received: by lager.cisco.com; Thu, 11 Feb 1993 14:11:37 -0800 Date: Thu, 11 Feb 1993 14:11:37 -0800 From: Tony Li Message-Id: <199302112211.AA22363@lager.cisco.com> To: bsimpson@morningstar.com Cc: big-internet@munnari.oz.au, kasten@ftp.com, tli@cisco.com, deering@parc.xerox.com, tsuchiya@thumper.bellcore.com In-Reply-To: "William Allen Simpson"'s message of Thu, 11 Feb 93 14:42:22 EDT <929.bill.simpson@um.cc.umich.edu> Subject: addressing It appears that Tony would really like my address plan which I had posted to the SIP list. Hopefully, he will find it useful as a model for the CIDR effort. Thanks, but the CIDR address assignment is not done by yours truly. Just the good advice... Tony From owner-big-internet@munnari.oz.au Fri Feb 12 12:41:29 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA04054; Fri, 12 Feb 1993 12:44:12 +1100 (from owner-big-internet) Return-Path: Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15107; Thu, 11 Feb 1993 05:49:19 +1100 (from tli@cisco.com) Received: by lager.cisco.com; Wed, 10 Feb 1993 10:47:05 -0800 Date: Wed, 10 Feb 1993 10:47:05 -0800 From: Tony Li Message-Id: <199302101847.AA13137@lager.cisco.com> To: tsuchiya@thumper.bellcore.com Cc: kasten@ftp.com, tli@cisco.com, big-internet@munnari.oz.au, deering@parc.xerox.com, tsuchiya@thumper.bellcore.com In-Reply-To: Paul Tsuchiya's message of Wed, 10 Feb 93 13:29:16 EST <9302101829.AA28293@chiya.bellcore.com> Subject: addressing But, we have to at least nail down the top of the hierarchy before we start significant deployment...... I have interpreted the whole geographic vs. provider to be an argument about what the top of the hierarchy should look like..... I strongly disagree. The top of the hierarchy (above the metro area) looks the same in either case. The only thing that would have to be nailed down at this point is the top level. E.g.: I assume byte level granularity in addresses (if your particular protocol does otherwise, please generalize). The first byte will indicate the continent: 0 Europe 1 Asia 2 Africa 3 Antartica/Australia 4 South America 5 North America Remaining values of the first byte can be used for space exploration. ;-) Now, delegate the remaining bytes to the address allocation authorities for the respective continents. And give them good advice... Tony From owner-big-internet@munnari.oz.au Fri Feb 12 13:19:25 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA04753; Fri, 12 Feb 1993 13:22:15 +1100 (from owner-big-internet) Return-Path: Received: from thumper.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15588; Thu, 11 Feb 1993 06:09:07 +1100 (from tsuchiya@thumper.bellcore.com) Received: from chiya.bellcore.com by thumper.bellcore.com (4.1/4.7) id for big-internet@munnari.oz.au; Wed, 10 Feb 93 14:07:57 EST Received: by chiya.bellcore.com (4.1/4.7) id for tsuchiya@thumper.bellcore.com; Wed, 10 Feb 93 14:07:55 EST Date: Wed, 10 Feb 93 14:07:55 EST From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Message-Id: <9302101907.AA28382@chiya.bellcore.com> To: tli@cisco.com, tsuchiya@thumper.bellcore.com Subject: Re: addressing Cc: big-internet@munnari.oz.au, deering@parc.xerox.com, kasten@ftp.com > > But, we have to at least nail down the top of the hierarchy > before we start significant deployment...... > > I have interpreted the whole geographic vs. provider to be > an argument about what the top of the hierarchy should look > like..... > > I strongly disagree. The top of the hierarchy (above the metro area) > looks the same in either case. The only thing that would have to be > nailed down at this point is the top level. E.g.: *If* you are doing metro areas. If you doing provider, then metro areas (or continents, as somebody suggested and you copied below) don't come into it at all. If provider, then the provider is at the top....... That's my whole point. This argument has been to decide if provider or metro is at the top of the hierarchy...... > > I assume byte level granularity in addresses (if your particular > protocol does otherwise, please generalize). The first byte will > indicate the continent: > > 0 Europe > 1 Asia > 2 Africa > 3 Antartica/Australia > 4 South America > 5 North America > > Remaining values of the first byte can be used for space exploration. > ;-) > > Now, delegate the remaining bytes to the address allocation > authorities for the respective continents. And give them good > advice... > Do you view these continents as containing topological information or are they just topologically-superflous administrative assignments ala NSAPs? PX From owner-big-internet@munnari.oz.au Fri Feb 12 19:04:37 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12907; Fri, 12 Feb 1993 19:07:24 +1100 (from owner-big-internet) Return-Path: Received: from thumper.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19209; Thu, 11 Feb 1993 09:02:08 +1100 (from tsuchiya@thumper.bellcore.com) Received: from chiya.bellcore.com by thumper.bellcore.com (4.1/4.7) id for big-internet@munnari.oz.au; Wed, 10 Feb 93 17:01:22 EST Received: by chiya.bellcore.com (4.1/4.7) id for tsuchiya@thumper.bellcore.com; Wed, 10 Feb 93 17:01:21 EST Date: Wed, 10 Feb 93 17:01:21 EST From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Message-Id: <9302102201.AA28868@chiya.bellcore.com> To: tli@cisco.com, tsuchiya@thumper.bellcore.com Subject: Re: addressing Cc: big-internet@munnari.oz.au, deering@parc.xerox.com, kasten@ftp.com > > But, all of your examples have metro at the top (at least, > what I have come to understand as "metro"). > > !!!! > > Gee. And here I thought they were continents. ;-) [Background > music: "It's a small world, after all..."] Alright alright......I have equated "metro" with "geographical". Anyway, I think it was Deering who suggested that the number of metros in the world is small enough that metro could appear at the top. > > BarrNet.[internal BarrNet addressing].cisco.[internal cisco > address].tli-home > > I don't put any geographical information up front at all. > > But this clearly does NOT scale. Was someone advocating doing this? Aw, cum'on Tony. I can accept someone saying that provider-based as I define them *might* not scale, but to say "clearly"? In order to say "clearly", you'd have to argue that it is *clear* that there will be more than N providers at some time in the future, and that it is *clear* that N is too many, according to some future technology.... But, just for fun, let's say that we agree that 15,000 providers is too many (we're not *that* far from 15,000 IP networks, so I guess 15,000 is not too many.....but for the sake of argument.....). Do you think it is *clear* that we will have 15,000 providers any time soon? To me that means 15,000 providers that are worth advertising at the top level.....some really localized small provider could be placed at the next level of hierarchy down. I'm not a business major, but I guess that normal industry shakedown would prevent there from being much more than 15,000 significant providers in the world..... And, if it turns out that there are more than 15,000 (or whatever top-level routing can handle in the future) top-level providers, then you could at that time introduce another layer of hierarchy above the provider level (confederacies of providers......). Since any provider-based scheme will have had to have solved the address assignment problem anyway..... > > Just out of curiosity, were other people thinking of my > provider-based example or Tony's provider-based example > when they thought of provider based addresses? > > I am now of the opinion that this WHOLE discussion is just pure > miscommunication. That we're all in violent agreement and that we'll > make no progress on this until we set forth some very careful > definitions. What? You mean you are saying that it is so completely *clear* to *everybody* that provider-rooted addresses won't scale that it is not even up for discussion? Is this the opinion of others out there????? PX From owner-big-internet@munnari.oz.au Fri Feb 12 20:53:45 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15538; Fri, 12 Feb 1993 20:55:11 +1100 (from owner-big-internet) Return-Path: Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24223; Thu, 11 Feb 1993 12:11:51 +1100 (from tli@cisco.com) Received: by lager.cisco.com; Wed, 10 Feb 1993 17:11:25 -0800 Date: Wed, 10 Feb 1993 17:11:25 -0800 From: Tony Li Message-Id: <199302110111.AA03363@lager.cisco.com> To: tsuchiya@thumper.bellcore.com Cc: tsuchiya@thumper.bellcore.com, big-internet@munnari.oz.au, deering@parc.xerox.com, kasten@ftp.com In-Reply-To: Paul Tsuchiya's message of Wed, 10 Feb 93 17:01:21 EST <9302102201.AA28868@chiya.bellcore.com> Subject: addressing Alright alright......I have equated "metro" with "geographical". Anyway, I think it was Deering who suggested that the number of metros in the world is small enough that metro could appear at the top. Yes, for today. I would guess that we're talking ~100. > But this clearly does NOT scale. Was someone advocating doing this? Aw, cum'on Tony. I can accept someone saying that provider-based as I define them *might* not scale, but to say "clearly"? Well, it's clear to _me_. Assuming that you don't have giant monopolistic providers, I would assume that they would continue to grow at the rate the the rest of the internet does. 130%/year. So by the end of 30 years, you're at 262,000 providers. I admit that this is generous, but if it IS the case, you've just pushed the problem a few more years. Can you _guarantee_ that this doesn't happen? The _real_ problem here is that it is growing linearly with respect to the network growth. For something to scale, it MUST escape linear growth. With the continental prefixes that I described, I can guarantee you that a) the number of continents does not change (at least in 30 years ;-), b) the minimal amount of routing information needed to maintain wide-area reachability is fixed [but this information may well be sub-optimal, such is life with abstraction], c) growth in other parts of the system (i.e., population explosion on a different continent) does not perturb the system. In order to say "clearly", you'd have to argue that it is *clear* that there will be more than N providers at some time in the future, and that it is *clear* that N is too many, according to some future technology.... I disagree. I feel fine saying that this "clearly" doesn't scale because the top of the hierarchy now grows linearly with how some component in the network grows. But, just for fun, let's say that we agree that 15,000 providers is too many (we're not *that* far from 15,000 IP networks, so I guess 15,000 is not too many.....but for the sake of argument.....). Do you think it is *clear* that we will have 15,000 providers any time soon? To me that means 15,000 providers that are worth advertising at the top level.....some really localized small provider could be placed at the next level of hierarchy down. Please stop changing the rules. In the pure provider-based scheme that you were talking about, everyone gets top level, regardless of size. In fact, I think that I'm going to become a provider (selling service to my city block) so that I get a shorter prefix and can type less. ;-) The fact that you would consider adding a hierarchy of providers into this scheme already indicates that it has problems. I'm not a business major, but I guess that normal industry shakedown would prevent there from being much more than 15,000 significant providers in the world..... How many phone companies are there in the world? How many 7-11's? And, if it turns out that there are more than 15,000 (or whatever top-level routing can handle in the future) top-level providers, then you could at that time introduce another layer of hierarchy above the provider level (confederacies of providers......). Since any provider-based scheme will have had to have solved the address assignment problem anyway..... But then you're stuck with a MASSIVE renumbering problem. One that you can just avoid right now. Just put hierarchy in today. We're probably talking two bytes here... One if you need to be stingy. > I am now of the opinion that this WHOLE discussion is just pure > miscommunication. That we're all in violent agreement and that we'll > make no progress on this until we set forth some very careful > definitions. What? You mean you are saying that it is so completely *clear* to *everybody* that provider-rooted addresses won't scale that it is not even up for discussion? No. I'm a nice guy -- I'll discuss ANYTHING. The discussion has been so ill-defined that we're just not making progress. I would very much like to see us focus this somehow. Strawman: start an IPv7 addressing and routing BOF/WG. I believe that the addressing and routing plans are very similar, if not identical, across all of the proposed network protocols. I believe that if we put names to concrete ideas and draw lotsa pictures that we will quickly come to consensus. Famous last words. ;-) Tony From owner-big-internet@munnari.oz.au Sat Feb 13 00:44:25 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA20630; Sat, 13 Feb 1993 00:46:52 +1100 (from owner-big-internet) Return-Path: Received: from vela.acs.oakland.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03641; Thu, 11 Feb 1993 16:58:59 +1100 (from bill.simpson@um.cc.umich.edu) Received: from via.ws04.merit.edu by vela.acs.oakland.edu with SMTP id AA15244 (5.65c+/IDA-1.4.4); Thu, 11 Feb 1993 00:58:34 -0500 Date: Thu, 11 Feb 93 00:49:00 EDT From: "William Allen Simpson" Message-Id: <917.bill.simpson@um.cc.umich.edu> To: big-internet@munnari.oz.au Reply-To: bsimpson@morningstar.com Subject: ARP versus ES-IS I think that we've beaten the Metro thread into the ground. Could all you ARP fans tell me what's bad about ES-IS? Could all you ES-IS fans tell me what's bad about ARP? What would we do in a perfect world? an imperfect world? Bill.Simpson@um.cc.umich.edu From owner-big-internet@munnari.oz.au Sat Feb 13 05:04:49 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA26230; Sat, 13 Feb 1993 05:05:00 +1100 (from owner-big-internet) Return-Path: Received: from OPAL.ACC.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22250; Fri, 12 Feb 1993 03:32:47 +1100 (from art@opal.acc.com) Received: by opal.acc.com (4.1/SMI-4.0) id AA13916; Thu, 11 Feb 93 08:32:11 PST Date: Thu, 11 Feb 93 08:32:11 PST From: art@opal.acc.com (Art Berggreen) Message-Id: <9302111632.AA13916@opal.acc.com> To: tli@cisco.com Subject: Re: addressing Cc: big-internet@munnari.oz.au > 0 Europe > 1 Asia > 2 Africa > 3 Antartica/Australia > 4 South America > 5 North America > >Remaining values of the first byte can be used for space exploration. >;-) So, has Van started work on dealing with the bandwidth/delay of interstellar communications channels? ;-} ;-} ;-} If physics finds away around the speed-of-light, do we need protocols that can deal with getting ACKs before they have sent the data? ;-} ;-} ;-} Art "Inquiring minds want to know." From owner-big-internet@munnari.oz.au Sat Feb 13 05:10:27 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA26427; Sat, 13 Feb 1993 05:10:49 +1100 (from owner-big-internet) Return-Path: Received: from thumper.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20662; Fri, 12 Feb 1993 02:35:46 +1100 (from tsuchiya@thumper.bellcore.com) Received: from chiya.bellcore.com by thumper.bellcore.com (4.1/4.7) id for big-internet@munnari.oz.au; Thu, 11 Feb 93 10:35:20 EST Received: by chiya.bellcore.com (4.1/4.7) id for tsuchiya@thumper.bellcore.com; Thu, 11 Feb 93 10:35:19 EST Date: Thu, 11 Feb 93 10:35:19 EST From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Message-Id: <9302111535.AA29664@chiya.bellcore.com> To: avalon@coombs.anu.edu.au, tsuchiya@thumper.bellcore.com Subject: Re: addressing Cc: big-internet@munnari.oz.au, deering@parc.xerox.com, kasten@ftp.com, tli@cisco.com > > Someone else suggested that the top hierarchy be created as needed with > addressing built from the bottom up. This makes a lot of sense and > should be easily achievable using PIP. Why create a top you don't need ? > Or one that will need replacing ? It should also be possible to build > down as well as up.. I know that Chiappa has argued for bottom up numbering.... Pip numbers levels from the top down. I struggled for some time with bottom-up, but couldn't make it work. In the end, I found that you have no choice but to define a top level, even if you leave the bottom open and flexible. (Actually, kampai is a bottom-up address "number assignment" scheme, but even that scheme doesn't let you avoid deciding what each level of the hierarchy "represents", ie, a provider or a region..... PX From owner-big-internet@munnari.oz.au Sat Feb 13 05:28:46 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA26826; Sat, 13 Feb 1993 05:28:53 +1100 (from owner-big-internet) Return-Path: Received: from p.lanl.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21854; Fri, 12 Feb 1993 03:20:07 +1100 (from peter@goshawk.lanl.gov) Received: from goshawk.lanl.gov by p.lanl.gov (5.65/1.14) id AA25940; Thu, 11 Feb 93 09:19:44 -0700 Received: from localhost.lanl.gov by goshawk.lanl.gov (4.1/5.17) id AA27370; Thu, 11 Feb 93 09:19:43 MST Message-Id: <9302111619.AA27370@goshawk.lanl.gov> To: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Cc: kasten@ftp.com, tli@cisco.com, big-internet@munnari.oz.au, deering@parc.xerox.com Subject: Re: addressing In-Reply-To: Your message of Wed, 10 Feb 93 13:29:16 -0500. <9302101829.AA28293@chiya.bellcore.com> Date: Thu, 11 Feb 93 09:19:43 MST From: peter@goshawk.lanl.gov >>> But, we have to at least nail down the top of the hierarchy >>> before we start significant deployment...... That would be true if you were talking about a pure hierarchy. If you are using longest match routing/forwarding then you can escape a lot of the early decisions thereby allowing you to effectively utilize the real topology. For example, we could pick a pure metro system for addressing but in the "higher" levels of the routing system you will likely see Metro*Provider (or is that Provider*Metro? ). Strictly hierarchical in both addressing and routing equals optimality, but you are going to have to plan for those nasty non-optimal cases. The topology will be as much influenced by externalities such as economics and satellite footprints as by engineering planning. cheers, peter From owner-big-internet@munnari.oz.au Sat Feb 13 05:32:31 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA26884; Sat, 13 Feb 1993 05:32:36 +1100 (from owner-big-internet) Return-Path: Received: from thumper.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23769; Fri, 12 Feb 1993 04:47:53 +1100 (from tsuchiya@thumper.bellcore.com) Received: from chiya.bellcore.com by thumper.bellcore.com (4.1/4.7) id for big-internet@munnari.oz.au; Thu, 11 Feb 93 12:47:30 EST Received: by chiya.bellcore.com (4.1/4.7) id for mobile-ip@parc.xerox.com; Thu, 11 Feb 93 12:47:29 EST Date: Thu, 11 Feb 93 12:47:29 EST From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Message-Id: <9302111747.AA00277@chiya.bellcore.com> To: big-internet@munnari.oz.au, lillie@comm.mot.com Subject: Re: Mobility and Routing (was Metro Addressing) Cc: mobile-ip@parc.xerox.com I'll confess that I didn't read you're whole message. But, I saw the question and I'll answer for Pip. Pip only deals with mobility at the internet (Pip) layer..... That is, when the mobile host gets a new Pip Address, then mobility kicks in (the other end learns the new address, etc.) If some "lower level" mobility is going on that doesn't result in a new Pip Address (for instance, crossing radio cells in a single Pip subnet), that is transparent to Pip and Pip doesn't have any mechanisms to deal with it one way or another..... PX From owner-big-internet@munnari.oz.au Sat Feb 13 06:11:33 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA27861; Sat, 13 Feb 1993 06:11:41 +1100 (from owner-big-internet) Return-Path: Received: from vela.acs.oakland.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24965; Fri, 12 Feb 1993 05:52:01 +1100 (from bill.simpson@um.cc.umich.edu) Received: from via.ws04.merit.edu by vela.acs.oakland.edu with SMTP id AA00738 (5.65c+/IDA-1.4.4); Thu, 11 Feb 1993 13:51:26 -0500 Date: Thu, 11 Feb 93 13:08:24 EDT From: "William Allen Simpson" Message-Id: <923.bill.simpson@um.cc.umich.edu> To: big-internet@munnari.oz.au Cc: vaf@Stanford.EDU Cc: tli@cisco.com Cc: jyy@merit.edu Cc: kannan@oar.net Reply-To: bsimpson@morningstar.com Subject: the cidr draft Looked at the CIDR draft. Diffs from RFC 1338 don't show a lot of changes except the new Class A section. I was hoping for the actual allocation assignments. Neither yours nor ip-guidelines [RL] actually proposes numbers. I was also amused to note that in 1338 "all class B's will be exhausted within about 15 months". It has been 12 months, and it hasn't happened, as your new numbers attest. Presumably in your re-write you could take note of this, and offer some explanation in the change in allocation policy since that time. We have some experience by now. Could we get a statement as to the progress in changing the NSFnet backbone to classless? What about the regionals (three of whom are represented in the draft)? Two nits: - "rate of grown" -> "rate of growth". - "As AS" -> "An AS" Bill.Simpson@um.cc.umich.edu From owner-big-internet@munnari.oz.au Sat Feb 13 06:25:47 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA28124; Sat, 13 Feb 1993 06:25:59 +1100 (from owner-big-internet) Return-Path: Received: from thumper.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22645; Fri, 12 Feb 1993 03:49:08 +1100 (from tsuchiya@thumper.bellcore.com) Received: from chiya.bellcore.com by thumper.bellcore.com (4.1/4.7) id for big-internet@munnari.oz.au; Thu, 11 Feb 93 11:48:03 EST Received: by chiya.bellcore.com (4.1/4.7) id for tsuchiya@thumper.bellcore.com; Thu, 11 Feb 93 11:48:02 EST Date: Thu, 11 Feb 93 11:48:02 EST From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Message-Id: <9302111648.AA29973@chiya.bellcore.com> To: peter@goshawk.lanl.gov, tsuchiya@thumper.bellcore.com Subject: Re: addressing Cc: big-internet@munnari.oz.au, deering@parc.xerox.com, kasten@ftp.com, tli@cisco.com > > >>> But, we have to at least nail down the top of the hierarchy > >>> before we start significant deployment...... > > > That would be true if you were talking about a pure hierarchy. > If you are using longest match routing/forwarding then you can > escape a lot of the early decisions thereby allowing you to > effectively utilize the real topology. For example, we could > pick a pure metro system for addressing but in the "higher" levels > of the routing system you will likely see Metro*Provider (or is that > Provider*Metro? ). > But Peter, that's exactly the question, isn't it? Is it metro.provider or provider.metro? I agree that you could stick metro at the top and ignore it until the day that there are too many providers, then start to pay attention to it....(and do all the wiring necessary to make it work.....). And in doing so, you've managed to avoid the renumbering problem by putting the eventual top-level in from the beginning..... But, even with this hedging, you are making the decision for the "top" to be provider (in my example). I guess we are argueing at cross-purposes.....You are saying that by manipulating routing, you can hedge on what the top of the hierarchy in the address numbering is. I agree. What I'm saying is that, at the point where you send routing updates around, you have no choice to decide if the routing update reflects a provider or a geography. PX From owner-big-internet@munnari.oz.au Sat Feb 13 10:12:32 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03318; Sat, 13 Feb 1993 10:12:44 +1100 (from owner-big-internet) Return-Path: Received: from motgate.mot.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22329; Fri, 12 Feb 1993 03:36:03 +1100 (from lillie@comm.mot.com) Received: from pobox.mot.com ([129.188.137.100]) by motgate.mot.com with SMTP (5.65c/IDA-1.4.4/MOT-2.6 for ) id AA24159; Thu, 11 Feb 1993 10:35:15 -0600 Received: from comm.mot.com ([145.1.3.2]) by pobox.mot.com with SMTP (5.65c/IDA-1.4.4/MOT-2.6) id AA26532; Thu, 11 Feb 1993 10:35:13 -0600 Received: from anchor.comm.mot.com by comm.mot.com (4.1/SMI-4.0) id AA24632; Thu, 11 Feb 93 10:40:35 CST Received: by anchor.comm.mot.com (5.65/DEC-Ultrix/4.3) id AA15130; Thu, 11 Feb 1993 10:32:48 -0600 Message-Id: <9302111632.AA15130@anchor.comm.mot.com> To: big-internet@munnari.oz.au Cc: mobile-ip@parc.xerox.com Subject: Mobility and Routing (was Metro Addressing) Date: Thu, 11 Feb 93 10:32:47 -0600 From: lillie@comm.mot.com X-Mts: smtp I have been following the ongoing discussions regarding addressing/naming, abstraction/aggregation over the past months with much interest. As it appears that the charter for IPv7 now encompasses the problems of host mobility, my question concerns the definition of 'mobility' that is currently envisioned by the contributors to this discussion. In present-day cellular communication systems a distinction is usually made between the wide-area mobile host 'roaming' versus local-area (or metropolitan area?) mobile host 'handover'. Host mobility concerns as currently being discussed in this group seem best to fit the conventional definition of 'roaming', in a cellular system model. This encompasses geographic region to geographic region, metro-area to metro-area, or provider (carrier) to provider mobility. The principal distinction that I apply to these 2 types of mobility primarily involves the *rate* at which a mobile device (user/host?) changes location. While other attributes could serve to distinguish these mobility modes, the mobility rate provides the basis of engineering a solution to these 2 distinct problems. Roaming is a tractable problem; indeed a number of international standards within the wireless land-mobile, and telco communities have emerged in recent years (cf. Q.1000 series of recommendations, GSM/IS.41 standards, etc.) addressing inter-system host mobility. (I view *roaming*, perhaps naively, as the scenario of a mobile host establishing a session in Chicago, ending the session, getting on a plane, starting a new session in LA, 4 hours later.) For the *majority* (yes, an assumption is being made here...) of network subscribers roaming over like geographic distances (or time spans), uninterrupted network connectivity may not be of primary concern; only the fact that once they have roamed to a new destination that they have transparent connectivity to and availability of the underlying network fabric at their new location (regardless of the underlying area's service providers.) For the roaming model, if we assume some type of routing aggregation based upon provider, geographic boundary, or metro area, the amount of inter-cluster routing control traffic required to *track* the location of mobile subscribers should be far less that the information that must be propagated intra-cluster to track mobile subscribers moving within the cluster boundaries. This is not to say that a *roaming* solution should ignore the possibility of allowing uninterrupted service (i.e. you don't lose your connection/session), only that it may not be an optimal solution for this type of (*wide*-area) traffic. In a truly 'mobile' environment, some portion of the links comprising an internet will most likely be wireless. As we move within a cluster (as defined above), the problem of mobility management may become much more finely grained. A mobile subscriber's location now (assuming RF data links) becomes associated with one end of an RF channel. Furthermore, some method of frequence reuse will most likely be employed to increase overall system capacity, given the finite spectral allocations for wireless systems. In the Chicago area today, the average cellular telephone coverage area is on the order of 6 miles 'radius' (as an upper bound one can assume approximately 30 channels/cell in the competing Chicago area cellular systems.) Future system trends see the industry moving to 'microcells', providing coverage areas down the the city-block area. Assume for the moment, that RF coverage areas have well-defined 'edges', which they don't, but assume it anyway. It should be clear, that as a geographic region is subdivided into ever smaller coverage areas, the likelihood of a mobile user leaving one cell and entering another, during an active 'session' increases. Moreover consider a network containing 1000s of microcells, with 100,000s of mobile subscribers (probably very conservative), all moving about. Even if you make the assumption that mobile subscribers are NOT moving during a session (i.e. you're not typing on your laptop as you're driving down the freeway), the vagaries of the RF data-link (remember our asumption above) cause you problems. Two principal signal degradation mechanisms must be dealt with: short term signal fading, typically Rayleigh distributed and medium term signal decorrelation, typically log-normal distributed. Short-term fading is the familiar multi-path signal degradation, and can be effectively combated using diversity reception techniques. The medium-term log-normal, or 'shadowing' degradation, however, must be lived with. For example, a bus driving by, or the user sitting in an orientation where their body is between the mobile and the base site transmission path, both may *contribute* to the medium-term signal decorrelation. Consequently, even a stationary mobile user may be undergoing numerous handovers in a micro-cellular environment, due to the dynamics of the environment by which it is surrounded. Where does this rambling lead us? Typical land-mobile (i.e. users driving around in their cars) can exhibit average handoff rates on the order of 10-20 seconds/handoff/mobile, in an urban environment. As future architectures move towards microcells (and even if we make the assumption that the 'typical' mobile user will be stationary when active on the network,) because of the inherent signal decorrelation affects described above, handoff traffic will still be a *significant* amount of the control activity present in the network. The routing architecture that deals with *handover* must provide rapid convergence (to avoid having *lost* packets queued throughout the networks), and significant information aggregation to avoid consuming excessive network resources (scaling). The architecture most likely will be dealing with 1000s or 10000s (or more) of *routing updates* every second. Most present-day mobile-data (and voice, for that matter), cell-based networks rely upon centralized routing and control architectures. This approach is leading to problems handling the handover-routing traffic today, and most likely will not suffice in the very near future. After this rather long winded message, I return to my original question, that being what is meant by 'mobility' in these discussions? Moreover, is the ultimate goal to provide one common solution for host-mobility that satisfies the needs of not only wide-area regional mobility, but also local-area mobility? Furthermore, is this even possible given the certain possibility of different technological solutions for in-building versus out-of-building coverage, campus mobility versus metro-area mobility, etc? --------------------------------- Ross Lillie (lillie@comm.mot.com) LMPS Systems Research Lab Motorola, Inc. 1301 E. Algonquin Rd. IL02/2240 Schaumburg, Illinois 60195 From owner-big-internet@munnari.oz.au Sat Feb 13 10:37:52 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA04033; Sat, 13 Feb 1993 10:37:57 +1100 (from owner-big-internet) Return-Path: Received: from vela.acs.oakland.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26774; Fri, 12 Feb 1993 07:13:13 +1100 (from bill.simpson@um.cc.umich.edu) Received: from via.ws04.merit.edu by vela.acs.oakland.edu with SMTP id AA07353 (5.65c+/IDA-1.4.4); Thu, 11 Feb 1993 15:05:40 -0500 Date: Thu, 11 Feb 93 14:42:22 EDT From: "William Allen Simpson" Message-Id: <929.bill.simpson@um.cc.umich.edu> To: big-internet@munnari.oz.au Cc: kasten@ftp.com, tli@cisco.com, deering@parc.xerox.com, tsuchiya@thumper.bellcore.com Reply-To: bsimpson@morningstar.com Subject: Re: addressing It appears that Tony would really like my address plan which I had posted to the SIP list. Hopefully, he will find it useful as a model for the CIDR effort. SIP Continental Allocation Plan fraction of allocation prefix (binary) addr. space ----------------------------------- ------------------- ----------- reserved IP4 C000 0000 1/128 reserved for future use C000 0001 1/128 reserved for future use C000 001 1/64 reserved for future use C000 01 1/32 reserved for future use C000 1 1/16 Europe C001 1/8 North America C010 1/8 South America C011 1/8 Asia C10 1/4 Africa C110 1/8 South Pacific & Antarctica C111 0 1/16 reserved for future use C111 10 1/32 reserved for future use C111 110 1/64 reserved for future use C111 1110 1/128 multicast C111 1111 1/128 C = IP4 compatibility prefix Country, Provider and Metropolitan Area based allocations are made within the Continents. The reserved portions may be used as needed for other bodies within the local solar system, or to augment other special uses. Bill.Simpson@um.cc.umich.edu From owner-big-internet@munnari.oz.au Sat Feb 13 11:38:01 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AB06099; Sat, 13 Feb 1993 11:38:06 +1100 (from owner-big-internet) Return-Path: Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28797; Fri, 12 Feb 1993 08:56:17 +1100 (from tli@cisco.com) Received: by lager.cisco.com; Thu, 11 Feb 1993 13:55:54 -0800 Date: Thu, 11 Feb 1993 13:55:54 -0800 From: Tony Li Message-Id: <199302112155.AA21208@lager.cisco.com> To: jnc@ginger.lcs.mit.edu Cc: tsuchiya@thumper.bellcore.com, big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu In-Reply-To: Noel Chiappa's message of Thu, 11 Feb 93 11:21:02 -0500 <9302111621.AA17097@ginger.lcs.mit.edu> Subject: addressing I assume by 'address' here you mean something like what I mean by 'address'; i.e. the thing the routers look at that tells you *where* in the network something is, right? Yes. Absolutely. [And I believe that EID's are not assigned to hosts, but to processes! ;-)] OK. I am a multi-national, with offices in, say, the U.S. and France. It sounds like, under your plan, I'd give each offices addresses out of their continental spaces, and the internal company routing would have to track both subsets of the continental spaces directly, with 'defaults' for the rest of the continental stuff? In other words, the internal routing would just have to deal with the fact that there was no addressing aggregate for the company as a whole? With the general case of multihomed networks, there are large number of things that are possible. I refer you to "OSI guidelines" for a better discussion than I can ever present. In other words, you would not try and maximize the amount of aggregation, but simply take whatever you got accidentally through use of the continent system? You DO maximize aggregation. You maximize whatever is seen outside of the multi-national. What about, say, two large multi-nationals, with offices in many countries, which wanted to establish a direct link so they could do a joint venture. Each one would have to internally route all the little subpices of the address space which made up the other company? Yup. There's always noise in the system. Anytime that you have hierarchical addressing and a non-hierarchical topology, you get noise. The point is that it is local. Tony From owner-big-internet@munnari.oz.au Sat Feb 13 12:11:35 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AB06871; Sat, 13 Feb 1993 12:11:37 +1100 (from owner-big-internet) Return-Path: Received: from mitsou.inria.fr by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16468; Fri, 12 Feb 1993 21:38:42 +1100 (from huitema@mitsou.inria.fr) Received: by mitsou.inria.fr (5.65c/IDA-1.2.8) id AA09285; Fri, 12 Feb 1993 11:40:57 +0100 Message-Id: <199302121040.AA09285@mitsou.inria.fr> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: tli@cisco.com, tsuchiya@thumper.bellcore.com, big-internet@munnari.oz.au Subject: Re: addressing In-Reply-To: Your message of "Thu, 11 Feb 93 11:21:02 EST." <9302111621.AA17097@ginger.lcs.mit.edu> Date: Fri, 12 Feb 93 11:40:56 +0100 From: Christian Huitema Noel, I am very pleased to agree with you! I am also extremely skeptical on anything that strictly enforces countries, or even continent, boundaries. The current discussion showed that: 1) many people were not absolutely convinced that "metro addressing" was a riskless path to the large scale Internet. 2) the only "rough consensus" is on "doing CIDR now", i.e. use "provider addresses", and be ready to pay the cost of address renumbering when one "changes provider" -- or whatever that means. And, yes, the cost of supporting this may vary with the different architectures -- as other costs also vary. I think this means that as we dont know now how the address space will be used in 10 years, we should avoid "gratuitous allocation", and only use a limited part of the address space now. For example, if we enlarge IP addresses by doubling their size, maybe we should restrain ourselves and use only 16 bits of extension in the short term, leaving 16 bits free for renumbering when the situation clarifies. Christian Huitema From owner-big-internet@munnari.oz.au Sat Feb 13 12:31:14 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA07463; Sat, 13 Feb 1993 12:31:15 +1100 (from owner-big-internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00536; Sat, 13 Feb 1993 08:02:17 +1100 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA02618; Fri, 12 Feb 93 16:01:45 -0500 Date: Fri, 12 Feb 93 16:01:45 -0500 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9302122101.AA02618@ginger.lcs.mit.edu> To: avalon@coombs.anu.edu.au, tsuchiya@thumper.bellcore.com Subject: Re: addressing Cc: big-internet@munnari.oz.au, deering@parc.xerox.com, jnc@ginger.lcs.mit.edu I know that Chiappa has argued for bottom up numbering.... Let me hasten to add that I got the idea for it from a talk by Dave Reed at MIT-LCS when I was still a pup... I struggled for some time with bottom-up, but couldn't make it work. In the end, I found that you have no choice but to define a top level Why? Bottom-up seems to have worked reasonably well in the phone system as it grew. I mean, they didn't have country codes all figured out when they started depoying phones in 1900 or whenever. As you as you know in what context an address is to be interpreted, does it matter than contexts can nest indefinitely upward? Noel From owner-big-internet@munnari.oz.au Sat Feb 13 13:18:34 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA08845; Sat, 13 Feb 1993 13:18:47 +1100 (from owner-big-internet) Return-Path: Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02938; Sat, 13 Feb 1993 09:54:01 +1100 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <11809>; Fri, 12 Feb 1993 14:53:01 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Fri, 12 Feb 1993 14:52:59 -0800 To: big-internet@munnari.oz.au Cc: tsuchiya@thumper.bellcore.com, tli@cisco.com, deering@parc.xerox.com Subject: Re: addressing Date: Fri, 12 Feb 1993 14:52:45 PST Sender: Steve Deering From: Steve Deering Message-Id: <93Feb12.145259pst.12171@skylark.parc.xerox.com> Paul wrote: > Just out of curiosity, were other people thinking of my > provider-based example or Tony's provider-based example > when they thought of provider based addresses? My notion of provider-based addresses is the same as Paul's -- that they contain no geographical information at the levels above the individual subscriber or site. I have also worried about one of Tony's concerns with that model: I can imagine every little Mom & Pop provider demanding a top- level identifier, because they would all have ambitions of becoming mega- providers some day. And if each of those providers insists on getting enough address space in advance to grow to the size of a mega-provider, you would end up wasting a lot of address space, which matters little for CLNP, but is a significant concern for SIP. I really don't understand why Tony is advocating that the top level be continents. That does not yield enough aggregation to significantly reduce routing overhead (if you can't handle flat routing to all of the providers/metros/whatevers in the world, why do you think that you will be able handle routing to one sixth of them?). And where does this notion of a "continental authority" come from? Who is the continental authority for Asia? What continent is Tahiti in? Will the Cubans and the Americans achieve agreement on the North American Internet Numbering Plan? If you want a geographic top level, I suggest you use countries. That chops the world into about 200 pieces, which yields much more significant aggregation benefits; on the other hand, routing to 200 countries is not significantly more burdensome than routing to 6 continents. The notion of a national numbering authority seems a lot more sensible than a continental authority. Yes, countries are more volatile than continents, but there are a number of reasonable ways of dealing with country splits and joins. Paul again: > Anyway, I think it was Deering who suggested that the number > of metros in the world is small enough that metro could appear > at the top. Yes, I think we could put metro at the top, but I advocate using country as the top level. The argument that we could support metros at the top level is as follows: The projected world population for the year 2025 is 8.5 billion people. Using the rule-of-thumb of one metro for every one million people (a conservative rule -- most of the people in the world will be living in cities that are far larger than one million), there may be as many as 8500 metros, 30 years from now. We are currently doing flat routing to almost that number of IP networks. However, we can cluster the metro IDs by country without spending any more address bits (we'd need 14 bits to encode 8500 metros, but I have shown that we can also encode country + metro in 14 bits), and thus allow routing tables to be as small as 200 rather than 8500 (even though we *can* route to 8500, we might *prefer* to route to 200, for administrative reasons); those providers who want more precision for routing to particular metros can maintain individual routes for those metros, and longest-match route-lookup will do the right thing. > Making countries or continents or metro areas part of the hierarchy is > "artificial" hierarchy. It forces you to put interconnections where you > might otherwise not have done it. The idea behind metro-based addressing is to force providers to put interconections where they might otherwise not do so in order to make customers' lives easier and to foster competition in the provision of internet service (assuming that having to change addresses when changing providers is an impediment to competition). > Ultimately, it is a choice between renumbering to make the hierarchy > look like the topology, or rewiring to make the topology look > like the hierarchy. Nicely put. Although I would say "wiring" rather than "rewiring". Once the wires are in place, there will rarely be any need for rewiring for addressing/topological reasons, because the addressing hierarchy would not be changed. (An exception would be the partitioning of a metro, like another Berlin, where political forces prevent interconnection among the providers in the different partitions.) Tony wrote: > If North America decides that they want to allow for lots of growth, that > doesn't affect anyone except North America. If they blow it and have to > renumber, that STILL doesn't affect anyone other than North America. But the number of effected entities *within* North America would be enormous! I just don't buy into this idea that the wise leaders of North America will choose one kind of addressing hierarchy and the wise leaders of Europe will choose another. In fact, I'm also wary of leaving this decision in the hands of national or metropolitan "authorities". Let's architect an addressing plan that best serves the interests of the subscribers and, secondarily, the providers. Don't let the bureaucrats do anything more than hand out addresses according to the architected plan. > I disagree. For example, I immediately subdivide NorthAmerica into > states and provinces. [Not that this necessarily makes sense -- I can > be convinced otherwise.] I don't see the point in burning a level > just to separate the U.S. from Canada. I don't think anyone suggested *adding* a country level below the continental level -- the suggestion is to make country the top level *instead* of continent. And what's your definition of "continent" that has North America containing only two countries? Including the Caribbean and the mainland north of the Panama Canal, there are about 25 countries in North America. Paul wrote: > ...whereas with geographical addressing you've got to get the carriers > to interconnect properly from day one......(am I right about that? Is > there a way to avoid the interconnection? Perhaps by sending lots of > special case routing info around?) The alternative to interconnection of all providers within a geographical area is to tunnel or to leak next-level-down routes into the inter-area routing. However, with my metro-based scheme, those approaches wouldn't work very well at all as a long-term way of avoiding interconnection within a metro, because the next level down is site identifier, which means a potentially huge number of site routes would have to be exchanged over the tunnels or leaked into inter-metro routing. In the short-term (i.e., on day one, and for quite a few days after that), they should work fine, given that we currently do global, flat routing to all sites on the Internet. > Anyway, I'm tired of debating over the net. I think your idea > of a bof to discuss this is good. A BOF sounds like a good idea to me, if we can fit it into an already-too- full IETF agenda. > I would especially like to hear the IP provider's opinions on this..... > they will have to deal with it. And the subscribers, too! The providers' interests are not necessarily the same as the subscribers'. (Norr are the established providers' interests necessarily the same as the new, start-up providers', for that matter.) Steve From owner-Big-Internet@munnari.oz.au Sat Feb 13 13:23:54 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA08930; Sat, 13 Feb 1993 13:24:00 +1100 (from owner-Big-Internet) Return-Path: Received: from tengwar.itd.nrl.navy.mil by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08925; Sat, 13 Feb 1993 13:23:54 +1100 (from atkinson@tengwar.itd.nrl.navy.mil) Received: by tengwar.itd.nrl.navy.mil (16.8/16.2) id AA00699; Fri, 12 Feb 93 21:23:40 -0500 From: atkinson@tengwar.itd.nrl.navy.mil (Ran Atkinson) Message-Id: <9302122123.ZM697@tengwar.itd.nrl.navy.mil> Date: Fri, 12 Feb 1993 21:23:40 -0500 Organization: Naval Research Laboratory X-Mailer: Z-Mail (2.1.0 10/27/92) To: big-Internet@munnari.oz.au Subject: Re: metro addressing I can live with sacrificing current practice if really necessary for the good of the community. Since I'm _not_ a routing wizard, it would help me a whole lot if someone could explain these in simple terms on the list (I prefer to believe I'm not alone in my confusion :-). I'm having a really hard time with this notion that my organisation must adopt metro addressing within its private network if hosts inside that private network are to be externally visible. I must be really dense here. Can someone explain to me why a few select gateways (that are dual-homed on the private net in question and on the public net) could not just advertise the fact that they can handle traffic for that private network ? Thanks, Ran atkinson@itd.nrl.navy.mil From owner-big-internet@munnari.oz.au Sat Feb 13 17:22:57 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA14192; Sat, 13 Feb 1993 17:23:05 +1100 (from owner-big-internet) Return-Path: Received: from thumper.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20372; Fri, 12 Feb 1993 02:25:15 +1100 (from tsuchiya@thumper.bellcore.com) Received: from chiya.bellcore.com by thumper.bellcore.com (4.1/4.7) id for big-internet@munnari.oz.au; Thu, 11 Feb 93 10:24:46 EST Received: by chiya.bellcore.com (4.1/4.7) id for tsuchiya@thumper.bellcore.com; Thu, 11 Feb 93 10:24:46 EST Date: Thu, 11 Feb 93 10:24:46 EST From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Message-Id: <9302111524.AA29624@chiya.bellcore.com> To: tli@cisco.com, tsuchiya@thumper.bellcore.com Subject: Re: addressing Cc: big-internet@munnari.oz.au, deering@parc.xerox.com, kasten@ftp.com > > Well, it's clear to _me_. Assuming that you don't have giant > monopolistic providers, I would assume that they would continue to > grow at the rate the the rest of the internet does. 130%/year. So by > the end of 30 years, you're at 262,000 providers. I admit that this > is generous, but if it IS the case, you've just pushed the problem a > few more years. Can you _guarantee_ that this doesn't happen? Yes, I can guarantee it. I can decree that there will never be more than X things at the top, same as you. I guess in doing so I have a tougher legal battle to fight....perhaps similar to the legal battle of who gets radio spectrum.....but none the less it is a limit that can be impose (just as you propose putting a limit of "number of countries" or some such thing at the top) > soon? To me that means 15,000 providers that are worth advertising > at the top level.....some really localized small provider could be > placed at the next level of hierarchy down. > > Please stop changing the rules. In the pure provider-based scheme > that you were talking about, everyone gets top level, regardless of > size. In fact, I think that I'm going to become a provider (selling > service to my city block) so that I get a shorter prefix and can type > less. ;-) I'm not changing the rules, I'm just trying to set the rules..... It is very reasonable to not globally advertise a "provider" selling service to a single city block, or a few hotels in a city. A "provider" of that scale is basically "local access", and probably should not appear *anywhere* in the hierarchy....meaning that the providers "above" it (those that do appear globally) probably would rather individually keep track of everything under the local access provider than create a new level of hierarchy just for the local access provider......(or, put another way, the local access provider would rather pay for its provider to keep track of its insides rather than burden its customers with another layer of hierarchy......) Assuming that there is some cost to appearing at the top of the hierarchy, then selling service to a city block in order to appear at the top of the hierarchy might not make much business sense. I mean, say it costs $10,000 a year to appear at the top of the hierarchy. This is a modest sum for even a medium-sized carrier, but would put a one-city-block carrier out of business..... > > The fact that you would consider adding a hierarchy of providers into > this scheme already indicates that it has problems. I admit that adding levels of hierarchy at the top is not a good idea. That being said, I'm not willing to admit that it is impossible to do, or even terribly difficult. I'm designing Pip in such a way that a private network can easily change its prefix, and might do so several times a year. Since changing the top of the hierarchy means forcing an address change on everybody, it should be avoided, but still it could be done...... > > I'm not a business major, but I guess that normal industry shakedown > would prevent there from being much more than 15,000 significant > providers in the world..... > > How many phone companies are there in the world? How many 7-11's? The question is, how many phone companies are there in the world that should appear at the top of the hierarchy..... The fact is, we have to pick our poison here. And, to the extent that some "natural" level of the hierarchy won't scale, then we have to artificially introduce extra hierarchy. Making countries or continents or metro areas part of the hierarchy is "artificial" hierarchy. It forces you to put interconnections where you might otherwise not have done it. Arbitrarily deciding that only the top X providers appear at the top of the hierarchy is also artificial, but less so I think. Actually, this discussion is causing me to form a criteria for what justifies putting a provider at the top of the hierarchy. They go something like this: 1. As long as it doesn't cause a scaling problem, give all providers a top level number. A modest "rent" for the top-level number should be levied to discourage rampant mis-use. 2. To the extent that there is a scaling problem at the top, then limit the top to those providers that represent a meaningful policy choice for customers. To the extent that "local access providers" don't represent an interesting policy choice, they shouldn't appear at the top. In the phone company model, my local access carrier doesn't represent an interesting policy choice to me, because I have only one such carrier. What *is* interesting to me is the next layer up, AT&T vs. MCI vs. Sprint vs. etc..... Of course, you could still argue that I can't *guarantee* that even under this definition the top won't grow to be too big... But, unless you create a completely artificial hierarchy (that is, limit field size at every level, and *force* the topology to look like the hierarchy at all levels), then you also cannot guarantee that some part of your hierarchy won't grow too big. In other words, you can artificially constrain the top (continents, countries, metros, or whatever), but then you force the growth to occur at whatever level you haven't constrained. Ultimately, it is a choice between renumbering to make the hierarchy look like the topology, or rewiring to make the topology look like the hierarchy. Probably the truth lies somewhere in the middle, but I lean towards renumbering rather than rewiring, because I think it can be done pretty easily (I know Steve, you need proof.......) PX From owner-big-internet@munnari.oz.au Sat Feb 13 17:33:26 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA14403; Sat, 13 Feb 1993 17:33:33 +1100 (from owner-big-internet) Return-Path: Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17141; Thu, 11 Feb 1993 07:21:32 +1100 (from tli@cisco.com) Received: by lager.cisco.com; Wed, 10 Feb 1993 12:21:03 -0800 Date: Wed, 10 Feb 1993 12:21:03 -0800 From: Tony Li Message-Id: <199302102021.AA18174@lager.cisco.com> To: tsuchiya@thumper.bellcore.com Cc: tsuchiya@thumper.bellcore.com, big-internet@munnari.oz.au, deering@parc.xerox.com, kasten@ftp.com In-Reply-To: Paul Tsuchiya's message of Wed, 10 Feb 93 15:09:22 EST <9302102009.AA28590@chiya.bellcore.com> Subject: addressing > No! First, the addressing scheme has to be such that it's not an XOR > decision. You have to do both metro and provider-based addressing. > Exterior routing will not scale if it there is not topological > hierarchy above the metro area. But, all of your examples have metro at the top (at least, what I have come to understand as "metro"). !!!! Gee. And here I thought they were continents. ;-) [Background music: "It's a small world, after all..."] When I call an address provider-based, I don't think of: > NorthAmerica.California.SanFrancisco.BarrNet.[internal BarrNet addressing]. > cisco.[internal cisco address].tli-home Instead, I think of: BarrNet.[internal BarrNet addressing].cisco.[internal cisco address].tli-home I don't put any geographical information up front at all. But this clearly does NOT scale. Was someone advocating doing this? Just out of curiosity, were other people thinking of my provider-based example or Tony's provider-based example when they thought of provider based addresses? I am now of the opinion that this WHOLE discussion is just pure miscommunication. That we're all in violent agreement and that we'll make no progress on this until we set forth some very careful definitions. Tony From owner-big-internet@munnari.oz.au Sat Feb 13 17:50:25 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA14857; Sat, 13 Feb 1993 17:50:27 +1100 (from owner-big-internet) Return-Path: Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27784; Fri, 12 Feb 1993 08:02:20 +1100 (from tli@cisco.com) Received: by lager.cisco.com; Thu, 11 Feb 1993 13:01:31 -0800 Date: Thu, 11 Feb 1993 13:01:31 -0800 From: Tony Li Message-Id: <199302112101.AA17364@lager.cisco.com> To: avalon@coombs.anu.edu.au Cc: tsuchiya@thumper.bellcore.com, kasten@ftp.com, tli@cisco.com, big-internet@munnari.oz.au, deering@parc.xerox.com In-Reply-To: Darren Reed's message of Thu, 11 Feb 93 23:41:10 EST <9302111241.AA16325@coombs.anu.edu.au> Subject: addressing Someone else suggested that the top hierarchy be created as needed with addressing built from the bottom up. This makes a lot of sense and should be easily achievable using PIP. Why create a top you don't need ? You always need a top to get inter-domain routing and longest-match forwarding to work. By not fixing to either geographic or provider, it should be possible to build a network which has logical levels only which form the top, bottom or middle and to distribute routing information according to where you are. This should allow both to be incorporated. Exactly! If autoconfiguring of hosts is required, why not let routers anywhere in the routing tree autoconfigure to the position they are in when they boot ? Is it workable to have a router believe it is the top of the routing tree (however unbalanced it may be) ? Some sort of 'depth' discovery would be needed for each attached network. Being paranoid, I would have the router assume that it is NOT at the top. The number of these "seed" routers should be small enough to be manageable. Is it possible for TUBA/SIP to deal with these sorts of situations ? For Tuba, certainly. We just have to allocate a new AFI and do things properly. I won't speak to SIP. Tony From owner-big-internet@munnari.oz.au Sat Feb 13 18:11:19 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA27580; Sat, 13 Feb 1993 06:00:21 +1100 (from owner-big-internet) Return-Path: Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16281; Thu, 11 Feb 1993 06:39:33 +1100 (from tli@cisco.com) Received: by lager.cisco.com; Wed, 10 Feb 1993 11:39:06 -0800 Date: Wed, 10 Feb 1993 11:39:06 -0800 From: Tony Li Message-Id: <199302101939.AA15806@lager.cisco.com> To: tsuchiya@thumper.bellcore.com Cc: tsuchiya@thumper.bellcore.com, big-internet@munnari.oz.au, deering@parc.xerox.com, kasten@ftp.com In-Reply-To: Paul Tsuchiya's message of Wed, 10 Feb 93 14:07:55 EST <9302101907.AA28382@chiya.bellcore.com> Subject: addressing > I strongly disagree. The top of the hierarchy (above the metro area) > looks the same in either case. The only thing that would have to be > nailed down at this point is the top level. E.g.: *If* you are doing metro areas. If you doing provider, then metro areas (or continents, as somebody suggested and you copied below) don't come into it at all. If provider, then the provider is at the top....... No! First, the addressing scheme has to be such that it's not an XOR decision. You have to do both metro and provider-based addressing. Exterior routing will not scale if it there is not topological hierarchy above the metro area. Perhaps I'm not being clear. Let's try an example (with names, interpolate bytes as you like). Let's suppose that I live within the prefix NorthAmerica.California.SanFrancisco The SanFrancisco area may decide that it wants to go topological or metro. This decison is completely local. It is completely independent of what NorthAmerica.California.LosAngeles wants to do. Let's suppose that SanFrancisco decides to use metro addressing. It then decrees that the next N bytes of the address are completely flat and are the local code for the organization/entity in the metro area. My address ends up looking like: NorthAmerica.California.SanFrancisco.cisco.[internal cisco addressing].tli-home Note that it is wholly irrelevant HOW cisco is connected into SanFrancisco. You cannot tell if we use BarrNet or CERFnet as our service provider, so provider independence is preserved. [I won't even touch how you get BarrNet and CERFnet to interconnect.] The alternative is if SanFrancisco decides to be topological. [For a moment, let's igonre the fact that cisco is multi-homed.] Now my address looks like: NorthAmerica.California.SanFrancisco.BarrNet.[internal BarrNet addressing]. cisco.[internal cisco address].tli-home Note that this completely generalizes. ANY level in the hierarchy can decide if they want to be flat or topological. Do you view these continents as containing topological information or are they just topologically-superflous administrative assignments ala NSAPs? Continents must contain topological information if you want routing to scale. Note that the choice of "continents" is purely pragmatic. If you were to choose any roughly topological partitioning, it would probably do just as well. Tony From owner-big-internet@munnari.oz.au Sat Feb 13 18:12:03 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA01478; Sat, 13 Feb 1993 08:43:10 +1100 (from owner-big-internet) Return-Path: Received: from interlock.ans.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23934; Fri, 12 Feb 1993 04:58:42 +1100 (from dennis@ans.net) Received: by interlock.ans.net id AA20642 (InterLock SMTP Gateway 1.1 for big-internet@munnari.oz.au); Thu, 11 Feb 1993 12:56:41 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 11 Feb 1993 12:56:41 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 11 Feb 1993 12:56:41 -0500 From: Dennis Ferguson Message-Id: <199302111756.AA17263@foo.ans.net> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: deering@parc.xerox.com, big-internet@munnari.oz.au Subject: Re: EGP/IGP split (was Metro Addressing Summary) In-Reply-To: (Your message of Thu, 11 Feb 93 01:18:05 EST.) <9302110618.AA14180@ginger.lcs.mit.edu> Date: Thu, 11 Feb 93 12:56:44 -0500 Noel, This grows a bit tiresome. > your job is to compute an address-and-mask and associated next hop > for your forwarding table > > I assume you mean routing table here, yes? I mean the table which IP uses to look up a next hop for a destination when it is forwarding a packet. The "Forwarding Information Base" in ISOese (and BGPv4-ese, for that matter). As distinguished from the ISOese "Routing Information Base" (which I would call a "routing table"), which is where you store the raw routing information from your neighbours from which you compute your forwarding table. You say "illumination", I say "light", it is still the same thing. > This would suggest that, with ISIS certainly, level 1 areas are > explicitly *not* designed to be links between level 2 routers. > > Exactly. So? This was a design limitation of IS-IS. Of what relevance is it to > a discussion of the general limitations of MD routing? It is of no relevance to last night's hockey scores, either. So? I was discussing IS-IS and OSPF, the "general limitations of MD routing" is a topic I'm willing to leave to you. > ISIS supports the exact opposite, and permits virtual links between level 1 > routers through level 2 areas to heal level 1 partitions [...] > IP has no equivalent of the partition repair in IS-IS, since if a single > (sub)-network becomes partitioned (e.g. an Ethernet bridge fails), you break > one of the fundamental tents of IP routing, which is that all the addresses in > a (sub)- network are guarnteed to be fully interconnected. You are confused. There is nothing which constrains either IS-IS or OSPF level 1 areas to a single subnet. CLNP can route around subnet partitions, IP can't. Both could heal level 1 area partitions, though IP could never heal a partitioned subnet within the level 1 area (or the level 2 area, for that matter). > [...] You can do > just as much aggregation in a MD system as you can in DV. [...] > This also suggests that the relationship between OSPF level 1 and level > 2 areas is not strictly hierarchical. > > Look, there are two entirely different hierarchies, which you are confusing. > The first is an address abstraction hierarchy (instantiated in the > address/mask pair data), and the second is a topology representation hierarchy > (OSPF level 1 and 2). They are only loosely connected. For the first statement above to be true they had better be pretty tightly connected. > It seems to me that the routing resulting from either of these methods > would be equivalent > > Not necessarily. If the optimal path for traffic from S to D (both outside > area A) passes into A, back out, and *back in to A again*, then it might be > the case (depending on how the level 2 routing works) to have traffic take the > optimal path in the first case (what you later call 'LS'), but it will be > impossible in the second case ( what you later call 'DV'). Certainly, there's > enough information in the first case for the level 1 routers in A to do the > right thing, whereas there definitely isn't in the second. This defies reality. You are incorrect. OSPF uses the second method and can support routes like that just fine. If your level two routing is capable of computing routes in and out of level 1 areas like that (OSPF's is) your level 1 routing had better be capable of supporting them (OSPF's is). > Given all this, I challenge the use of 'DV' to describe the latter style of > incoming abstraction algorithm, since it brings along a mental image of a lot > of algorithmic baggage which simply doesn't imply. To you, maybe. To me it brings along a mental image of exactly what it does. You say "pork chop", I say "slice of dead pig". Different words, same thing. Big deal. > If you had carefully studied the message I sent out about how OSPF represents > level 1 topologies at level 2 From a careful study of the protocol it seems to me OSPF represents level 1 topologies at level 2 in the same way it represents level 2 topology at level 1. As distance-vectors (actually as type 3 LSA's, to be precise). So? > If you were the OSPF > designer, how would *you* have handled the problem of an automatic outgoing > abstraction algorithm? What would you have done? Probably exactly what the OSPF designer did. If the ability of a level 1 area to carry level 2 transit traffic at all is subject to configuration you might as well leave to configuration the use of those level 1 areas which you have configured to receive level 2 routing for transit traffic as well. Enough already. It may be I am just another one of those dumb engineers who do not understand the underlying mathematics of networks and who have been befuddled by the terminology associated with computer networks, but none of this of this strikes me as particularly profound. More like quibbling about whether to call it a rock or a stone. Perhaps someone else will understand the nuances better. Dennis Ferguson From owner-big-internet@munnari.oz.au Sat Feb 13 18:11:55 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA00175; Sat, 13 Feb 1993 07:52:14 +1100 (from owner-big-internet) Return-Path: Received: from thumper.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16908; Thu, 11 Feb 1993 07:10:42 +1100 (from tsuchiya@thumper.bellcore.com) Received: from chiya.bellcore.com by thumper.bellcore.com (4.1/4.7) id for big-internet@munnari.oz.au; Wed, 10 Feb 93 15:09:24 EST Received: by chiya.bellcore.com (4.1/4.7) id for tsuchiya@thumper.bellcore.com; Wed, 10 Feb 93 15:09:22 EST Date: Wed, 10 Feb 93 15:09:22 EST From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Message-Id: <9302102009.AA28590@chiya.bellcore.com> To: tli@cisco.com, tsuchiya@thumper.bellcore.com Subject: Re: addressing Cc: big-internet@munnari.oz.au, deering@parc.xerox.com, kasten@ftp.com > > *If* you are doing metro areas. If you doing provider, then metro > areas (or continents, as somebody suggested and you copied below) > don't come into it at all. If provider, then the provider is at > the top....... > > No! First, the addressing scheme has to be such that it's not an XOR > decision. You have to do both metro and provider-based addressing. > Exterior routing will not scale if it there is not topological > hierarchy above the metro area. But, all of your examples have metro at the top (at least, what I have come to understand as "metro"). When I call an address provider-based, I don't think of: > > NorthAmerica.California.SanFrancisco.BarrNet.[internal BarrNet addressing]. > cisco.[internal cisco address].tli-home > Instead, I think of: BarrNet.[internal BarrNet addressing].cisco.[internal cisco address].tli-home I don't put any geographical information up front at all. Just out of curiosity, were other people thinking of my provider-based example or Tony's provider-based example when they thought of provider based addresses? This is the kind of address that the Pip architecture proposes..... PX From owner-big-internet@munnari.oz.au Sat Feb 13 18:12:57 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA05127; Sat, 13 Feb 1993 11:07:27 +1100 (from owner-big-internet) Return-Path: Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28964; Fri, 12 Feb 1993 09:05:39 +1100 (from tli@cisco.com) Received: by lager.cisco.com; Thu, 11 Feb 1993 14:04:45 -0800 Date: Thu, 11 Feb 1993 14:04:45 -0800 From: Tony Li Message-Id: <199302112204.AA21726@lager.cisco.com> To: bsimpson@morningstar.com Cc: big-internet@munnari.oz.au, vaf@Stanford.EDU, tli@cisco.com, jyy@merit.edu, kannan@oar.net In-Reply-To: "William Allen Simpson"'s message of Thu, 11 Feb 93 13:08:24 EDT <925.bill.simpson@um.cc.umich.edu> Subject: the cidr draft Looked at the CIDR draft. Diffs from RFC 1338 don't show a lot of changes except the new Class A section. Yup. I was hoping for the actual allocation assignments. Neither yours nor ip-guidelines [RL] actually proposes numbers. Please see RFC 1366. I was also amused to note that in 1338 "all class B's will be exhausted within about 15 months". It has been 12 months, and it hasn't happened, as your new numbers attest. Presumably in your re-write you could take note of this, and offer some explanation in the change in allocation policy since that time. We have some experience by now. Noted. Could we get a statement as to the progress in changing the NSFnet backbone to classless? What about the regionals (three of whom are represented in the draft)? This is really a statement that should come from the BGP deployment group. However, I know of no deployed BGP4 implementations at this point. Two nits: - "rate of grown" -> "rate of growth". Thanks. Found and fixed two. - "As AS" -> "An AS" Huh? Tony From owner-big-internet@munnari.oz.au Sat Feb 13 18:49:27 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15762; Sat, 13 Feb 1993 18:49:29 +1100 (from owner-big-internet) Return-Path: Received: from thumper.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29316; Fri, 12 Feb 1993 09:16:08 +1100 (from tsuchiya@thumper.bellcore.com) Received: from chiya.bellcore.com by thumper.bellcore.com (4.1/4.7) id for big-internet@munnari.oz.au; Thu, 11 Feb 93 17:15:06 EST Received: by chiya.bellcore.com (4.1/4.7) id for tsuchiya@thumper.bellcore.com; Thu, 11 Feb 93 17:15:06 EST Date: Thu, 11 Feb 93 17:15:06 EST From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Message-Id: <9302112215.AA01115@chiya.bellcore.com> To: tli@cisco.com, tsuchiya@thumper.bellcore.com Subject: Re: addressing Cc: big-internet@munnari.oz.au, deering@parc.xerox.com, kasten@ftp.com > can be impose (just as you propose putting a limit of "number of countries" > or some such thing at the top) > > Number of continents. I don't believe that you can make this fly > politically. > Don't you think that continents is too small of a first level? There aren't that many countries, and you know the first thing you'll have to do is divide continents into countries, so why not make it countries at the top? As for flying politically, I think it will be easier to limit top level providers than to force various interconnections. In any event, you won't have to face the political problem of limiting provider numbers for a long time (I think never, but you disagree.....), whereas with geographical addressing you've got to get the carriers to interconnect properly from day one......(am I right about that? Is there a way to avoid the interconnection? Perhaps by sending lots of special case routing info around?) Anyway, I'm tired of debating over the net. I think your idea of a bof to discuss this is good. I would especially like to hear the IP provider's opinions on this.....they will have to deal with it. Is there an existing forum where discussion of this makes sense? If not, do people think creating a bof for this is a good idea? PX From owner-big-internet@munnari.oz.au Sat Feb 13 18:54:29 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15830; Sat, 13 Feb 1993 18:54:33 +1100 (from owner-big-internet) Return-Path: Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28618; Fri, 12 Feb 1993 08:50:28 +1100 (from tli@cisco.com) Received: by lager.cisco.com; Thu, 11 Feb 1993 13:49:57 -0800 Date: Thu, 11 Feb 1993 13:49:57 -0800 From: Tony Li Message-Id: <199302112149.AA20773@lager.cisco.com> To: tsuchiya@thumper.bellcore.com Cc: tsuchiya@thumper.bellcore.com, big-internet@munnari.oz.au, deering@parc.xerox.com, kasten@ftp.com In-Reply-To: Paul Tsuchiya's message of Thu, 11 Feb 93 10:24:46 EST <9302111524.AA29624@chiya.bellcore.com> Subject: addressing Yes, I can guarantee it. I can decree that there will never be more than X things at the top, same as you. I guess in doing so I have a tougher legal battle to fight....perhaps similar to the legal battle of who gets radio spectrum.....but none the less it is a limit that can be impose (just as you propose putting a limit of "number of countries" or some such thing at the top) Number of continents. I don't believe that you can make this fly politically. It is very reasonable to not globally advertise a "provider" selling service to a single city block, or a few hotels in a city. A "provider" of that scale is basically "local access", and probably should not appear *anywhere* in the hierarchy....meaning that the providers "above" it (those that do appear globally) probably would rather individually keep track of everything under the local access provider than create a new level of hierarchy just for the local access provider......(or, put another way, the local access provider would rather pay for its provider to keep track of its insides rather than burden its customers with another layer of hierarchy......) Agreed. So this isn't really true "providers at the top based" addressing. You actually are incorporating a hierarchy of providers. I don't see that customers get a "burden" by having another layer of hierachy. Is something else going on, or is this just a fear of having a longer prefix? The fact is, we have to pick our poison here. And, to the extent that some "natural" level of the hierarchy won't scale, then we have to artificially introduce extra hierarchy. Making countries or continents or metro areas part of the hierarchy is "artificial" hierarchy. It forces you to put interconnections where you might otherwise not have done it. True. But by delegating those decisions, we can delegate this task to the lower level. Further, we reduce the noise in the routing system by giving us a means of abstracting away from the "natural" noise that gets introduced. This is very important. Of course, you could still argue that I can't *guarantee* that even under this definition the top won't grow to be too big... Beat me to it. ;-) But, unless you create a completely artificial hierarchy (that is, limit field size at every level, and *force* the topology to look like the hierarchy at all levels), then you also cannot guarantee that some part of your hierarchy won't grow too big. In other words, you can artificially constrain the top (continents, countries, metros, or whatever), but then you force the growth to occur at whatever level you haven't constrained. Again, the only thing that gets constrained now is the top. The remainder is delegated. If North America decides that they want to allow for lots of growth, that doesn't affect anyone except North America. If they blow it and have to renumber, that STILL doesn't affect anyone other than North America. The difference is that there would be no case in which North America itself would change levels in the hierarchy. Ultimately, it is a choice between renumbering to make the hierarchy look like the topology, or rewiring to make the topology look like the hierarchy. Probably the truth lies somewhere in the middle, but I lean towards renumbering rather than rewiring, because I think it can be done pretty easily (I know Steve, you need proof.......) I don't disagree that renumbering is easier than rewiring. I have no objections to this approach at the lower levels of addressing. Tony From owner-big-internet@munnari.oz.au Sat Feb 13 18:59:51 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15920; Sat, 13 Feb 1993 18:59:53 +1100 (from owner-big-internet) Return-Path: Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29617; Fri, 12 Feb 1993 09:29:49 +1100 (from tli@cisco.com) Received: by lager.cisco.com; Thu, 11 Feb 1993 14:29:19 -0800 Date: Thu, 11 Feb 1993 14:29:19 -0800 From: Tony Li Message-Id: <199302112229.AA23339@lager.cisco.com> To: tsuchiya@thumper.bellcore.com Cc: tsuchiya@thumper.bellcore.com, big-internet@munnari.oz.au, deering@parc.xerox.com, kasten@ftp.com In-Reply-To: Paul Tsuchiya's message of Thu, 11 Feb 93 17:15:06 EST <9302112215.AA01115@chiya.bellcore.com> Subject: addressing Don't you think that continents is too small of a first level? No. But I'm not trying to squeeze the bits out of the address either. ;-) If I was, I would probably try to retain continents, but limit the number of bits for the top level. There aren't that many countries, and you know the first thing you'll have to do is divide continents into countries, so why not make it countries at the top? I disagree. For example, I immediately subdivide NorthAmerica into states and provinces. [Not that this necessarily makes sense -- I can be convinced otherwise.] I don't see the point in burning a level just to separate the U.S. from Canada. As for flying politically, I think it will be easier to limit top level providers than to force various interconnections. In any event, you won't have to face the political problem of limiting provider numbers for a long time (I think never, but you disagree.....), whereas with geographical addressing you've got to get the carriers to interconnect properly from day one......(am I right about that? Is there a way to avoid the interconnection? Perhaps by sending lots of special case routing info around?) Woah. It need not be geographical. Yes, you can avoid interconnection. You can also model the addressing to match the existing topology. In any case, it becomes a local decision and we avoid the fight. Any of the below are possible (but not all are good ideas!): NorthAmerica.Barrnet.[local Barrnet].cisco.[local cisco].tli NorthAmerica.WestCoast.cisco.[local cisco].tli NorthAmerica.ANSnet.[local ANSnet].Barrnet.[local Barrnet].cisco.[local cisco].tli NorthAmerica.US.WestCoast.California.North.BayArea.SanFrancisco .MenloPark.cisco.[local cisco].tli NorthAmerica.tli NorthAmerica.cisco.tli NorthAmerica.computers.cisco.tli NorthAmerica.computers.dcom.sys.cisco.tli The point is that it is now North America's choice and that Europe can do things completely differently. If one continent blows it, no one else gets hurt. I think that this eliminates the political debate and still retains the essential scaling properties that we need so that it works technically. Anyway, I'm tired of debating over the net. I think your idea of a bof to discuss this is good. I would especially like to hear the IP provider's opinions on this.....they will have to deal with it. Agreed. Is there an existing forum where discussion of this makes sense? If not, do people think creating a bof for this is a good idea? BOF! Are you volunteering? ;-) Tony From owner-big-internet@munnari.oz.au Sat Feb 13 19:02:09 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15953; Sat, 13 Feb 1993 19:02:11 +1100 (from owner-big-internet) Return-Path: Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23763; Thu, 11 Feb 1993 12:00:27 +1100 (from martillo@nero.clearpoint.com) Received: from nero.clearpoint.com by mulga.cs.mu.OZ.AU with SMTP (5.64+1.3.1+0.50); id AA27076 Thu, 11 Feb 1993 11:59:51 +1100 (from martillo@nero.clearpoint.com) Received: by nero.clearpoint.com (4.1/1.34) id AA20570; Wed, 10 Feb 93 19:49:25 EST Date: Wed, 10 Feb 93 19:49:25 EST From: martillo@nero.clearpoint.com (Joachim Carlo Santos Martillo Ajami) Message-Id: <9302110049.AA20570@nero.clearpoint.com> To: yakov@watson.ibm.com Cc: Christian.Huitema@sophia.inria.fr, big-internet@munnari.oz.au In-Reply-To: yakov@watson.ibm.com's message of Wed, 3 Feb 93 14:00:13 EST <9302031853.AA04693@nero.clearpoint.com> Subject: Metro Addressing Summary From: yakov@watson.ibm.com To: martillo@nero.clearpoint.com, Christian.Huitema@sophia.inria.fr, big-internet@munnari.oz.au Subject: Metro Addressing Summary Ref: Your note of Wed, 3 Feb 93 13:07:13 EST >Is this supposed to be a general principle ? Certainly, one can >build very complex physical network topologies with IEEE P802.1d >MAC bridging, yet the physical addresses used in a given network >are arbitrary. Building complex topologies is certainly one of the issues. However, there is another thing to consider -- building LARGE topologies. So, the question to ask is how well IEEE P802.1d MAC bridging is suitable for building LARGE topologies. Yakov. Hi Yakov, Granted, STP bridging suffers limitations in the building of networks with very large diameters. A different path selection procedure might support larger diameters but I would suggest that the problem of building very LARGE networks is made more tractable by first building comms subnets of big diameters (which could actually be IBM SR-bridged token rings) using first order packet switches (bridges) and then connecting these comms subnets in a large network topology using second order packet switches (routers). I have no doubt that building very LARGE topologies is possible using purely 2nd order packet switching technology but the approach may be needlessly complex. I also have no doubt that building very LARGE topologies is possible using purely first order packet switching technology but that approach is needlessly complex. Using the mixed first and second order packet switching probably simplifies the approach and in the case of IBM products actually makes fairly effective use of the logical subbridge architecture which -- I believe -- the 6611 supports. The observation of the benefits of the mixed approach is fundamental to the architecture of very large networks and is relatively independent of the nature (DV vs LS vs BROADCAST etc.) of the first order and second order routing protocols. Interestingly enough the mixed first/2nd order approach simplifies configuration and eliminates, obviates or reduces the problems associated with multiprotocol internetworks as described by Nick Lippis in "Too Many Protocols Can Break the Corporate Backbone" in Data Communications, February 1993, p. 27 and as described by Kelly Jackson Higgins in "When Nets Collide: Multiple protocols have created a world of multiple managers, multiple transmissions, multiple addresses and multiple headaches" in Communications Week, February 8, 1993, p.35. Joachim Carlo Santos Martillo Ajami The article represents noone's opinions other than the author's. From owner-Big-Internet@munnari.oz.au Sat Feb 13 20:17:52 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA16972; Sat, 13 Feb 1993 20:17:57 +1100 (from owner-Big-Internet) Return-Path: Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16969; Sat, 13 Feb 1993 20:17:52 +1100 (from tli@cisco.com) Received: by lager.cisco.com; Sat, 13 Feb 1993 01:17:38 -0800 Date: Sat, 13 Feb 1993 01:17:38 -0800 From: Tony Li Message-Id: <199302130917.AA08896@lager.cisco.com> To: bill.simpson@um.cc.umich.edu ("William Allen Simpson") Cc: big-internet@munnari.oz.au Subject: ARP versus ES-IS Could all you ARP fans tell me what's bad about ES-IS? Overhead. Could all you ES-IS fans tell me what's bad about ARP? No router discovery. No black hole detection. Real fun when mixed-media bridging gets involved. No autoconfiguration. What would we do in a perfect world? an imperfect world? No media addresses inside of packets. Router discovery/blackhole detection/failover protocol/default router. Automatic address assignment. Media level redirects. Optimal route query. Shaken, not stirred. Tony From owner-big-internet@munnari.oz.au Sat Feb 13 20:28:48 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17229; Sat, 13 Feb 1993 20:28:51 +1100 (from owner-big-internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04176; Thu, 11 Feb 1993 17:18:44 +1100 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA14180; Thu, 11 Feb 93 01:18:05 -0500 Date: Thu, 11 Feb 93 01:18:05 -0500 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9302110618.AA14180@ginger.lcs.mit.edu> To: deering@parc.xerox.com, dennis@ans.net Subject: Re: EGP/IGP split (was Metro Addressing Summary) Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu LS routing provides you with exactly as much detail about the most distant part of the topology it is computing routes for as it does about your immediate neighbours at that level Your terminology here is a little ambiguous; I take it you don't mean that a K-level router has information about *all* K level topological information in the system, but rather just the K-1 level elements in the local K level area? your job is to compute an address-and-mask and associated next hop for your forwarding table I assume you mean routing table here, yes? The forwarding table is often taken to mean the cached per-destination information used to speed up the typical commercial router. Some people also use the forwarding table to mean the place where flow information is stored, in the new flow-network architectures. (I will spare everyone the usual flame about how routing tables are obsolescent.) You can aggregate when moving information up and down through a hierarchical set of LS-routed topologies, but you can't aggregate within any particular level of the topology. You can aggregate the topology, but you can't aggregate within the link-state routing running over your (possibly aggregated) topology. I'm not sure I understand which of several possible subtly different meanings for this statement you meant, but I don't agree with any of them. You can do just as much aggregation in a MD system as you can in DV. ---> For any aggregatable object, there is a boundary within which that object is not aggregated. Within that boundary, the routing computes route to each sub-piece individually. This is true whether you are using DV or MD routing. <--- Aggregation as a process has much the same characteristics whether the computation of routes is done using MD or DV technology. This would suggest that, with ISIS certainly, level 1 areas are explicitly *not* designed to be links between level 2 routers. Exactly. So? This was a design limitation of IS-IS. Of what relevance is it to a discussion of the general limitations of MD routing? ISIS supports the exact opposite, and permits virtual links between level 1 routers through level 2 areas to heal level 1 partitions You need to be careful about equating level 1 in OSPF and IS-IS (and level 2 likewise). They are not the functionally equivalent at all. Level 1 in IS-IS tracks individual destination which cannot be aggregated at all; they are only aggregated by virtue of being assigned to a single level 1 area. Thus, an IS-IS level 1 area acts much more like an IP (sub)-network (i.e. a range of IP addresses defined by a mask, which are guaranteed to be fully interconnected). IP has no equivalent of the partition repair in IS-IS, since if a single (sub)-network becomes partitioned (e.g. an Ethernet bridge fails), you break one of the fundamental tents of IP routing, which is that all the addresses in a (sub)- network are guarnteed to be fully interconnected. Yes, not a good assumption for a real system, but there it is. Level 2 in IS-IS tracks collections of these things, and is thus roughly equivalent to OSPF level 1 in effective functionality. Given the radically different effective functionality, it's not surprising that they made different decisions in important areas. This also suggests that the relationship between OSPF level 1 and level 2 areas is not strictly hierarchical. Look, there are two entirely different hierarchies, which you are confusing. The first is an address abstraction hierarchy (instantiated in the address/mask pair data), and the second is a topology representation hierarchy (OSPF level 1 and 2). They are only loosely connected. It seems to me that the routing resulting from either of these methods would be equivalent Not necessarily. If the optimal path for traffic from S to D (both outside area A) passes into A, back out, and *back in to A again*, then it might be the case (depending on how the level 2 routing works) to have traffic take the optimal path in the first case (what you later call 'LS'), but it will be impossible in the second case ( what you later call 'DV'). Certainly, there's enough information in the first case for the level 1 routers in A to do the right thing, whereas there definitely isn't in the second. I would call the first method above "link-state" inter-area routing, and the second "distance-vector". ... The fact is that OSPF uses the second method for propagating inter-area routing information. It seems to me that calling OSPF inter-area routing "distance-vector" is quite accurate. I agree that there are two distinct poles (not classes, as we shall see) of propogating higher level routing information into lower layers, for purposes of supporting transit traffic, and I understand the derivation of your names. However, I don't agree that this is the only way (or even the *best* way) to think of them. I suggest that an *equally* valid way to view the OSPF operational mode is to, once again, see it as a really simplistic abstraction technique. The question is "how to represent the external topology to routers inside an area". One possibility is to give them the full external topology. This is what you are called "link state mode". The other is a simplistic model where each border router represents itself as being directly connected (with appropriate metrics to each external destination). However, it's obvious when you look at it this way that these are merely the endpoints of a continuum, and there are a large number of options in the middle; it is (once again) a question of the algorithm used to create the abstraction. In a previous message, I talked about how OSPF represents level 1 areas to the level 2; this is a simple case of what the routing theory part of Nimrod calls 'outgoing' abstraction algorithms. What we now discuss (how level 2 is represented to level 1) is what Nimrod calls 'incoming' abstraction algorithms. Given all this, I challenge the use of 'DV' to describe the latter style of incoming abstraction algorithm, since it brings along a mental image of a lot of algorithmic baggage which simply doesn't imply. There is no distributed computation involving shipping of complete partial results around, which to me is the soul of DV. In addition, while I have no doubt that a link state routing protocol which used level one topologies as the links to move traffic between level 2 routers could be developed, I think you're on thinner ice to assert that ... OSPF, is such a protocol. ... ISIS level 1 areas are explicitly precluded from ever carrying transit traffic between level 2 routers, while OSPF does this only as a hand-configured exception rather than the normal way of doing things. If you had carefully studied the message I sent out about how OSPF represents level 1 topologies at level 2, and why, you would understand why OSPF does it the way it does, as hand-configured virtual links. If you were the OSPF designer, how would *you* have handled the problem of an automatic outgoing abstraction algorithm? What would you have done? Noel From owner-big-internet@munnari.oz.au Sat Feb 13 20:34:04 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17263; Sat, 13 Feb 1993 20:34:06 +1100 (from owner-big-internet) Return-Path: Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14703; Sat, 13 Feb 1993 17:44:47 +1100 (from tli@cisco.com) Received: by lager.cisco.com; Fri, 12 Feb 1993 22:43:58 -0800 Date: Fri, 12 Feb 1993 22:43:58 -0800 From: Tony Li Message-Id: <199302130643.AA05077@lager.cisco.com> To: deering@parc.xerox.com Cc: big-internet@munnari.oz.au, tsuchiya@thumper.bellcore.com, tli@cisco.com, deering@parc.xerox.com In-Reply-To: Steve Deering's message of Fri, 12 Feb 1993 14:52:45 PST <93Feb12.145259pst.12171@skylark.parc.xerox.com> Subject: addressing I really don't understand why Tony is advocating that the top level be continents. That does not yield enough aggregation to significantly reduce routing overhead (if you can't handle flat routing to all of the providers/metros/whatevers in the world, why do you think that you will be able handle routing to one sixth of them?). I can't handle routing to all of the whatevers of the world when the number of top level whatevers is subject to change. Whatever we do, the top level will fill up. I'm trying to achieve a fixed, O(1 byte), top level. And where does this notion of a "continental authority" come from? From CIDR, where we have regional authorities for doing address allocation. In many cases, this is turning into a continental authority anyhow. Who is the continental authority for Asia? What continent is Tahiti in? Will the Cubans and the Americans achieve agreement on the North American Internet Numbering Plan? If I volunteer to be the continental authority for Asia, do I get to live in Tahiti? And develop a case for Cuban cigars? ;-) Seriously, I don't know and in some sense it doesn't make any difference. If you want a geographic top level, I suggest you use countries. That chops the world into about 200 pieces, which yields much more significant aggregation benefits; on the other hand, routing to 200 countries is not significantly more burdensome than routing to 6 continents. The notion of a national numbering authority seems a lot more sensible than a continental authority. Yes, countries are more volatile than continents, but there are a number of reasonable ways of dealing with country splits and joins. On the down side, this leads us down the path of political address assignment. Not something that I either intend, endorse, or like. Political boundaries have little to do with topology. The argument that we could support metros at the top level is as follows: The projected world population for the year 2025 is 8.5 billion people. Using the rule-of-thumb of one metro for every one million people (a conservative rule -- most of the people in the world will be living in cities that are far larger than one million), there may be as many as 8500 metros, 30 years from now. We are currently doing flat routing to almost that number of IP networks. Just because we're doing it now does NOT mean that it's a good thing. This is WAY too many routes for a baseline. Please remember that _whatever_ addressing plan we come up with, the noise in the system will certainly magnify this number. Add TOS routes and the mind boggles again. Nicely put. Although I would say "wiring" rather than "rewiring". Once the wires are in place, there will rarely be any need for rewiring for addressing/topological reasons, because the addressing hierarchy would not be changed. (An exception would be the partitioning of a metro, like another Berlin, where political forces prevent interconnection among the providers in the different partitions.) I should point out that all of these cases do NOT require "wiring". You treat them as a partitioned entity and use know techniques for healing them. This is ugly and no fun, but it will make sense in some circumstances. Regardless of the top level. > If North America decides that they want to allow for lots of growth, that > doesn't affect anyone except North America. If they blow it and have to > renumber, that STILL doesn't affect anyone other than North America. But the number of effected entities *within* North America would be enormous! More motivation to do it right? I just don't buy into this idea that the wise leaders of North America will choose one kind of addressing hierarchy and the wise leaders of Europe will choose another. North America and Europe are bad examples because both have "dense" (vigourous handwave) connectivity. Look at the case of North America and South America. Within South (and Central) America at present, there seems to be very little interconnectivity. As far as I can tell, almost all sites are stubs off of US regionals. But that's only for today. In fact, I'm also wary of leaving this decision in the hands of national or metropolitan "authorities". Let's architect an addressing plan that best serves the interests of the subscribers and, secondarily, the providers. Architecting say, South America, into metro addressing today will really hurt them. As they grow, and transit into "dense" interconnectivity, they would end up completely changing their "metro" addressing. Ugh. Don't let the bureaucrats do anything more than hand out addresses according to the architected plan. Who said _anything_ about bureaucrats? I don't think anyone suggested *adding* a country level below the continental level -- the suggestion is to make country the top level *instead* of continent. And what's your definition of "continent" that has North America containing only two countries? Including the Caribbean and the mainland north of the Panama Canal, there are about 25 countries in North America. Draw the lines where you like. I'm not picky. Where does Central America belong? I dunno. Flip a coin. Split it in two. I'm easy. The alternative to interconnection of all providers within a geographical area is to tunnel or to leak next-level-down routes into the inter-area routing. Yup. This is the healing technique. However, with my metro-based scheme, those approaches wouldn't work very well at all as a long-term way of avoiding interconnection within a metro, because the next level down is site identifier, which means a potentially huge number of site routes would have to be exchanged over the tunnels or leaked into inter-metro routing. In the short-term (i.e., on day one, and for quite a few days after that), they should work fine, given that we currently do global, flat routing to all sites on the Internet. Well, we're gonna need those techniques at some level somewhere, so I think we better pick some way of making them work. This would really argue for there being a tall, skinny hierarchy (i.e., the arity of the tree is a single digit integer). > I would especially like to hear the IP provider's opinions on this..... > they will have to deal with it. And the subscribers, too! The providers' interests are not necessarily the same as the subscribers'. (Norr are the established providers' interests necessarily the same as the new, start-up providers', for that matter.) I know of no way of getting a consistent broad-spectrum set of opinions from the subscribers. Shall we hold a set of Internet-wide hearings? It doesn't work for the PUC; I bet it works just as badly for us. ;-) ;-) Tony From owner-big-internet@munnari.oz.au Sat Feb 13 20:52:53 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17538; Sat, 13 Feb 1993 20:52:57 +1100 (from owner-big-internet) Return-Path: Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01645; Fri, 12 Feb 1993 10:48:10 +1100 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <11559>; Thu, 11 Feb 1993 15:45:53 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Thu, 11 Feb 1993 15:45:44 -0800 To: atkinson@tengwar.itd.nrl.navy.mil (Ran Atkinson) Cc: big-internet@munnari.oz.au, deering@parc.xerox.com Subject: Re: Metro Addressing In-Reply-To: Your message of "Mon, 08 Feb 93 19:00:28 PST." <9302082200.ZM650@tengwar.itd.nrl.navy.mil> Date: Thu, 11 Feb 1993 15:45:29 PST Sender: Steve Deering From: Steve Deering Message-Id: <93Feb11.154544pst.12171@skylark.parc.xerox.com> > Perhaps some obvious principles are worth mentioning (I don't think > these are controversial or reflect any particular wisdom on my part) : > > 1) new addressing/routing schemes must not preclude current practices > or be less flexible than current practices. Ran, the problem is that some current practices don't scale. *If* it turns out that the only affordable way to allow the Internet to continue to grow is to preclude those practices, which would you choose to sacrifice: Internet growth or those practices? > 4) While metro addressing makes sense for the public (commercial ?) parts > of the Internet, use of metro addressing must not be forced on others > who don't choose to use it in their own networks. You are welcome to do whatever you want in the privacy of your own network. But if you want your hosts to be reachable from the public network, you may have to make some compromises. (Note that I said *may*, not *will*.) Steve From owner-big-internet@munnari.oz.au Sat Feb 13 20:59:25 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17583; Sat, 13 Feb 1993 20:59:26 +1100 (from owner-big-internet) Return-Path: Received: from coombs.anu.edu.au by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03548; Fri, 12 Feb 1993 12:24:54 +1100 (from avalon@coombs.anu.edu.au) Received: by coombs.anu.edu.au (5.61/1.0) id AA27015; Fri, 12 Feb 93 12:20:32 +1100 From: avalon@coombs.anu.edu.au (Darren Reed) Message-Id: <9302120120.AA27015@coombs.anu.edu.au> Subject: Re: addressing To: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Date: Fri, 12 Feb 93 12:20:31 EST Cc: big-internet@munnari.oz.au In-Reply-To: <9302111535.AA29664@chiya.bellcore.com>; from "Paul Tsuchiya" at Feb 11, 93 10:35 am Reply-To: avalon@coombs.anu.edu.au X-Mailer: ELM [version 2.3 PL11] In some email I received from Paul Tsuchiya, Sie wrote: > > > > > Someone else suggested that the top hierarchy be created as needed with > > addressing built from the bottom up. This makes a lot of sense and > > should be easily achievable using PIP. Why create a top you don't need ? > > Or one that will need replacing ? It should also be possible to build > > down as well as up.. > > I know that Chiappa has argued for bottom up numbering.... > > Pip numbers levels from the top down. I struggled for some > time with bottom-up, but couldn't make it work. In the end, > I found that you have no choice but to define a top level, even > if you leave the bottom open and flexible. You sure ? Pip looks to be able handling bottom-up through use of the RD in which you only put in as much routing information as required. What are the problems with an open top ? > (Actually, kampai is a bottom-up address "number assignment" scheme, > but even that scheme doesn't let you avoid deciding what each level > of the hierarchy "represents", ie, a provider or a region..... It shouldn't matter what each level represents. A level is a level and they should all be the same. The only difference is in what we see making them up. It would be better left to routing protocols (ie RIP/EGP/BGP style protocols) to make distinctions between levels. Darren. From owner-big-internet@munnari.oz.au Sat Feb 13 21:12:17 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17747; Sat, 13 Feb 1993 21:12:18 +1100 (from owner-big-internet) Return-Path: Received: from thumper.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05961; Fri, 12 Feb 1993 14:21:41 +1100 (from tsuchiya@thumper.bellcore.com) Received: from chiya.bellcore.com by thumper.bellcore.com (4.1/4.7) id for avalon@coombs.anu.edu.au; Thu, 11 Feb 93 21:58:57 EST Received: by chiya.bellcore.com (4.1/4.7) id for tsuchiya@thumper.bellcore.com; Thu, 11 Feb 93 21:58:55 EST Date: Thu, 11 Feb 93 21:58:55 EST From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Message-Id: <9302120258.AA01376@chiya.bellcore.com> To: avalon@coombs.anu.edu.au, tsuchiya@thumper.bellcore.com Subject: Re: addressing Cc: big-internet@munnari.oz.au > > > > Pip numbers levels from the top down. I struggled for some > > time with bottom-up, but couldn't make it work. In the end, > > I found that you have no choice but to define a top level, even > > if you leave the bottom open and flexible. > > You sure ? Pip looks to be able handling bottom-up through use of the > RD in which you only put in as much routing information as required. > What are the problems with an open top ? It is true, Pip does not have to put all levels in the routing directive, but the Routing Context has to state what level of the hierarchy is being acted on, so that the routers know the context for forwarding. With traditional addresses, the address is parsed left-to-right (top-down) until a single forwarding entry is isolated.....they determine the level by looking from the top down. Semantically Pip is no different, but to keep the routers from having to look at the whole address, Pip has to state the level--and the only way I've found to do this is to count levels from the top down..... > > > (Actually, kampai is a bottom-up address "number assignment" scheme, > > but even that scheme doesn't let you avoid deciding what each level > > of the hierarchy "represents", ie, a provider or a region..... > > It shouldn't matter what each level represents. A level is a level and > they should all be the same. The only difference is in what we see making > them up. It would be better left to routing protocols (ie RIP/EGP/BGP > style protocols) to make distinctions between levels. > Right. In the routing protocol and the forwarding engine, it doesn't matter. They will advertise what people tell them to advertise. But the people have to decide what to tell them.....(I'm sure I'm not being clear, but I hope this helps.......) PX From owner-big-internet@munnari.oz.au Sat Feb 13 21:14:49 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17765; Sat, 13 Feb 1993 21:14:51 +1100 (from owner-big-internet) Return-Path: Received: from tengwar.itd.nrl.navy.mil by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03949; Fri, 12 Feb 1993 12:41:04 +1100 (from atkinson@tengwar.itd.nrl.navy.mil) Received: by tengwar.itd.nrl.navy.mil (16.8/16.2) id AA04054; Thu, 11 Feb 93 21:25:14 -0500 From: atkinson@tengwar.itd.nrl.navy.mil (Ran Atkinson) Message-Id: <9302112125.ZM4052@tengwar.itd.nrl.navy.mil> Date: Thu, 11 Feb 1993 21:25:14 -0500 In-Reply-To: Steve Deering "Re: Metro Addressing" (Feb 11, 15:45) References: <93Feb11.154544pst.12171@skylark.parc.xerox.com> Organization: Naval Research Laboratory X-Mailer: Z-Mail (2.1.0 10/27/92) To: big-internet@munnari.oz.au Subject: Re: Metro Addressing I can live with sacrificing current practice if really necessary for the good of the community. Since I'm _not_ a routing wizard, it would help me a whole lot if someone could explain these in simple terms on the list (I prefer to believe I'm not alone in my confusion :-). I'm having a really hard time with this notion that my organisation must adopt metro addressing within its private network if hosts inside that private network are to be externally visible. I must be really dense here. Can someone explain to me why a few select gateways (that are dual-homed on the private net in question and on the public net) could not just advertise the fact that they can handle traffic for that private network ? Thanks, Ran atkinson@itd.nrl.navy.mil From owner-big-internet@munnari.oz.au Sat Feb 13 21:37:50 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA18242; Sat, 13 Feb 1993 21:37:56 +1100 (from owner-big-internet) Return-Path: Received: from thumper.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05990; Fri, 12 Feb 1993 14:23:57 +1100 (from tsuchiya@thumper.bellcore.com) Received: from chiya.bellcore.com by thumper.bellcore.com (4.1/4.7) id for big-internet@munnari.oz.au; Thu, 11 Feb 93 22:02:39 EST Received: by chiya.bellcore.com (4.1/4.7) id for tsuchiya@thumper.bellcore.com; Thu, 11 Feb 93 22:00:29 EST Date: Thu, 11 Feb 93 22:00:29 EST From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Message-Id: <9302120300.AA01393@chiya.bellcore.com> To: tli@cisco.com, tsuchiya@thumper.bellcore.com Subject: Re: addressing Cc: big-internet@munnari.oz.au, deering@parc.xerox.com, kasten@ftp.com > > Is there an existing forum where discussion of this makes sense? > If not, do people think creating a bof for this is a good idea? > > BOF! Are you volunteering? ;-) > I'll run it if you'll write up the report..... PX From owner-Big-Internet@munnari.oz.au Sat Feb 13 22:51:54 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA19742; Sat, 13 Feb 1993 22:52:00 +1100 (from owner-Big-Internet) Return-Path: Received: from coombs.anu.edu.au by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19739; Sat, 13 Feb 1993 22:51:54 +1100 (from avalon@coombs.anu.edu.au) Received: by coombs.anu.edu.au (5.61/1.0) id AA10138; Sat, 13 Feb 93 22:52:03 +1100 From: avalon@coombs.anu.edu.au (Darren Reed) Message-Id: <9302131152.AA10138@coombs.anu.edu.au> Subject: Relative Addressing To: big-internet@munnari.oz.au Date: Sat, 13 Feb 93 22:52:01 EST Reply-To: avalon@coombs.anu.edu.au X-Mailer: ELM [version 2.3 PL11] Is there any reason why everyone wants to use complete, absolute addresses in packets and not a nice relative address ? How often do you use your absolute mail address when sending email ? For email, you can get away with "joe@cray" or "joe@cray.cs" and surface mail is similar (you don't need to put in the country or state if you send your neighbour mail). (What do I mean by 'relative address' ? An address which is essentially the route to take to reach the endpoint, similar to those used by PIP in the RD and RH fields). I've been trying to work out how to do this on paper but its not nearly as easy as I had first imagined :( Is anyone else working on this or done any papers on this field ? Many people have asked on this list why not do it that way but I've yet to see anyone argue against it. Considering everyone is saying IPv7 must scale and be useable for the next 20 years at least, wouldn't a protocol that took advantage of relative addressing be preferable to something like IPv4 where you need the full address in each packet ? Darren From owner-Big-Internet@munnari.oz.au Sat Feb 13 22:54:43 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA19763; Sat, 13 Feb 1993 22:54:52 +1100 (from owner-Big-Internet) Return-Path: Message-Id: <9302131154.19763@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19760; Sat, 13 Feb 1993 22:54:43 +1100 (from J.Crowcroft@cs.ucl.ac.uk) Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Sat, 13 Feb 1993 11:54:27 +0000 To: lillie@comm.mot.com Cc: big-internet@munnari.oz.au, mobile-ip@parc.xerox.com Subject: Re: Mobility and Routing (was Metro Addressing) In-Reply-To: Your message of "Thu, 11 Feb 93 10:32:47 CST." <9302111632.AA15130@anchor.comm.mot.com> Date: Sat, 13 Feb 93 11:54:25 +0000 From: Jon Crowcroft >Where does this rambling lead us? Typical land-mobile (i.e. users >driving around in their cars) can exhibit average handoff rates on the >order of 10-20 seconds/handoff/mobile, in an urban environment. this is assuming the computer user is a human - the DRIVE program in europe is considering mobile computing to mainly consist of vehicle management computers commuicating between vehicles and with traffic management and guidance centers...in which case you get a whole lot more than cell hand off rates are engineered for... jon From owner-Big-Internet@munnari.oz.au Sat Feb 13 22:58:28 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA19817; Sat, 13 Feb 1993 22:58:43 +1100 (from owner-Big-Internet) Return-Path: Message-Id: <9302131158.19817@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19814; Sat, 13 Feb 1993 22:58:28 +1100 (from J.Crowcroft@cs.ucl.ac.uk) Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Sat, 13 Feb 1993 11:57:50 +0000 To: Tony Li Cc: big-internet@munnari.oz.au Subject: Re: addressing In-Reply-To: Your message of "Wed, 10 Feb 93 10:47:05 PST." <199302101847.AA13137@lager.cisco.com> Date: Sat, 13 Feb 93 11:57:48 +0000 From: Jon Crowcroft >protocol does otherwise, please generalize). The first byte will >indicate the continent: > 0 Europe > 1 Asia > 2 Africa > 3 Antartica/Australia > 4 South America this just shows why this approach may be flawed - the centers for GIXes already under real world planning discussion have the "pacific rim", not an asian, and a antarctic/austrlia - you've gotta consider centers of population/resources more than this... >Remaining values of the first byte can be used for space exploration. >;-) not a joke - ESA will probably have IP connectivity to newer space vehicles (at least i ndesigns i've seen...) jon From owner-Big-Internet@munnari.oz.au Sat Feb 13 23:43:33 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA20848; Sat, 13 Feb 1993 23:43:59 +1100 (from owner-Big-Internet) Return-Path: Received: from nero.clearpoint.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20812; Sat, 13 Feb 1993 23:43:33 +1100 (from martillo@nero.clearpoint.com) Received: by nero.clearpoint.com (4.1/1.34) id AA00657; Sat, 13 Feb 93 07:35:06 EST Date: Sat, 13 Feb 93 07:35:06 EST From: martillo@nero.clearpoint.com (Joachim Carlo Santos Martillo Ajami) Message-Id: <9302131235.AA00657@nero.clearpoint.com> To: tli@cisco.com Cc: bill.simpson@um.cc.umich.edu, big-internet@munnari.oz.au, martillo@nero.clearpoint.com In-Reply-To: Tony Li's message of Sat, 13 Feb 1993 01:17:38 -0800 <199302130917.AA08896@lager.cisco.com> Subject: ARP versus ES-IS Date: Sat, 13 Feb 1993 01:17:38 -0800 From: Tony Li To: bill.simpson@um.cc.umich.edu ("William Allen Simpson") Cc: big-internet@munnari.oz.au Subject: ARP versus ES-IS Could all you ARP fans tell me what's bad about ES-IS? Overhead. Could all you ES-IS fans tell me what's bad about ARP? No router discovery. No black hole detection. Real fun when mixed-media bridging gets involved. No autoconfiguration. I guess if you don't like ARP, I suppose you could just send IP packets whose IP address was not resolved to the MAC broadcast address, keep some maximum number of such packets outstanding to a given destination IP address within some time period and learn mac addresses from incoming IP packets. Routers would be automatically discovered. What would we do in a perfect world? an imperfect world? No media addresses inside of packets. Router discovery/blackhole detection/failover protocol/default router. Automatic address assignment. Media level redirects. Optimal route query. Shaken, not stirred. Tony Joachim Carlo Santos Martillo Ajami The article represents noone's opinions other than the author's. From owner-Big-Internet@munnari.oz.au Sun Feb 14 02:18:53 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA24354; Sun, 14 Feb 1993 02:19:02 +1100 (from owner-Big-Internet) Return-Path: Received: from tengwar.itd.nrl.navy.mil by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24346; Sun, 14 Feb 1993 02:18:53 +1100 (from atkinson@tengwar.itd.nrl.navy.mil) Received: by tengwar.itd.nrl.navy.mil (16.8/16.2) id AA00830; Sat, 13 Feb 93 10:18:45 -0500 From: atkinson@tengwar.itd.nrl.navy.mil (Ran Atkinson) Message-Id: <9302131018.ZM828@tengwar.itd.nrl.navy.mil> Date: Sat, 13 Feb 1993 10:18:45 -0500 In-Reply-To: Tony Li "Re: metro addressing" (Feb 13, 1:31) References: <199302130931.AA09332@lager.cisco.com> Organization: Naval Research Laboratory X-Mailer: Z-Mail (2.1.0 10/27/92) To: Tony Li Subject: Re: metro addressing Cc: big-Internet@munnari.oz.au (This is using NRL as an example, feel free to substitute GE or IBM or another large organisation in your own head :-). NRL is located in Mississippi, California, DC, Maryland, and West Virginia. I want to continue to have a single private network for all of NRL (something like PRIVATE-NET.USN.NRL.*) and advertise routing gateways into that private net at several places. So the gateway dual-homed host might be FOO.DC.USN-GW and also PRIVATE-NET.USN.DC-GW, where FOO is whatever the top-level metro hook is. Hosts internal to NRL should only need *1* address and it should be of the form PRIVATE-NET.USN.NRL.hostname. That address would be usable by folks outside unchanged (i.e. their router observes that a nearby metro-addressed dual-homed gateway is advertising routes into PRIVATE-NET.USN.*) and the internal hosts would be fully accessible to the outside but NEED NOT have a metro address in addition to their private network address. Do I understand that this will still work with metro-based addressing or am I still confused ? Ran atkinson@itd.nrl.navy.mil P.S. If you use continents at the top-level, you will want to split Asia into East Asia, South Asia, and West Asia at least. The continents vary widely in size and population and the top level pieces should, IMHO, be roughly equal in scale. Otherwise the top-level for Asia will require a lot more powerful systems than anyone else needs. P.P.S. I also think that country-based addressing is not wise because the boundaries of countries have never been, are not now, and are not likely to be stable. Go from continent down to locality and avoid political quagmires.. From owner-Big-Internet@munnari.oz.au Sun Feb 14 05:00:34 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA27539; Sun, 14 Feb 1993 05:00:44 +1100 (from owner-Big-Internet) Return-Path: Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27535; Sun, 14 Feb 1993 05:00:34 +1100 (from dcrocker@Mordor.Stanford.EDU) Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA25929; Sat, 13 Feb 93 10:00:27 -0800 Message-Id: <9302131800.AA25929@Mordor.Stanford.EDU> To: Tony Li Cc: big-internet@munnari.oz.au Subject: Re: addressing Org: The Branch Office, Sunnyvale CA Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Thu, 11 Feb 93 14:29:19 -0800. <199302112229.AA23339@lager.cisco.com> Date: Sat, 13 Feb 93 10:00:27 -0800 From: Dave Crocker X-Mts: smtp Tony (and Paul), ---- Included message: From: Tony Li There aren't that many countries, and you know the first thing you'll have to do is divide continents into countries, so why not make it countries at the top? I disagree. For example, I immediately subdivide NorthAmerica into states and provinces. [Not that this necessarily makes sense -- I can The recent round of international boundary upheavals has made us all leary of using country boundaries, but my own feeling is that the political, adminstrative, and psychological import of national boundaries is so large that we are forced into their use. Given a rich addressing space, continent probably would be pleasant to put ahead, but I agree with Steve Deering that having country first, which creates a top-level space of a "few" hundred entries, isn't onerous. The aggregation of continent might be pleasant, but I don't find it compelling. Similarly, the next level down (province, state, etc.) exposing too much detail to be appropriate for the top of the global geographic listing. be convinced otherwise.] I don't see the point in burning a level just to separate the U.S. from Canada. I tend to suspect that Canadians would disagree with you. (Less frivolously, I'll note that trans-border data flow is still a very major issue and serves as just one of the reasons that keeping aware of national boundaries is quite useful.) Anyway, I'm tired of debating over the net. I think your idea of a bof to discuss this is good. I would especially like to hear the IP provider's opinions on this.....they will have to deal with it. Agreed. Is there an existing forum where discussion of this makes sense? If not, do people think creating a bof for this is a good idea? BOF! Are you volunteering? ;-) Months ago, I hoped that we could split the addressing discussion separate from the protocol debates. It looks like there is now a enough of a base of interest to do that. Key question is who will set up a mailing list? Might be too late to get a BOF at Columbus, but I'll check. Dave From owner-Big-Internet@munnari.oz.au Sun Feb 14 05:15:51 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA27743; Sun, 14 Feb 1993 05:16:03 +1100 (from owner-Big-Internet) Return-Path: Received: from sadye.emba.uvm.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27740; Sun, 14 Feb 1993 05:15:51 +1100 (from Garrett.Wollman@UVM.EDU) Received: by sadye.emba.uvm.edu id AA03448 (5.65/6.02); Sat, 13 Feb 93 13:15:42 -0500 Date: Sat, 13 Feb 93 13:15:42 -0500 From: Garrett.Wollman@UVM.EDU Message-Id: <9302131815.AA03448@sadye.emba.uvm.edu> To: big-internet@munnari.oz.au Subject: Re: addressing In-Reply-To: <9302120258.AA01376@chiya.bellcore.com> References: <9302120258.AA01376@chiya.bellcore.com> (I hope I can convince SuperCite to cite both of these messages at the same time...) < It is true, Pip does not have to put all levels in the routing directive, > but the Routing Context has to state what level of the hierarchy is > being acted on, so that the routers know the context for forwarding. So why not number from the bottom up? It's what I was thinking of when I did my NAP-based addressing scheme... > Semantically Pip is no different, > but to keep the routers from having to look at the whole address, Pip > has to state the level--and the only way I've found to do this is > to count levels from the top down..... I think that you can avoid doing this in two ways. The first way is simply to encode the information into the FTIF. The router can reserve a few FTIF values for itself, so that when it sees (up), it knows that this packet is destined for a ``higher'' level. The NAP-based plan only cares about *relative* levels, rather than absolute ones (indeed, I think I said explicitly that absolute levels don't make sense in my model; see section 2). The second way is to number the levels from the bottom up, and require that the tree below any router be balanced, either naturally, or by force (i.e., modifying the HD or RC to indicate a higher level than is actually the case). I prefer the second option. Here's how it would work... Consider a topology that looks something like this: /---------------ucs-gw====UCS hosts uvm-gw----------------emba-gw===EMBA hosts \---------------med-gw====Med School hosts \----------colch-gw====Colchester hosts The height of this tree is three, so we can say for sure that uvm-gw is at level 3, and colch-gw is at level 1. We have three choices here: we can either tell colch-gw to forcibly map all the packets it passes up to med-gw back to level 1 (normally they would be level 2); we can tell med-gw to do the same for packets coming in on that interface; or we can tell med-gw, emba-gw, and ucs-gw that they should forcibly map all the packets coming in on their local interfaces to level 2, even though the hosts think of them as being on level 1. This is not really very significant on our small network... For a large regional network, levels could simply be arbitrarily defined, so that (for example) all customer interfaces are defined to be at level 16. This wastes a bit of the ``level space'', but allows the customers to make their internal network have as many as 15 internal levels before they get to the provider's network. It may be necessary to break some of the topology influence in the internal provider addresses; for example, part of my address might not be (down)(down)(down) but instead something more like (down) By having all NEARnet's customers be represented simply as (none) the level-shifting would be unnecessary. This is probably what would have to be done anyway, so that customers didn't get stuck with 50-byte addresses (and who said NSAPs were too long...). < (What do I mean by 'relative address' ? An address which is essentially > the route to take to reach the endpoint, similar to those used by PIP > in the RD and RH fields). > I've been trying to work out how to do this on paper but its not nearly > as easy as I had first imagined :( Is anyone else working on this or > done any papers on this field ? See my I-D draft-wollman-nap-based-01.txt. This describes how I would represent such addresses, and where I would get them from. -GAWollman -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@emba.uvm.edu | Shashish is the bonding of hearts in spite of distance. uvm-gen!wollman | It is a bond more powerful than absence. We like people UVM disagrees. | who like Shashish. - Claude McKenzie + Florent Vollant From owner-Big-Internet@munnari.oz.au Sun Feb 14 05:22:49 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA27868; Sun, 14 Feb 1993 05:23:15 +1100 (from owner-Big-Internet) Return-Path: Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27838; Sun, 14 Feb 1993 05:22:49 +1100 (from dcrocker@Mordor.Stanford.EDU) Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA26436; Sat, 13 Feb 93 10:22:10 -0800 Message-Id: <9302131822.AA26436@Mordor.Stanford.EDU> To: avalon@coombs.anu.edu.au Cc: big-internet@munnari.oz.au Subject: Re: Relative Addressing Org: The Branch Office, Sunnyvale CA Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Sat, 13 Feb 93 22:52:01 -0500. <9302131152.AA10138@coombs.anu.edu.au> Date: Sat, 13 Feb 93 10:22:10 -0800 From: Dave Crocker X-Mts: smtp Darren, Don't know about anyone else, but you certainly pressed one of MY hot buttons. ---- Included message: Is there any reason why everyone wants to use complete, absolute addresses in packets and not a nice relative address ? How often do you use your absolute mail address when sending email ? For email, Always. You, the user, might not type it, but internet email is required to carry the full internet domain name for your machine. I even maintain that this should be true WITHIN a domain, since I've been bitten too many times by local conventions that collide with global references. The key reason for wanting globally unique, absolute addresses, is that debugging & management are massively easier. The Security folks seem particularly strong on this point. Dave From owner-Big-Internet@munnari.oz.au Sun Feb 14 07:08:06 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA29131; Sun, 14 Feb 1993 07:08:21 +1100 (from owner-Big-Internet) Return-Path: Received: from Sun.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29127; Sun, 14 Feb 1993 07:08:06 +1100 (from Bob.Hinden@Eng.Sun.COM) Received: from Eng.Sun.COM (zigzag-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA28922; Sat, 13 Feb 93 12:08:00 PST Received: from bigriver.Eng.Sun.COM (bigriver-248) by Eng.Sun.COM (4.1/SMI-4.1) id AA05161; Sat, 13 Feb 93 12:12:15 PST Received: by bigriver.Eng.Sun.COM (4.1/SMI-4.1) id AA21926; Sat, 13 Feb 93 12:07:58 PST Date: Sat, 13 Feb 93 12:07:58 PST From: Bob.Hinden@Eng.Sun.COM (Bob Hinden) Message-Id: <9302132007.AA21926@bigriver.Eng.Sun.COM> To: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Cc: big-internet@munnari.oz.au In-Reply-To: <9302112215.AA01115@chiya.bellcore.com> Subject: Re: addressing Content-Length: 284 Paul, I think a BOF is an excellent idea as long as it has some specific goals as to what it intends to accomplish. Perhaps something like a comparison of two specific addressing proposals (provider vs. metro). That would, of course, require the proposals to be written down. Bob From owner-Big-Internet@munnari.oz.au Sun Feb 14 07:30:12 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA29386; Sun, 14 Feb 1993 07:30:22 +1100 (from owner-Big-Internet) Return-Path: Received: from is.rice.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29378; Sun, 14 Feb 1993 07:30:12 +1100 (from bmanning@is.rice.edu) Received: by is.rice.edu (AA02628); Sat, 13 Feb 93 14:29:55 CST From: bmanning@is.rice.edu (William Manning) Message-Id: <9302132029.AA02628@is.rice.edu> Subject: Re: the cidr draft To: tli@cisco.com (Tony Li) Date: Sat, 13 Feb 93 14:29:54 CST Cc: bsimpson@morningstar.com, big-internet@munnari.oz.au, vaf@stanford.edu, tli@cisco.com, jyy@merit.edu, kannan@oar.net In-Reply-To: <199302112204.AA21726@lager.cisco.com>; from "Tony Li" at Feb 11, 93 2:04 pm X-Mailer: ELM [version 2.3 PL11] Tony Li > > Could we get a statement as to the progress in changing the NSFnet > backbone to classless? What about the regionals (three of whom are > represented in the draft)? > > This is really a statement that should come from the BGP deployment > group. However, I know of no deployed BGP4 implementations at this > point. > Neither do I. Something to do with getting vendor support. :) However, regionals can move to classless IGPs, (OSPF, ISISd) using code from a number of different providers. This might be the gist of the question. At the last regional techs meeting, only two regionals indicated that they were running an IGP that could run classless. Several others are moving that way even as we speak. -- Regards, Bill Manning bmanning@rice.edu PO Box 1892 713-285-5415 713-527-6099 Houston, Texas R.U. (o-kome) 77251-1892 From owner-Big-Internet@munnari.oz.au Sun Feb 14 11:05:34 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03663; Sun, 14 Feb 1993 11:05:48 +1100 (from owner-Big-Internet) Return-Path: Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03656; Sun, 14 Feb 1993 11:05:34 +1100 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <11940>; Sat, 13 Feb 1993 16:05:16 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Sat, 13 Feb 1993 16:05:08 -0800 To: atkinson@tengwar.itd.nrl.navy.mil (Ran Atkinson) Cc: big-internet@munnari.oz.au, deering@parc.xerox.com Subject: Re: metro addressing In-Reply-To: Your message of "Fri, 12 Feb 93 18:23:40 PST." <9302122123.ZM697@tengwar.itd.nrl.navy.mil> Date: Sat, 13 Feb 1993 16:04:53 PST Sender: Steve Deering From: Steve Deering Message-Id: <93Feb13.160508pst.12171@skylark.parc.xerox.com> > Can someone explain to me why a few select gateways (that are > dual-homed on the private net in question and on the public net) could > not just advertise the fact that they can handle traffic for that > private network ? The concern is that, if every multi-homed organization or household (i.e., every organization/household attached to more than one provider, under a provider-based plan, or to more than one metro, under a metro-based plan) gets to be advertised to the public internet as an individual entity, then the routing cost to the public internet will be too high. In other words, it wouldn't scale. Under a provider-based plan, what you are suggesting is equivalent to treating every multi-homed organization or household as a distinct provider (even as a top-level provider, if the organization's attachments are to sufficiently-distant parts of the public topology). Under a metro-based plan, it is equivalent to treating every multi-homed organization as a distinct metro area (even as a distinct country/continent, if the organization's attachments are in different countries/continents). Some have suggested that, if an organization wants to be advertised as an individual entity in the public Internet, then the organization should be able to pay the public providers for that privilege (i.e., reimburse them for the extra cost of maintaining an individual route to the organization). That doesn't seem very workable to me. If the price of such a service were to have a reasonable relationship to its real costs, it would result in multi-homed organizations directly or indirectly paying a few pennies to each of tens, hundreds, or thousands of providers. Of course, the price would likely be much higher than the cost of the service, because it would have to cover the much higher costs of collecting the fees! Can you explain to me why it's so important to you that all of your organization's hosts have the same address prefix, or that they only have one address prefix each? I can imagine some reasons, but I would like to hear yours. Steve From owner-Big-Internet@munnari.oz.au Sun Feb 14 12:32:42 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA05212; Sun, 14 Feb 1993 12:33:14 +1100 (from owner-Big-Internet) Return-Path: Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05194; Sun, 14 Feb 1993 12:32:42 +1100 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <11944>; Sat, 13 Feb 1993 17:32:22 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Sat, 13 Feb 1993 17:32:13 -0800 To: Tony Li Cc: big-internet@munnari.oz.au, deering@parc.xerox.com Subject: Re: addressing In-Reply-To: Your message of "Fri, 12 Feb 93 22:43:58 PST." <199302130643.AA05077@lager.cisco.com> Date: Sat, 13 Feb 1993 17:32:11 PST Sender: Steve Deering From: Steve Deering Message-Id: <93Feb13.173213pst.12171@skylark.parc.xerox.com> Tony, > On the down side [of having country be the top level of the hierarchy], > this leads us down the path of political address assignment. Not something > that I either intend, endorse, or like. Yes, I acknowledge that problem. I hope that the task of the national authorites could be well-enough prescribed and circumscribed to minimize the hazards. (By the way, what I have in mind as an appropriate national "authority" is something like a national chapter of the ISOC, not something like ANSI or a PTT. Probably naive of me, I know.) > Political boundaries have little to do with topology. Neither do continental boundaries, as your example of South American connectivity shows. However, I think that as Internet service becomes ubiquitous, aggregation by country will work quite well, from a quality-of- routing perspective. For geographically-large countries that are nearby, you may well want to keep finer-grain routes (e.g., U.S. wide-area routers would likely keep per-metro routes for Canadian metros, rather than just a single route for Canada), but that's easily done. > Just because we're [routing to almost 8500 destinations] now does NOT mean > that it's a good thing. This is WAY too many routes for a baseline. Yes. That's why I advocate putting countries at the top level. I was describing a *feasible* approach, not necessarily a *good* approach. (We seem to be having trouble communicating, but I don't know if the problem is at the sender or the receiver.) > I should point out that all of these cases do NOT require "wiring". > You treat them as a partitioned entity and use know techniques for > healing them. Yes, yes, yes. I'm usually careful to qualify every statement I make about connectivity requirements of hierarchical addressing schemes with some mention of partition healing, but one of the few times I omit the qualification, you jump on it. (In fact, I did mention it later on in my message.) For the sake of brevity, let's just take it as assumed from now on, OK? > Architecting say, South America, into metro addressing today will > really hurt them. As they grow, and transit into "dense" > interconnectivity, they would end up completely changing their "metro" > addressing. Ugh. What?? If they were to assign addresses according to a metro plan today, they would *not* have to renumber in the future. While there are a small number of sites, they can use partition-healing techniques to make up for lack of wires; as density increases, wires will be added to reduce routing overheads and improve delivery paths. If I understand you, you would advocate that South Americans use a different addressing plan than what would be appropriate in the "dense" continents. Then, when the number of Internet susbcribers in South America get dense enough that they need an addressing plan like that of North America or Europe, you would have them undergo a massive renumbering. Wouldn't it be better to adopt the right long-term plan from the beginning? > Well, we're gonna need [partition healing] techniques at some level > somewhere, so I think we better pick some way of making them work. This > would really argue for there being a tall, skinny hierarchy (i.e., the > arity of the tree is a single digit integer). If you can do painless renumbering, you may be right. If renumbering is not painless, a short, broad hierarchy is preferrable, because it enables much more reconfiguration of the topology to occur without requiring address changes. Short, broad hierarchies also enable more efficient use of the address space, which some of us consider important. Steve From owner-Big-Internet@munnari.oz.au Sun Feb 14 13:26:53 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA06107; Sun, 14 Feb 1993 13:27:00 +1100 (from owner-Big-Internet) Return-Path: Received: from itd.nrl.navy.mil by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06096; Sun, 14 Feb 1993 13:26:53 +1100 (from atkinson@itd.nrl.navy.mil) Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA05692; Sat, 13 Feb 93 21:26:47 EST Date: Sat, 13 Feb 93 21:26:47 EST From: atkinson@itd.nrl.navy.mil (Ran Atkinson) Message-Id: <9302140226.AA05692@itd.nrl.navy.mil> To: big-Internet@munnari.oz.au Subject: Re: Metro addressing Steve, It isn't that I think that "every multi-homed organisation" should have the ability to have its own non-metro addresses, but rather that those organisations which really do already have very large private networks (e.g. DoD, GE, IBM, DEC, Xerox, others) should be able to continue to have about the same capability. For example, I think the IP networks run by DISA are far larger than those run by ANS or UUNET or any other commercial provider. I am not talking about organisations that aren't multi-homed or about organisations which are smaller than "very large". Both of those cases would use the metro-based addressing. Under the provider-based addressing, such organisations should be considered providers (based on size of existing networks relative to the size of existing commercial provider networks). There are several reasons that organisations currently use large private networks. In the case of GE, there was a desire to strictly control access to the communications assets of the firm and a desire to be able to install firewalls between GE and the rest of the world. For example, when I was at GE-Fanuc (a 50/50 joint venture), we disconnected from the GE net whenever we connected to Fanuc and vice versa. GE had no major losses to the Internet worm in part because the reachability of hosts on its internal network was strictly controlled by firewalls and other special systems. While I might argue that the better technical solution would be to address the security of the Internet more effectively, I am enough of a realist to consider that Internet security and implementations of that will be in the forefront any time soon and so I want to be sure that we don't drive these large organisations away from the Internet without giving their particular concerns full thought. I will go along with the consensus, but I want to be sure that all have thoroughly pondered these real-world issues along the way. :-) Regards, Ran atkinson@itd.nrl.navy.mil From owner-Big-Internet@munnari.oz.au Sun Feb 14 15:56:59 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA10760; Sun, 14 Feb 1993 15:57:11 +1100 (from owner-Big-Internet) Return-Path: Received: from thumper.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10749; Sun, 14 Feb 1993 15:56:59 +1100 (from tsuchiya@thumper.bellcore.com) Received: from chiya.bellcore.com by thumper.bellcore.com (4.1/4.7) id for big-internet@munnari.oz.au; Sat, 13 Feb 93 23:56:45 EST Received: by chiya.bellcore.com (4.1/4.7) id for tsuchiya@thumper.bellcore.com; Sat, 13 Feb 93 23:56:44 EST Date: Sat, 13 Feb 93 23:56:44 EST From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Message-Id: <9302140456.AA03943@chiya.bellcore.com> To: avalon@coombs.anu.edu.au, jnc@ginger.lcs.mit.edu, tsuchiya@thumper.bellcore.com Subject: Re: addressing Cc: big-internet@munnari.oz.au, deering@parc.xerox.com > > I struggled for some time with bottom-up, but couldn't make it work. > In the end, I found that you have no choice but to define a top level > > Why? Bottom-up seems to have worked reasonably well in the phone system as it > grew. I mean, they didn't have country codes all figured out when they started > depoying phones in 1900 or whenever. As you as you know in what context an > address is to be interpreted, does it matter than contexts can nest > indefinitely upward? > I have a feeling that we are talking apples and oranges...... I'm not saying that with top-down numbering you couldn't add a level at the top.....but you need to renumber the levels......or in the case of traditional left-to-right addresses, you'd need to renumber everything...... PX From owner-Big-Internet@munnari.oz.au Sun Feb 14 16:04:26 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA10949; Sun, 14 Feb 1993 16:04:36 +1100 (from owner-Big-Internet) Return-Path: Received: from thumper.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10946; Sun, 14 Feb 1993 16:04:26 +1100 (from tsuchiya@thumper.bellcore.com) Received: from chiya.bellcore.com by thumper.bellcore.com (4.1/4.7) id for big-internet@munnari.oz.au; Sun, 14 Feb 93 00:04:13 EST Received: by chiya.bellcore.com (4.1/4.7) id for tsuchiya@thumper.bellcore.com; Sun, 14 Feb 93 00:04:12 EST Date: Sun, 14 Feb 93 00:04:12 EST From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Message-Id: <9302140504.AA03961@chiya.bellcore.com> To: big-internet@munnari.oz.au, deering@parc.xerox.com Subject: Re: addressing Cc: tli@cisco.com, tsuchiya@thumper.bellcore.com > > My notion of provider-based addresses is the same as Paul's -- that they > contain no geographical information at the levels above the individual > subscriber or site. I have also worried about one of Tony's concerns with > that model: I can imagine every little Mom & Pop provider demanding a top- > level identifier, because they would all have ambitions of becoming mega- > providers some day. And if each of those providers insists on getting > enough address space in advance to grow to the size of a mega-provider, > you would end up wasting a lot of address space, which matters little > for CLNP, but is a significant concern for SIP. > It also matters little for Pip, but for different reasons that why it doesn't matter for CNLP...... As for Mom&Pop providers......Pip allows the "address" advertised by DNS to contain a route fragment....so, even if an M&P provider got its own top-level number, it wouldn't necessarily get advertised globally...... For instance, the DNS address returned for some host could be.... MCI(none).M&P(down).subscriber(down).area(down).host The "down" and "none" things indicate being above or not above the next thing in the hierarchy (address numbering-wise). So, even though M&P has a top level number, it doesn't get advertised world-wide.....MCI does, and then MCI knows how to route to M&P........ This makes sense from a policy route perspective too. If M&P really is just a local access provider, then the subscriber probably connects only to M&P, but can be billed by MCI etc (just like the USA phone model), and so would like the ability to choose...... PX From owner-Big-Internet@munnari.oz.au Sun Feb 14 16:06:28 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA10967; Sun, 14 Feb 1993 16:06:35 +1100 (from owner-Big-Internet) Return-Path: Received: from thumper.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10964; Sun, 14 Feb 1993 16:06:28 +1100 (from tsuchiya@thumper.bellcore.com) Received: from chiya.bellcore.com by thumper.bellcore.com (4.1/4.7) id for big-internet@munnari.oz.au; Sun, 14 Feb 93 00:06:22 EST Received: by chiya.bellcore.com (4.1/4.7) id for tsuchiya@thumper.bellcore.com; Sun, 14 Feb 93 00:06:21 EST Date: Sun, 14 Feb 93 00:06:21 EST From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Message-Id: <9302140506.AA03978@chiya.bellcore.com> To: Bob.Hinden@Eng.Sun.COM, tsuchiya@thumper.bellcore.com Subject: Re: addressing Cc: big-internet@munnari.oz.au > > Paul, > > I think a BOF is an excellent idea as long as it has some specific goals > as to what it intends to accomplish. Perhaps something like a comparison > of two specific addressing proposals (provider vs. metro). That would, > of course, require the proposals to be written down. > Well, I still offer to run the BOF if somebody else offers to take minutes and write them up...... Of course, I'll need to have the provider-based scheme written up just for Pip, so no extra work there...... PX From owner-Big-Internet@munnari.oz.au Sun Feb 14 16:20:36 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA11236; Sun, 14 Feb 1993 16:20:48 +1100 (from owner-Big-Internet) Return-Path: Received: from thumper.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11233; Sun, 14 Feb 1993 16:20:36 +1100 (from tsuchiya@thumper.bellcore.com) Received: from chiya.bellcore.com by thumper.bellcore.com (4.1/4.7) id for big-internet@munnari.oz.au; Sun, 14 Feb 93 00:20:29 EST Received: by chiya.bellcore.com (4.1/4.7) id for big-internet@munnari.oz.au; Sun, 14 Feb 93 00:20:28 EST Date: Sun, 14 Feb 93 00:20:28 EST From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Message-Id: <9302140520.AA04042@chiya.bellcore.com> To: Garrett.Wollman@UVM.EDU, big-internet@munnari.oz.au Subject: Re: addressing > levels don't make sense in my model; see section 2). The second way > is to number the levels from the bottom up, and require that the tree > below any router be balanced, either naturally, or by force (i.e., > modifying the HD or RC to indicate a higher level than is actually the > case). > I see what you're doing...... I hadn't thought of this. It requires that hosts know how levels are numbered above them, right? This may not be so bad...... I'll think about it.... PX From owner-Big-Internet@munnari.oz.au Sun Feb 14 16:25:25 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA11347; Sun, 14 Feb 1993 16:25:39 +1100 (from owner-Big-Internet) Return-Path: Received: from thumper.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11341; Sun, 14 Feb 1993 16:25:25 +1100 (from tsuchiya@thumper.bellcore.com) Received: from chiya.bellcore.com by thumper.bellcore.com (4.1/4.7) id for big-internet@munnari.oz.au; Sun, 14 Feb 93 00:25:13 EST Received: by chiya.bellcore.com (4.1/4.7) id for deering@parc.xerox.com; Sun, 14 Feb 93 00:25:11 EST Date: Sun, 14 Feb 93 00:25:11 EST From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Message-Id: <9302140525.AA04050@chiya.bellcore.com> To: big-internet@munnari.oz.au, deering@parc.xerox.com Subject: Re: metro addressing > > When the phone companies introduce personal, portable, owned-for-life phone > numbers, do you think they will route on them? > By the way, I read an article that AT&T will now sell you a personal phone number (700 "area" code). Apparently the use of it isn't completely smooth sailing, it may not work depending on where the person trying to reach you is or something like that (I don't remember the details.....) PX From owner-Big-Internet@munnari.oz.au Sun Feb 14 19:31:48 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15365; Sun, 14 Feb 1993 19:32:05 +1100 (from owner-Big-Internet) Return-Path: Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15362; Sun, 14 Feb 1993 19:31:48 +1100 (from tli@cisco.com) Received: by lager.cisco.com; Sun, 14 Feb 1993 00:31:29 -0800 Date: Sun, 14 Feb 1993 00:31:29 -0800 From: Tony Li Message-Id: <199302140831.AA11511@lager.cisco.com> To: martillo@nero.clearpoint.com Cc: bill.simpson@um.cc.umich.edu, big-internet@munnari.oz.au, martillo@nero.clearpoint.com In-Reply-To: Joachim Carlo Santos Martillo Ajami's message of Sat, 13 Feb 93 07:35:06 EST <9302131235.AA00657@nero.clearpoint.com> Subject: ARP versus ES-IS Could all you ES-IS fans tell me what's bad about ARP? No router discovery. No black hole detection. Real fun when mixed-media bridging gets involved. No autoconfiguration. I guess if you don't like ARP, I suppose you could just send IP packets whose IP address was not resolved to the MAC broadcast address, keep some maximum number of such packets outstanding to a given destination IP address within some time period and learn mac addresses from incoming IP packets. Routers would be automatically discovered. This fails in the case of a multihomed host with asymmetric routes. And the overhead is not inconsequential. Tony From owner-big-internet@munnari.oz.au Sun Feb 14 19:45:29 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15626; Sun, 14 Feb 1993 19:45:37 +1100 (from owner-big-internet) Return-Path: Received: from thumper.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11427; Sun, 14 Feb 1993 16:31:31 +1100 (from tsuchiya@thumper.bellcore.com) Received: from chiya.bellcore.com by thumper.bellcore.com (4.1/4.7) id for big-internet@munnari.oz.au; Sun, 14 Feb 93 00:31:21 EST Received: by chiya.bellcore.com (4.1/4.7) id for big-internet@munnari.oz.au; Sun, 14 Feb 93 00:31:20 EST Date: Sun, 14 Feb 93 00:31:20 EST From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Message-Id: <9302140531.AA04078@chiya.bellcore.com> To: avalon@coombs.anu.edu.au, big-internet@munnari.oz.au Subject: Re: Relative Addressing > > > Is there any reason why everyone wants to use complete, absolute > addresses in packets and not a nice relative address ? How often do > you use your absolute mail address when sending email ? For email, > you can get away with "joe@cray" or "joe@cray.cs" and surface mail > is similar (you don't need to put in the country or state if you > send your neighbour mail). > > (What do I mean by 'relative address' ? An address which is essentially > the route to take to reach the endpoint, similar to those used by PIP > in the RD and RH fields). > As you say, Pip uses relative addresses.....but, the Pip host (or whatever forms the addresses) still has to know the complete address of itself and the destination, to know how much of the address to put in the packet..... It turns out to be easier to do with dns because the hierarchy is strict, not overlapping..... PX From owner-big-internet@munnari.oz.au Sun Feb 14 19:57:25 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AB15872; Sun, 14 Feb 1993 19:57:40 +1100 (from owner-big-internet) Return-Path: Received: from Sun.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13304; Sun, 14 Feb 1993 17:52:59 +1100 (from Bob.Hinden@Eng.Sun.COM) Received: from Eng.Sun.COM (zigzag-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA23531; Sat, 13 Feb 93 22:52:47 PST Received: from bigriver.Eng.Sun.COM (bigriver-248) by Eng.Sun.COM (4.1/SMI-4.1) id AA08889; Sat, 13 Feb 93 22:57:07 PST Received: by bigriver.Eng.Sun.COM (4.1/SMI-4.1) id AA25039; Sat, 13 Feb 93 22:52:45 PST Date: Sat, 13 Feb 93 22:52:45 PST From: Bob.Hinden@Eng.Sun.COM (Bob Hinden) Message-Id: <9302140652.AA25039@bigriver.Eng.Sun.COM> To: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Cc: big-internet@munnari.oz.au In-Reply-To: <9302091505.AA26212@chiya.bellcore.com> Subject: Re: Metro Addressing Content-Length: 1255 Paul, > Seriously, though, it seems to me that, over time, we will periodically > be renumbering the internet, to reflect evolution of topology, routing > practices, and so on. My strong speculation is that renumbering will > eventually be mandatory under any scheme..... I have real problems with this assumption. I don't think we could get all internet sites to renumber now, let alone when we have a 10^^9 internet. Sites will renumber when it is in their interest to do so. For example when they switch providers. I have a hard time imagining that all sites can be convinced to renumber at approximately the same time to solve a global internet problem. Sort of like asking all telephone subscribers to change their telephone numbers because the inter-exchange carriers decide to upgrade to SS8. I just don't see it as possible. Large global changes like this will, IMHO, be impossible. We are a long way from being able to do it in one site, let alone across the whole internet. Sites with many types of equipment, running various revisions of software, each with various levels of support will make this very difficult to do, even in a single site. Trying to coordinate this across the whole internet would be a staggering task. Bob From owner-Big-Internet@munnari.oz.au Sun Feb 14 20:15:14 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA16291; Sun, 14 Feb 1993 20:15:28 +1100 (from owner-Big-Internet) Return-Path: Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16284; Sun, 14 Feb 1993 20:15:14 +1100 (from tli@cisco.com) Received: by lager.cisco.com; Sun, 14 Feb 1993 01:15:00 -0800 Date: Sun, 14 Feb 1993 01:15:00 -0800 From: Tony Li Message-Id: <199302140915.AA12107@lager.cisco.com> To: atkinson@tengwar.itd.nrl.navy.mil Cc: big-Internet@munnari.oz.au In-Reply-To: Ran Atkinson's message of Sat, 13 Feb 1993 10:18:45 -0500 <9302131018.ZM828@tengwar.itd.nrl.navy.mil> Subject: metro addressing (This is using NRL as an example, feel free to substitute GE or IBM or another large organisation in your own head :-). NRL is located in Mississippi, California, DC, Maryland, and West Virginia. I want to continue to have a single private network for all of NRL (something like PRIVATE-NET.USN.NRL.*) and advertise routing gateways into that private net at several places. So the gateway dual-homed host might be FOO.DC.USN-GW and also PRIVATE-NET.USN.DC-GW, where FOO is whatever the top-level metro hook is. Hosts internal to NRL should only need *1* address and it should be of the form PRIVATE-NET.USN.NRL.hostname. That address would be usable by folks outside unchanged (i.e. their router observes that a nearby metro-addressed dual-homed gateway is advertising routes into PRIVATE-NET.USN.*) and the internal hosts would be fully accessible to the outside but NEED NOT have a metro address in addition to their private network address. Do I understand that this will still work with metro-based addressing or am I still confused ? Well, this is a loaded question. First and foremost, we have NOT discussed how multihomed domains work in ANY of these scenarios. Further, since I'm not really an advocate of metro-based addressing, I will undoubtedly misrepresent someone else's views. That's never stopped me, tho. ;-) There are basically a few ways to make multi-homed domains work in ANY of these schemes (metro, CIDR, provider, whatever). I'll try to give the highlights, but RFC 1237 does a much better job. Option 1: All hosts within NRL should have a metro address and only a metro address. Thus, you get Mississippi.USN.NRL.*, DC.USN.NRL.*, etc. Note that routing within NRL would have to carry all of these prefixes around. I suspect that this would be a net win for your IGP anyhow. All of the right things happen with inter-domain routing automagically. Option 2: All hosts within NRL get address space from a single metro area. Within your prefix, you subdivide as you wish. For purposes of aggregation you may wish to subdivide the NRL prefix internally according to metro area. Thus you might get: DC.USN.NRL.DC.*, DC.USN.NRL.Mississippi.*, DC.USN.NRL.CA.*, etc. Interior routing carries around only your internal regional prefixes. Same IGP overhead as option 1. Inter-domain routing now can work in one of several ways. Option 2a: In the default case, you would appear to be aggregated into the DC metro area and you would advertise nothing at other boundaries. Traffic inbound to NRL would all pass though the DC connect. Outbound traffic falls out properly. Option 2b: Act as a transit to the DC area. Advertise the DC metro aggregate through other boundaries. Inbound traffic would now flow first into NRL, however, you are now providing transit service. Note that all traffic into NRL gets into NRL at the first possible boundary, even if this is not optimal. Option 2c: Advertise the NRL prefix at other boundaries. This injects a longer prefix (i.e., noise, entropy, overhead) into the interdomain routing. As with 2b, inbound NRL traffic finds the first possible NRL boundary. There is no guarantee (without some algorithm for automagic aggregation) that the noise injected into the routing system is ever recovered. Your prefix could end up not aggregated half way around the world. Option 2c var 1: Assuming the inter-domain routing protocol has at least the capabilities of IDRP, only advertise your prefix into a limited set of other domains. This allows you to limit the level of noise that you inject, at the cost of possibly missing some optimal paths. Option 2d: Advertise the NRL internal metro prefixes into inter-domain routing. This would allow optimal routing into the particular area. However, this would encourage inbound traffic to remain outside of NRL for as long as possible. Option 2d var 1: As with 2c var 1. Option 2e: Hybrid of 2c and 2d. Advertise both NRL internal metro prefixes and an NRL aggregate. Differs from 2d only if some of the internal metro prefixes has been aggregated away at some point. This option would cause traffic to flow to NRL at the nearest boundary. Option 2e var 1-3: Hybrid 2c var 1 and 2d var 1. Hybrid 2c and 2d var 1. Hybrid 2c var 1 and 2d. Behaviors are permutations of the components. P.S. If you use continents at the top-level, you will want to split Asia into East Asia, South Asia, and West Asia at least. The continents vary widely in size and population and the top level pieces should, IMHO, be roughly equal in scale. Otherwise the top-level for Asia will require a lot more powerful systems than anyone else needs. Size and population are not particularly relevant. The primary question is where does it make sense to aggregate? I stipulate that I have not done more than create a strawman and that extensive further engineering consideration remains to be done.. Tony p.s. If you've actually read this far, I will take the opportunity to point out how a continental-at-the-top mechanism helps routing in the options 2b-e are selected. Assume that automagic aggregation happens at the continental boundary. NRL routing information is automatically confined to the continent. In Steve's scheme, _as_I_understand_it_, NRL prefixes once advertised outside of the metro area in which they occur, have no other obvious aggregation boundary. Steve, if I'm completely screwy, please correct me. From owner-Big-Internet@munnari.oz.au Sun Feb 14 20:21:36 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA16467; Sun, 14 Feb 1993 20:22:07 +1100 (from owner-Big-Internet) Return-Path: Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16443; Sun, 14 Feb 1993 20:21:36 +1100 (from tli@cisco.com) Received: by lager.cisco.com; Sun, 14 Feb 1993 01:21:20 -0800 Date: Sun, 14 Feb 1993 01:21:20 -0800 From: Tony Li Message-Id: <199302140921.AA12385@lager.cisco.com> To: dcrocker@Mordor.Stanford.EDU Cc: big-internet@munnari.oz.au In-Reply-To: Dave Crocker's message of Sat, 13 Feb 93 10:00:27 -0800 <9302131800.AA25929@Mordor.Stanford.EDU> Subject: addressing I don't see the point in burning a level just to separate the U.S. from Canada. I tend to suspect that Canadians would disagree with you. ;-) I bet. More political based addressing. ;-( (Less frivolously, I'll note that trans-border data flow is still a very major issue and serves as just one of the reasons that keeping aware of national boundaries is quite useful.) As long as the national border coincides cleanly with _some_ set of entities in the hierarchy, this isn't a problem. You just have a list of provinces/states to play with at the borders. At least _this_ list isn't changing too fast. ;-) Tony From owner-Big-Internet@munnari.oz.au Mon Feb 15 01:03:05 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA23335; Mon, 15 Feb 1993 01:03:16 +1100 (from owner-Big-Internet) Return-Path: Received: from coombs.anu.edu.au by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23332; Mon, 15 Feb 1993 01:03:05 +1100 (from avalon@coombs.anu.edu.au) Received: by coombs.anu.edu.au (5.61/1.0) id AA24324; Mon, 15 Feb 93 01:02:55 +1100 From: avalon@coombs.anu.edu.au (Darren Reed) Message-Id: <9302141402.AA24324@coombs.anu.edu.au> Subject: Re: Relative Addressing To: dcrocker@Mordor.Stanford.EDU (Dave Crocker) Date: Mon, 15 Feb 93 1:02:53 EST Cc: big-internet@munnari.oz.au In-Reply-To: <9302131822.AA26436@Mordor.Stanford.EDU>; from "Dave Crocker" at Feb 13, 93 10:22 am Reply-To: avalon@coombs.anu.edu.au X-Mailer: ELM [version 2.3 PL11] In some email I received from Dave Crocker, Sie wrote: > > The key reason for wanting globally unique, absolute addresses, is > that debugging & management are massively easier. The Security folks > seem particularly strong on this point. Absolute addresses as in IPv4 aren't that secure. I've looked at some stuff on building firewalls and they point out the only thing in a packet you can trust is the destination address and port. Wouldn't it be better if a source address was built up as it passed through routers on the way to the destination ? At least then it would require more hosts to 'lie' about the packet (maybe this can work with using absolute addresses too, but it is similar to putting in filters on all traffic to stop fakes). I haven't given much thought to debugging/management, but how hard could it be if you don't have to worry about a "net number" and just worry about numbering subnets and hosts ? Darren From owner-Big-Internet@munnari.oz.au Mon Feb 15 02:26:52 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA24995; Mon, 15 Feb 1993 02:26:58 +1100 (from owner-Big-Internet) Return-Path: Received: from itd.nrl.navy.mil by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24992; Mon, 15 Feb 1993 02:26:52 +1100 (from atkinson@itd.nrl.navy.mil) Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA12255; Sun, 14 Feb 93 10:26:48 EST Date: Sun, 14 Feb 93 10:26:48 EST From: atkinson@itd.nrl.navy.mil (Ran Atkinson) Message-Id: <9302141526.AA12255@itd.nrl.navy.mil> To: big-Internet@munnari.oz.au Subject: Re: relative addressing Folks who doubt that security is much much easier to add if there are fixed absolute addresses have not looked at the security protocols for datagram networks (e.g. SP3 or ISO NLSP). Fixed absolute addresses are much easier to handle from a security perspective. Ran atkinson@itd.nrl.navy.mil From owner-Big-Internet@munnari.oz.au Mon Feb 15 02:46:51 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA25427; Mon, 15 Feb 1993 02:47:03 +1100 (from owner-Big-Internet) Return-Path: Received: from MITCHELL.CIT.CORNELL.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25424; Mon, 15 Feb 1993 02:46:51 +1100 (from Scott_Brim@cornell.edu) Received: from by mitchell.cit.cornell.edu (4.1/1.34/Honig-1.3) id AB04324; Sun, 14 Feb 93 10:46:39 EST Message-Id: <9302141546.AB04324@mitchell.cit.cornell.edu> Date: Sun, 14 Feb 1993 10:46:44 -0500 To: big-internet@munnari.oz.au From: Scott_Brim@cornell.edu X-Sender: swb@132.236.200.25 (Unverified) Subject: An old Feynman quote The first time I saw this was when Henry Spencer posted it on tcp-ip in 1989. I can't resist sending it to big-internet at this time. >From the concluding essay ("The Value Of Science") in Richard Feynman's >last book, "What Do *You* Care What Other People Think?": > > Our responsibility is to do what we can, learn what we can, > improve the solutions, and pass them on. It is our respon- > sibility to leave the people of the future a free hand. In > the impetuous youth of humanity, we can make grave errors > that can stunt our growth for a long time. This we will do > if we say we have the answers now, so young and ignorant as > we are. If we suppress all discussion, all criticism, pro- > claiming "This is the answer, my friends; man is saved!" we > will doom humanity for a long time to the chains of authority, > confined to the limits of our present imagination... From owner-Big-Internet@munnari.oz.au Mon Feb 15 04:01:30 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA27056; Mon, 15 Feb 1993 04:01:47 +1100 (from owner-Big-Internet) Return-Path: Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27053; Mon, 15 Feb 1993 04:01:30 +1100 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <11974>; Sun, 14 Feb 1993 09:01:00 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Sun, 14 Feb 1993 09:00:56 -0800 To: Tony Li Cc: big-Internet@munnari.oz.au, deering@parc.xerox.com Subject: Re: metro addressing In-Reply-To: Your message of "Sun, 14 Feb 93 01:15:00 PST." <199302140915.AA12107@lager.cisco.com> Date: Sun, 14 Feb 1993 09:00:46 PST Sender: Steve Deering From: Steve Deering Message-Id: <93Feb14.090056pst.12171@skylark.parc.xerox.com> > In Steve's scheme, _as_I_understand_it_, NRL prefixes once advertised > outside of the metro area in which they occur, have no other obvious > aggregation boundary. Steve, if I'm completely screwy, please correct > me. They could be aggregated at the country level into the U.S. prefix, since all of NRL's points of attachment to the public internet are within the U.S. Steve From owner-Big-Internet@munnari.oz.au Mon Feb 15 04:29:12 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA27481; Mon, 15 Feb 1993 04:29:25 +1100 (from owner-Big-Internet) Return-Path: Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27478; Mon, 15 Feb 1993 04:29:12 +1100 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <11894>; Sun, 14 Feb 1993 09:28:52 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Sun, 14 Feb 1993 09:28:43 -0800 To: Tony Li Cc: big-internet@munnari.oz.au, deering@parc.xerox.com Subject: Re: addressing In-Reply-To: Your message of "Sun, 14 Feb 93 01:47:19 PST." <199302140947.AA12600@lager.cisco.com> Date: Sun, 14 Feb 1993 09:28:38 PST Sender: Steve Deering From: Steve Deering Message-Id: <93Feb14.092843pst.12171@skylark.parc.xerox.com> > My current understanding of the top level debate is > > Person Steve Paul Tony > Top Level Countries Metro Continent > > Agreed? Tony, Your table is correct for you and me, but Paul wants to put Provider at the top, not Metro. He mentioned my claim that it would be feasible to put Metro at the top, but he certainly does not endorse it. > Short, broad hierarchies also enable more efficient use of the > address space, which some of us consider important. > > I disagree. It is only more efficient if there are bits high up in > the hierarchy that are not used. One byte can be used to address 256 > flat items or 2 sets of 128 or .... But you want to use the first byte to identify continents -- 8 bits to represent 6 or 7 values seems rather inefficient to me. > While I do consider efficient use important, I don't see that making > things tall and skinny is necessarily inefficient. Each additional level increases the amount of fragmentation of the address space. Hierarchical addressing will always be less address-space-efficient than flat routing if the address assignment has to satisfy any external criteria, such as respecting organization boundaries or provider boundaries or geographic boundaries. The more levels of hierarchy, the greater the inefficiency. Steve From owner-Big-Internet@munnari.oz.au Mon Feb 15 04:32:29 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA27543; Mon, 15 Feb 1993 04:32:44 +1100 (from owner-Big-Internet) Return-Path: Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27540; Mon, 15 Feb 1993 04:32:29 +1100 (from dcrocker@Mordor.Stanford.EDU) Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA27657; Sun, 14 Feb 93 09:32:06 -0800 Message-Id: <9302141732.AA27657@Mordor.Stanford.EDU> To: avalon@coombs.anu.edu.au Cc: big-internet@munnari.oz.au Subject: Re: Relative Addressing Org: The Branch Office, Sunnyvale CA Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Mon, 15 Feb 93 01:02:53 -0500. <9302141402.AA24324@coombs.anu.edu.au> Date: Sun, 14 Feb 93 09:32:05 -0800 From: Dave Crocker X-Mts: smtp Darren, ---- Included message: > The key reason for wanting globally unique, absolute addresses, is > that debugging & management are massively easier. The Security folks > seem particularly strong on this point. Absolute addresses as in IPv4 aren't that secure. I've looked at Please note that I did not assert that GUA's were secure, but rather that they were wanted by the security community. Please also note that I cited network management ease. I'm not a security techie (that's the realm of a different Crocker) so I can't defend the details. However the network management arguement -- which I suspect is also relevant for the Security folks -- is that packets are far easier to trace when they have the same identifier end-to-end. Dave From owner-Big-Internet@munnari.oz.au Mon Feb 15 04:42:14 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA27698; Mon, 15 Feb 1993 04:42:34 +1100 (from owner-Big-Internet) Return-Path: Received: from coombs.anu.edu.au by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27683; Mon, 15 Feb 1993 04:42:14 +1100 (from avalon@coombs.anu.edu.au) Received: by coombs.anu.edu.au (5.61/1.0) id AA13007; Mon, 15 Feb 93 04:41:35 +1100 From: avalon@coombs.anu.edu.au (Darren Reed) Message-Id: <9302141741.AA13007@coombs.anu.edu.au> Subject: Re: Relative Addressing To: dcrocker@Mordor.Stanford.EDU (Dave Crocker) Date: Mon, 15 Feb 93 4:41:34 EST Cc: big-internet@munnari.oz.au In-Reply-To: <9302141732.AA27657@Mordor.Stanford.EDU>; from "Dave Crocker" at Feb 14, 93 9:32 am Reply-To: avalon@coombs.anu.edu.au X-Mailer: ELM [version 2.3 PL11] In some email I received from Dave Crocker, Sie wrote: > > Please note that I did not assert that GUA's were secure, but rather > that they were wanted by the security community. Please also note > that I cited network management ease. > > I'm not a security techie (that's the realm of a different Crocker) so > I can't defend the details. However the network management arguement -- > which I suspect is also relevant for the Security folks -- is that packets > are far easier to trace when they have the same identifier end-to-end. When I used "Relative Addressing" I was just refering to having a different ('less complete') address to reach the host next to you than what would be required for one (say) in Finland. Maybe 'variable length' better describes this sort of address where the length is proportional to the distance away it is (encourages 'close' net connections :). Darren From owner-big-internet@munnari.oz.au Mon Feb 15 05:08:11 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA28060; Mon, 15 Feb 1993 05:08:18 +1100 (from owner-big-internet) Return-Path: Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17102; Sun, 14 Feb 1993 20:47:28 +1100 (from tli@cisco.com) Received: by lager.cisco.com; Sun, 14 Feb 1993 01:47:19 -0800 Date: Sun, 14 Feb 1993 01:47:19 -0800 From: Tony Li Message-Id: <199302140947.AA12600@lager.cisco.com> To: deering@parc.xerox.com Cc: big-internet@munnari.oz.au, deering@parc.xerox.com In-Reply-To: Steve Deering's message of Sat, 13 Feb 1993 17:32:11 PST <93Feb13.173213pst.12171@skylark.parc.xerox.com> Subject: addressing I hope that the task of the national authorites could be well-enough prescribed and circumscribed to minimize the hazards. (By the way, what I have in mind as an appropriate national "authority" is something like a national chapter of the ISOC, not something like ANSI or a PTT. Probably naive of me, I know.) I agree with the idea of the national ISOC dealing with it. Naive of both of us. ;-) > Political boundaries have little to do with topology. Neither do continental boundaries, as your example of South American connectivity shows. However, I think that as Internet service becomes ubiquitous, aggregation by country will work quite well, from a quality-of- routing perspective. True. But as Internet service becomes ubiquitous, the continental boundaries again become natural barriers to connectivity and thus provide demarcation of topology. For geographically-large countries that are nearby, you may well want to keep finer-grain routes (e.g., U.S. wide-area routers would likely keep per-metro routes for Canadian metros, rather than just a single route for Canada), but that's easily done. Certainly. My objections to doing things on the country level are basing addressing on very dynamic political boundaries, and that the granularity isn't as large as I would like for aggregation purposes. In either case, there are certainly situations where you want to introduce noise to improve routing. See my reply to Ran... Yes. That's why I advocate putting countries at the top level. I was describing a *feasible* approach, not necessarily a *good* approach. (We seem to be having trouble communicating, but I don't know if the problem is at the sender or the receiver.) At the receiver. I'm confused. My current understanding of the top level debate is Person Steve Paul Tony Top Level Countries Metro Continent Agreed? > I should point out that all of these cases do NOT require "wiring". > You treat them as a partitioned entity and use know techniques for > healing them. Yes, yes, yes. I'm usually careful to qualify every statement I make about connectivity requirements of hierarchical addressing schemes with some mention of partition healing, but one of the few times I omit the qualification, you jump on it. (In fact, I did mention it later on in my message.) For the sake of brevity, let's just take it as assumed from now on, OK? Sorry, I didn't mean to jump on you. It was Paul who was pushing the rewiring angle. If they were to assign addresses according to a metro plan today, they would *not* have to renumber in the future. While there are a small number of sites, they can use partition-healing techniques to make up for lack of wires; as density increases, wires will be added to reduce routing overheads and improve delivery paths. True. I was confused. > Well, we're gonna need [partition healing] techniques at some level > somewhere, so I think we better pick some way of making them work. This > would really argue for there being a tall, skinny hierarchy (i.e., the > arity of the tree is a single digit integer). If you can do painless renumbering, you may be right. This is an effective (literal?) requirement of IPv7 anyhow. If renumbering is not painless, a short, broad hierarchy is preferrable, because it enables much more reconfiguration of the topology to occur without requiring address changes. True. Short, broad hierarchies also enable more efficient use of the address space, which some of us consider important. I disagree. It is only more efficient if there are bits high up in the hierarchy that are not used. One byte can be used to address 256 flat items or 2 sets of 128 or .... While I do consider efficient use important, I don't see that making things tall and skinny is necessarily inefficient. Tony From owner-Big-Internet@munnari.oz.au Mon Feb 15 06:27:21 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA29296; Mon, 15 Feb 1993 06:27:30 +1100 (from owner-Big-Internet) Return-Path: Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29290; Mon, 15 Feb 1993 06:27:21 +1100 (from dcrocker@Mordor.Stanford.EDU) Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA29339; Sun, 14 Feb 93 11:26:59 -0800 Message-Id: <9302141926.AA29339@Mordor.Stanford.EDU> To: avalon@coombs.anu.edu.au Cc: big-internet@munnari.oz.au Subject: Re: Relative Addressing Org: The Branch Office, Sunnyvale CA Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Mon, 15 Feb 93 04:41:34 -0500. <9302141741.AA13007@coombs.anu.edu.au> Date: Sun, 14 Feb 93 11:26:59 -0800 From: Dave Crocker X-Mts: smtp ---- Included message: When I used "Relative Addressing" I was just refering to having a different ('less complete') address to reach the host next to you than what would be required for one (say) in Finland. Maybe 'variable length' better describes this sort of address where the length is proportional to the distance away it is (encourages 'close' net connections :). Based upon the kinds of problems I've seen with the use of "variable" domain name length in email administrations, I'd strongly recommend against such a scheme. Using the full, globally unique string ALWAYS simplifies operations and management massively. Dave From owner-Big-Internet@munnari.oz.au Mon Feb 15 06:30:50 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA29377; Mon, 15 Feb 1993 06:31:06 +1100 (from owner-Big-Internet) Return-Path: Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29364; Mon, 15 Feb 1993 06:30:50 +1100 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <11977>; Sun, 14 Feb 1993 11:30:30 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Sun, 14 Feb 1993 11:30:20 -0800 To: atkinson@itd.nrl.navy.mil (Ran Atkinson) Cc: big-internet@munnari.oz.au, deering@parc.xerox.com Subject: Re: Metro addressing In-Reply-To: Your message of "Sat, 13 Feb 93 18:26:47 PST." <9302140226.AA05692@itd.nrl.navy.mil> Date: Sun, 14 Feb 1993 11:30:05 PST Sender: Steve Deering From: Steve Deering Message-Id: <93Feb14.113020pst.12171@skylark.parc.xerox.com> > It isn't that I think that "every multi-homed organisation" should > have the ability to have its own non-metro addresses, but rather that > those organisations which really do already have very large private > networks (e.g. DoD, GE, IBM, DEC, Xerox, others) should be able to > continue to have about the same capability. ... I am not talking about > organisations that aren't multi-homed or about organisations which are > smaller than "very large". OK, now I understand. I extrapolated from your claim that your multi-homed private network requires or desires its own, single, public address prefix to the conclusion that every multi-homed organization would require or desire the same. Sure, a small number of large private networks could be treated as distinct providers or distinct metros, but where would you draw the line between a "big" private net and a "not-so-big" private net, such that the number of "big" nets remains manageably small, and the operators of "not-so-big" nets remain content without their own prefixes? (I wonder how many organizations in the U.S. currently operate a private network between two or more metro areas, and how many will do so in the future.) > There are several reasons that organisations currently use large > private networks. Certainly. I have never advocated the abolition of large private networks. Why do you think that it would be impossible or difficult to operate a private network using addresses that conform to the scaling needs of the public infrastructure? Yes, it might be a little more complicated than having your own unique prefix, e.g., filtering gateways might need to know a short list of prefixes, rather than just a single prefix, to distinguish between "internal" hosts and "external" hosts, but are there any real show-stoppers? > While I might argue that the better technical solution would be to > address the security of the Internet more effectively, I am enough of > a realist to consider that Internet security and implementations of > that will be in the forefront any time soon and so I want to be sure > that we don't drive these large organisations away from the Internet > without giving their particular concerns full thought. In what ways would their security would be any weaker than it is now if they had to use addresses taken from the public addressing hierarchy (e.g., from their attached public providers or their attached metros)? > I will go along with the consensus, but I want to be sure that all > have thoroughly pondered these real-world issues along the way. :-) Consensus? Wouldn't that be nice! I, for one, really appreciate your efforts to ensure that real-world issues are pondered and adequately handled, and I hope you will continue to help us all understand exactly what those issues are. We *are* trying to design an internet architecture for the real world. Steve From owner-Big-Internet@munnari.oz.au Mon Feb 15 06:39:30 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA29490; Mon, 15 Feb 1993 06:39:38 +1100 (from owner-Big-Internet) Return-Path: Received: from sadye.emba.uvm.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29486; Mon, 15 Feb 1993 06:39:30 +1100 (from Garrett.Wollman@UVM.EDU) Received: by sadye.emba.uvm.edu id AA20800 (5.65/6.02); Sun, 14 Feb 93 14:39:05 -0500 Date: Sun, 14 Feb 93 14:39:05 -0500 From: Garrett.Wollman@UVM.EDU Message-Id: <9302141939.AA20800@sadye.emba.uvm.edu> To: atkinson@itd.nrl.navy.mil (Ran Atkinson) Cc: big-Internet@munnari.oz.au Subject: Re: relative addressing In-Reply-To: <9302141526.AA12255@itd.nrl.navy.mil> References: <9302141526.AA12255@itd.nrl.navy.mil> < Fixed absolute addresses are much easier to handle from a > security perspective. Ran:- Don't EIDs provide the necessary location-independent entities for this function? (And you can have an EID prefix like US.GSA.USN.NRL.*, assuming that GSA wants to assign things like that...) It seems to me that they provide all the information that IPv4 addresses do, and under the schemes I'm familiar with, every host has at least one (it might have more, depending on how they are assigned by the owning site). So, it should be no harder to use EIDs in a security or authentication protocol than it is to handle a multi-homed host under IPv4 (stipulated that some systems have problems with that, too). PIP has EIDs (or the last version of it that I looked at did), so this should work for PIP. All the other protocols use location-insensitive addressing(*), so it's not a problem for them. -GAWollman (*)Def: location-insensitive === the address of a remote host does not depend on your address; this is different from location-independent === your address doesn't depend on where in the topology you are -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@emba.uvm.edu | Shashish is the bonding of hearts in spite of distance. uvm-gen!wollman | It is a bond more powerful than absence. We like people UVM disagrees. | who like Shashish. - Claude McKenzie + Florent Vollant From owner-Big-Internet@munnari.oz.au Mon Feb 15 09:16:41 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03535; Mon, 15 Feb 1993 09:16:53 +1100 (from owner-Big-Internet) Return-Path: Received: from MITCHELL.CIT.CORNELL.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03529; Mon, 15 Feb 1993 09:16:41 +1100 (from Scott_Brim@cornell.edu) Received: from by mitchell.cit.cornell.edu (4.1/1.34/Honig-1.3) id AB11169; Sun, 14 Feb 93 17:16:33 EST Message-Id: <9302142216.AB11169@mitchell.cit.cornell.edu> Date: Sun, 14 Feb 1993 17:16:38 -0500 To: big-internet@munnari.oz.au From: Scott_Brim@cornell.edu X-Sender: swb@132.236.200.25 Subject: Re: addressing Paul, in saying you will impose a limit on the number of top-level providers, are you committing us to worldwide support of regulated monopolies, and closing the door for all time (or until we redo Internet addressing) on new innovative providers? Talk about bucking the tide of history, guy! Who gets to decide which providers are a "reasonable choice for the users"? The ITU??? hey would all have ambitions of becoming mega- >providers some day. And if each of those providers insists on getting >enough address space in advance to grow to the size of a mega-provider, >you would end up wasting a lot of address space, which matters little >for CLNP, but is a significant concern for SIP. In the evolution of BGP we once thought we were going to need a field in the packets saying how you thought you were related to your neighbor -- up, down, or lateral. At the time the commercial ISPs were starting up pretty strongly, and some of us argued that you didn't want to force people to define their relationships so explicitly, that you would probably end up with a whole lot of meaningless (except politically) "laterals". We argued successfully, so the field was removed and we never got to test our prediction, but I would still strongly agree with what Paul and Steve say above. Every provider will assert the position they *want* to be in, in order not to get locked in -- so it's a big win not to force them to assert anything so explicitly, but to have only their actions define their role in the infrastructure at any given time. >The idea behind metro-based addressing is to force providers to put >interconections where they might otherwise not do so in order to make >customers' lives easier and to foster competition in the provision of >internet service (assuming that having to change addresses when changing >providers is an impediment to competition). ... >The alternative to interconnection of all providers within a geographical >area is to tunnel or to leak next-level-down routes into the inter-area >routing. However, with my metro-based scheme, those approaches wouldn't >work very well at all as a long-term way of avoiding interconnection within >a metro, because the next level down is site identifier, which means a >potentially huge number of site routes would have to be exchanged over the >tunnels or leaked into inter-metro routing. In the short-term (i.e., on >day one, and for quite a few days after that), they should work fine, given >that we currently do global, flat routing to all sites on the Internet. I am inclined to believe that we will have some sort of regulation of Internet service provision in most countries within the next few years, whether anyone believes we need it or not. Therefore the requirement that providers be somehow interconnected within the metro (or more awkwardly through inter-metro routing) is not such a large obstacle as you might think, since there is plenty of experience dealing with it in other kinds of regulated services (telecomm, electricity...). Scott From owner-Big-Internet@munnari.oz.au Mon Feb 15 09:48:10 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA04790; Mon, 15 Feb 1993 09:50:18 +1100 (from owner-Big-Internet) Return-Path: Received: from gaea.es.flinders.edu.au by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04730; Mon, 15 Feb 1993 09:48:10 +1100 (from esrte@es.flinders.edu.au) Received: by gaea.es.flinders.edu.au (16.8/15.6) id AA00963; Mon, 15 Feb 93 09:16:26 +1030 From: Richard Eames Posted-Date: Mon, 15 Feb 93 9:16:25 CDT Received-Date: Mon, 15 Feb 93 09:16:26 +1030 Message-Id: <9302142246.AA00963@gaea.es.flinders.edu.au> Subject: Please Please Please unsubscribe me from this list !!!!!!! To: big-internet@munnari.oz.au Date: Mon, 15 Feb 93 9:16:25 CDT Mailer: Elm [revision: 70.30] Please remove me from this list, I can't stand the Re:'s anymore. From owner-Big-Internet@munnari.oz.au Mon Feb 15 10:06:25 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA05365; Mon, 15 Feb 1993 10:06:38 +1100 (from owner-Big-Internet) Return-Path: Received: from nero.clearpoint.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05356; Mon, 15 Feb 1993 10:06:25 +1100 (from martillo@nero.clearpoint.com) Received: by nero.clearpoint.com (4.1/1.34) id AA05002; Sun, 14 Feb 93 17:57:51 EST Date: Sun, 14 Feb 93 17:57:51 EST From: martillo@nero.clearpoint.com (Joachim Carlo Santos Martillo Ajami) Message-Id: <9302142257.AA05002@nero.clearpoint.com> To: tli@cisco.com Cc: bill.simpson@um.cc.umich.edu, big-internet@munnari.oz.au In-Reply-To: Tony Li's message of Sun, 14 Feb 1993 00:31:29 -0800 <199302140831.AA11511@lager.cisco.com> Subject: ARP versus ES-IS Date: Sun, 14 Feb 1993 00:31:29 -0800 From: Tony Li To: martillo@nero.clearpoint.com Cc: bill.simpson@um.cc.umich.edu, big-internet@munnari.oz.au, martillo@nero.clearpoint.com In-Reply-To: Joachim Carlo Santos Martillo Ajami's message of Sat, 13 Feb 93 07:35:06 EST <9302131235.AA00657@nero.clearpoint.com> Subject: ARP versus ES-IS Could all you ES-IS fans tell me what's bad about ARP? No router discovery. No black hole detection. Real fun when mixed-media bridging gets involved. No autoconfiguration. I guess if you don't like ARP, I suppose you could just send IP packets whose IP address was not resolved to the MAC broadcast address, keep some maximum number of such packets outstanding to a given destination IP address within some time period and learn mac addresses from incoming IP packets. Routers would be automatically discovered. This fails in the case of a multihomed host with asymmetric routes. And the overhead is not inconsequential. Why does it fail in the case of a multihomed host with asymmetric routes? And let's consider the overhead on an ethernet worst case where a maximal sized etherpacket is to be sent to a local IP host whose IP address has not been resolved to a mac address. Using arp. 1) Save IP packet, broadcast arp request. 2) Each host on ethernet checks if arp is for them. 3) If so send arp response to first host, otherwise drop arp. 4) first host receives arp response and sends out original packet. Not using arp. 1) If IP address not in arp table, store IP address in arp table with broadcast mac address and set fast timeout on entry. If IP address in arp table with broadcast mac address enqueue packet until mac address times out 2) Send IP packet to broadcast mac address. 3) Host sees packet, if for him keep it and send to IP processing. If not drop it. ARP uses more packets, and requires more packet processing (e.g. target must generate an arp response which must be processed at the querying host). You could argue it is bad for other hosts to receive the initial broadcast IP packet but that is merely a security and buffer utilization issue for most modern ether interfaces. I would argue that if you really care about security, you probably should not use a broadcast medium. As for buffer utilization, with reasonable memory sizes (say 8-32kbytes buffer memory for singly homed hosts and 256 kbytes buffer memory for 8 interface multiply homed hosts), the extra buffer utilization now and then should not be a problem. Tony Joachim Carlo Santos Martillo Ajami The article represents noone's opinions other than the author's. From owner-Big-Internet@munnari.oz.au Mon Feb 15 10:21:27 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA05836; Mon, 15 Feb 1993 10:21:45 +1100 (from owner-Big-Internet) Return-Path: Received: from nero.clearpoint.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05804; Mon, 15 Feb 1993 10:21:27 +1100 (from martillo@nero.clearpoint.com) Received: by nero.clearpoint.com (4.1/1.34) id AA05005; Sun, 14 Feb 93 18:13:07 EST Date: Sun, 14 Feb 93 18:13:07 EST From: martillo@nero.clearpoint.com (Joachim Carlo Santos Martillo Ajami) Message-Id: <9302142313.AA05005@nero.clearpoint.com> To: tli@cisco.com Cc: bill.simpson@um.cc.umich.edu, big-internet@munnari.oz.au In-Reply-To: Tony Li's message of Sun, 14 Feb 1993 00:31:29 -0800 <199302140831.AA11511@lager.cisco.com> Subject: ARP versus ES-IS Date: Sun, 14 Feb 1993 00:31:29 -0800 From: Tony Li To: martillo@nero.clearpoint.com Cc: bill.simpson@um.cc.umich.edu, big-internet@munnari.oz.au, martillo@nero.clearpoint.com In-Reply-To: Joachim Carlo Santos Martillo Ajami's message of Sat, 13 Feb 93 07:35:06 EST <9302131235.AA00657@nero.clearpoint.com> Subject: ARP versus ES-IS Could all you ES-IS fans tell me what's bad about ARP? No router discovery. No black hole detection. Real fun when mixed-media bridging gets involved. No autoconfiguration. I guess if you don't like ARP, I suppose you could just send IP packets whose IP address was not resolved to the MAC broadcast address, keep some maximum number of such packets outstanding to a given destination IP address within some time period and learn mac addresses from incoming IP packets. Routers would be automatically discovered. This fails in the case of a multihomed host with asymmetric routes. And the overhead is not inconsequential. Tony Actually, I would probably argue that the only really obvious problem with broadcasting the initial IP packet whose destination IP address is not yet resolved to a physical address lies with things like SNMP traps where there is no reason to expect any reply from the destination IP host, but I would suggest that in such cases the destination should always be pinged first. Joachim Carlo Santos Martillo Ajami The article represents noone's opinions other than the author's. From owner-Big-Internet@munnari.oz.au Mon Feb 15 11:23:17 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA07634; Mon, 15 Feb 1993 11:23:32 +1100 (from owner-Big-Internet) Return-Path: Received: from p.lanl.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07629; Mon, 15 Feb 1993 11:23:17 +1100 (from peter@goshawk.lanl.gov) Received: from goshawk.lanl.gov by p.lanl.gov (5.65/1.14) id AA24122; Sun, 14 Feb 93 17:22:58 -0700 Received: from localhost.lanl.gov by goshawk.lanl.gov (4.1/5.17) id AA19490; Sun, 14 Feb 93 17:22:57 MST Message-Id: <9302150022.AA19490@goshawk.lanl.gov> To: Bob.Hinden@Eng.Sun.COM (Bob Hinden) Cc: tsuchiya@thumper.bellcore.com (Paul Tsuchiya), big-internet@munnari.oz.au Subject: Re: Metro Addressing In-Reply-To: Your message of Sat, 13 Feb 93 22:52:45 -0800. <9302140652.AA25039@bigriver.Eng.Sun.COM> Date: Sun, 14 Feb 93 17:22:57 MST From: peter@goshawk.lanl.gov Bob, It is not necessary for all sites to renumber at the same time. In fact, once a CIDR hierarchy is in place and being routed it will be possible to ask people to move and let them transition over a fairly good time range. Each move of a pre-CIDR site will *reduce* the size of the routing tables seen at top-level routing domains. It is also important to note that most networks routed on the Internet are actually pretty small. Well over 50% of the Internet's networks are class C nets. From looking at the SRI DNS survey data most of the class C's use less than 50 addresses. In some sense, we get very good scaling in terms of renumbering since the "pain" is distributed out across so many sites. You are right that it is hard for a site to see how this can help them, which is a good reason for the leadership of the Internet should get out there and promote CIDR and renumbering as a reasonable and tractable way of helping the Internet continue to grow. I suspect there is sufficient community effort out there that this is not as big a deal as is being presented. In the meantime, the people in charge of IP networking software at companies should press ahead to build systems and tools which make transitioning IP network addresses easy. All of this will be useful experience which can help feed architectural and system design information into the various IPv7 efforts. cheers, peter From owner-Big-Internet@munnari.oz.au Mon Feb 15 18:23:47 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21331; Mon, 15 Feb 1993 18:23:54 +1100 (from owner-Big-Internet) Return-Path: Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21328; Mon, 15 Feb 1993 18:23:47 +1100 (from tli@cisco.com) Received: by lager.cisco.com; Sun, 14 Feb 1993 23:23:27 -0800 Date: Sun, 14 Feb 1993 23:23:27 -0800 From: Tony Li Message-Id: <199302150723.AA05996@lager.cisco.com> To: martillo@nero.clearpoint.com Cc: bill.simpson@um.cc.umich.edu, big-internet@munnari.oz.au In-Reply-To: Joachim Carlo Santos Martillo Ajami's message of Sun, 14 Feb 93 17:57:51 EST <9302142257.AA05002@nero.clearpoint.com> Subject: ARP versus ES-IS I guess if you don't like ARP, I suppose you could just send IP packets whose IP address was not resolved to the MAC broadcast address, keep some maximum number of such packets outstanding to a given destination IP address within some time period and learn mac addresses from incoming IP packets. Routers would be automatically discovered. This fails in the case of a multihomed host with asymmetric routes. And the overhead is not inconsequential. Why does it fail in the case of a multihomed host with asymmetric routes? Because you may never seen return traffic from that IP address on that media. Tony From owner-Big-Internet@munnari.oz.au Mon Feb 15 18:30:19 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21473; Mon, 15 Feb 1993 18:30:27 +1100 (from owner-Big-Internet) Return-Path: Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21467; Mon, 15 Feb 1993 18:30:19 +1100 (from tli@cisco.com) Received: by lager.cisco.com; Sun, 14 Feb 1993 23:30:10 -0800 Date: Sun, 14 Feb 1993 23:30:10 -0800 From: Tony Li Message-Id: <199302150730.AA06172@lager.cisco.com> To: deering@parc.xerox.com Cc: big-internet@munnari.oz.au, deering@parc.xerox.com In-Reply-To: Steve Deering's message of Sun, 14 Feb 1993 09:28:38 PST <93Feb14.092843pst.12171@skylark.parc.xerox.com> Subject: addressing > Short, broad hierarchies also enable more efficient use of the > address space, which some of us consider important. > > I disagree. It is only more efficient if there are bits high up in > the hierarchy that are not used. One byte can be used to address 256 > flat items or 2 sets of 128 or .... But you want to use the first byte to identify continents -- 8 bits to represent 6 or 7 values seems rather inefficient to me. So we squish it when we decide what to do. I was suggesting a byte as a straw man because it is conceptually easy. > While I do consider efficient use important, I don't see that making > things tall and skinny is necessarily inefficient. Each additional level increases the amount of fragmentation of the address space. Hierarchical addressing will always be less address-space-efficient than flat routing if the address assignment has to satisfy any external criteria, such as respecting organization boundaries or provider boundaries or geographic boundaries. The more levels of hierarchy, the greater the inefficiency. The same argument applies for the fat, short trees. If you allocate a large number of bits to a level of hierarchy, will you always be able to fill that number of bits? In either case that you will be trying to fit whatever you have into some power-of-two sized bucket. You still get fragmentation losses. Tony From owner-Big-Internet@munnari.oz.au Mon Feb 15 18:34:11 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21649; Mon, 15 Feb 1993 18:34:26 +1100 (from owner-Big-Internet) Return-Path: Received: from vela.acs.oakland.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21644; Mon, 15 Feb 1993 18:34:11 +1100 (from bill.simpson@um.cc.umich.edu) Received: from via.ws04.merit.edu by vela.acs.oakland.edu with SMTP id AA27792 (5.65c+/IDA-1.4.4); Mon, 15 Feb 1993 02:34:00 -0500 Date: Mon, 15 Feb 93 02:23:55 EDT From: "William Allen Simpson" Message-Id: <946.bill.simpson@um.cc.umich.edu> To: Tony Li Cc: big-internet@munnari.oz.au Reply-To: bsimpson@morningstar.com Subject: Re: ARP versus ES-IS > No media addresses inside of packets. I understand the problem with this over multi-media bridges. The rationale in the ARP spec says that some systems might not be able to get the media address from the link packet. Does anyone know of anywhere that this is the case? Is there a standard set of workarounds? Perhaps any media address should have a media type field attached to it, and we could have a list of software translations. > Media level redirects. I don't understand this. Bill.Simpson@um.cc.umich.edu From owner-big-internet@munnari.oz.au Mon Feb 15 23:26:05 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA29074; Mon, 15 Feb 1993 23:26:13 +1100 (from owner-big-internet) Return-Path: Received: from tengwar.itd.nrl.navy.mil by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07801; Mon, 15 Feb 1993 11:32:46 +1100 (from atkinson@tengwar.itd.nrl.navy.mil) Received: by tengwar.itd.nrl.navy.mil (16.8/16.2) id AA01569; Sun, 14 Feb 93 19:32:37 -0500 From: atkinson@tengwar.itd.nrl.navy.mil (Ran Atkinson) Message-Id: <9302141932.ZM1567@tengwar.itd.nrl.navy.mil> Date: Sun, 14 Feb 1993 19:32:37 -0500 In-Reply-To: Steve Deering "Re: Metro addressing" (Feb 14, 11:30) References: <93Feb14.113020pst.12171@skylark.parc.xerox.com> Organization: Naval Research Laboratory X-Mailer: Z-Mail (2.1.0 10/27/92) To: big-Internet@munnari.oz.au Subject: Re: Metro addressing & Re: Address uniqueness On Feb 14, 11:30, Steve Deering wrote: > Subject: Re: Metro addressing % Sure, a small number of large private networks could be treated as % distinct providers or distinct metros, but where would you draw the % line between a "big" private net and a "not-so-big" private net, such % that the number of "big" nets remains manageably small, and the % operators of "not-so-big" nets remain content without their own % prefixes? (I wonder how many organizations in the U.S. currently % operate a private network between two or more metro areas, and how % many will do so in the future.) This is the crux of the matter. I'm not sure how you write a rule that draws the line, but I suspect that we could reach consensus on which cases "deserve" a private net prefix and which ones don't. In my mind NRL probably doesn't, but the whole USN net or DISA net or IBM's VNET probably do. I'd be interested in the answer to your parenthetical question. I'd also be curious to know how the NIC determines whether to issue a Class A network today and on how many of those Class A networks are so sparse that they would fit in a Class B or C and how many aren't. I think we need that information to determine the likely size/cost/need of private network addressing hooks. % In what ways would their security would be any weaker than it is now if % they had to use addresses taken from the public addressing hierarchy % (e.g., from their attached public providers or their attached metros) ? The perception in the minds of some private net operators seems to be that they can minimise the number of cracker-attacks by controlling the information on how many hosts they have and where they exist and what geographic locality (e.g. plant) has which hosts. I don't buy that myself, but there are folks who think that way. Of course, they also want to preclude external traffic over their internal links (by knowing all internal traffic has a single network prefix) and they want to firewall (again based on network prefix) and they also find it administratively much easier to have their own corporate-wide address space. These might not be significant enough concerns to justify a private network address space, but then again they might be in some folks minds. II. On an unrelated note, let me explain quickly why security folks like to have unique absolute addresses. The term "EID" means different things to different people and so I'm not going to try to talk in terms of EIDs here. I also still don't fully understand all parts of PIP so I won't address it here either. PIP appears to be non-trivial to secure, but perhaps that is because I don't understand PIP well enough. The existing security protocols (SP3 and ISO NLSP) use frame encapsulation to provide protection; I won't address either specifically, but will try to describe a generic process. One takes the real network layer datagram and protects using a transformation that is reversible and provides some security properties (e.g. confidentiality, authentication, integrity). One then treats the output of that transformation as payload and puts it into a new network layer datagram with a normal unprotected network header. The protected information _cannot_ be modified or altered whilst in transit without that modification causing the back transformation to fail. The information in the unprotected header should not be altered whilst in transit (except maybe a TTL field). At the receive end, the protected data is transformed back into normal form for processing. However the process of unprotecting it might rely on the values of fields in the unprotected header to give clues as to how to unprotect it (e.g. data from system A might use one kind of transformation while data from system B might use a different kind of transformation). Ran atkinson@itd.nrl.navy.mil From owner-big-internet@munnari.oz.au Mon Feb 15 23:52:09 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA29564; Mon, 15 Feb 1993 23:52:13 +1100 (from owner-big-internet) Return-Path: Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21993; Mon, 15 Feb 1993 18:45:10 +1100 (from tli@cisco.com) Received: by lager.cisco.com; Sun, 14 Feb 1993 23:44:45 -0800 Date: Sun, 14 Feb 1993 23:44:45 -0800 From: Tony Li Message-Id: <199302150744.AA06276@lager.cisco.com> To: bsimpson@morningstar.com Cc: big-internet@munnari.oz.au In-Reply-To: "William Allen Simpson"'s message of Mon, 15 Feb 93 02:23:55 EDT <945.bill.simpson@um.cc.umich.edu> Subject: ARP versus ES-IS > No media addresses inside of packets. I understand the problem with this over multi-media bridges. The rationale in the ARP spec says that some systems might not be able to get the media address from the link packet. Does anyone know of anywhere that this is the case? Is there a standard set of workarounds? Perhaps any media address should have a media type field attached to it, and we could have a list of software translations. ARP already has such a list. But the multi-media bridges have to play with things to bridge ARP packets. Please note this is the EXACT same problem as FTP putting IP addresses into the data stream. > Media level redirects. I don't understand this. Currently, if you have multiple subnets on the same cable, you cannot redirect a host in a way to tell it that it should use a different media address on the same cable for that destination. How you tackle this and not put the media address in the packet is called a "challenge". ;-) Tony From owner-Big-Internet@munnari.oz.au Tue Feb 16 01:07:22 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA02019; Tue, 16 Feb 1993 01:07:32 +1100 (from owner-Big-Internet) Return-Path: Received: from nero.clearpoint.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02016; Tue, 16 Feb 1993 01:07:22 +1100 (from martillo@nero.clearpoint.com) Received: by nero.clearpoint.com (4.1/1.34) id AA11703; Mon, 15 Feb 93 08:57:36 EST Date: Mon, 15 Feb 93 08:57:36 EST From: martillo@nero.clearpoint.com (Joachim Carlo Santos Martillo Ajami) Message-Id: <9302151357.AA11703@nero.clearpoint.com> To: jonson@server.af.mil Cc: Christian.Huitema@sophia.inria.fr, tli@cisco.com, big-internet@munnari.oz.au, martillo@nero.clearpoint.com In-Reply-To: Matt Jonson's message of Fri, 5 Feb 93 8:28:02 CST <9302051428.AA02336@server.af.mil> Subject: Metro Addressing Summary From: Matt Jonson Subject: Re: Metro Addressing Summary > Subject: Metro Addressing Summary > If I take a Constellation Auriga (an EISA/ISA bus host resident bridge > router), put it into a PC, configure it with two logical subbridges > (Auriga IP interfaces), assign lb0 (logical subbridge 0) ip address > netid0.hostid0, configure the Auriga to run the standard ip routing > protocols, connect the PC ip interface to the same ip network as lb0 > (i.e. give the PC ip address netid0.hostid1), I can move my PC to > California connect lb1 to a local ip network running the standard ip > routing protocols, get lb1 a local ip network address (either by !!! > manual assignment, by listening and challenge, by a dynamic ip address > server if one is running or by some other procedure), and lo and > behold my PC has changed its position in the network layer network > topology and yet it has kept the same ip address and it talks to > everybody in the ip internetwork just fine. Sure looks to me like you're 1) Depending on IP routing protocols to communicate 2) changing an IP address I am depending on the ability of the portable IP router to acquire an IP address on the foreign network and to exchange routing information with the routers on that network. But this dependence seems minor. Dynamically changing an end host address generally involves far more complexities than changing a router IP address (as long as the IP address which is changed is not involved in any static routes). so, you aren't bridging. In fact your example would work only because you have a portable IP router with a private IP network behind it. But isn't the problem of a motile IP network one which should be considered within the domain of developing big internets. A few years ago a portable IP host was rare. Nowadays with portable PCs and sparcs worrying about portable IP hosts makes a lot of sense. But as the technology advances, isn't it likely that the next step will be portable private networks appearing at different locations in the network topology. -- Lt Matthew W Jonson jonson@server.af.mil snail-mail: Network Systems Engineer 205-416-4075 SSC/SSDN USAF DDN Program Office AV: 596-4075 Gunter AFB, AL 36114 Joachim Carlo Santos Martillo Ajami The article represents noone's opinions other than the author's. From owner-Big-Internet@munnari.oz.au Tue Feb 16 03:17:48 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA04856; Tue, 16 Feb 1993 03:17:56 +1100 (from owner-Big-Internet) Return-Path: Received: from nero.clearpoint.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04853; Tue, 16 Feb 1993 03:17:48 +1100 (from martillo@nero.clearpoint.com) Received: by nero.clearpoint.com (4.1/1.34) id AA11872; Mon, 15 Feb 93 11:09:26 EST Date: Mon, 15 Feb 93 11:09:26 EST From: martillo@nero.clearpoint.com (Joachim Carlo Santos Martillo Ajami) Message-Id: <9302151609.AA11872@nero.clearpoint.com> To: tli@cisco.com Cc: bill.simpson@um.cc.umich.edu, big-internet@munnari.oz.au, martillo@nero.clearpoint.com In-Reply-To: Tony Li's message of Sun, 14 Feb 1993 23:23:27 -0800 <199302150723.AA05996@lager.cisco.com> Subject: ARP versus ES-IS Date: Sun, 14 Feb 1993 23:23:27 -0800 From: Tony Li Subject: ARP versus ES-IS I guess if you don't like ARP, I suppose you could just send IP packets whose IP address was not resolved to the MAC broadcast address, keep some maximum number of such packets outstanding to a given destination IP address within some time period and learn mac addresses from incoming IP packets. Routers would be automatically discovered. This fails in the case of a multihomed host with asymmetric routes. And the overhead is not inconsequential. Why does it fail in the case of a multihomed host with asymmetric routes? Because you may never seen return traffic from that IP address on that media. I assume you mean that the host which must send an IP packet to an IP host whose IP address has not been resolved has multiple network interfaces attaching to separate communications subnets which correspond to separate IP subnetworks. There are two possibilities for this multihomed source host. Either the multihomed source home is routing or it is not. If the multihomed source host is routing, this host is acquiring information about network connectivity through the routing protocols and the lack of arp is not a problem in the example you cite. If the multihomed source host is not routing, it would be an error for the return traffic to the source IP address to appear on another IP interface (unless that interface happen to be on an intermediate network hop to the correct source IP interface) and would indicate a topological misconfiguration which would probably cause problems even if the arp protocol were supported. Tony Joachim Carlo Santos Martillo Ajami The article represents noone's opinions other than the author's. From owner-Big-Internet@munnari.oz.au Tue Feb 16 11:39:08 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA19305; Tue, 16 Feb 1993 11:39:24 +1100 (from owner-Big-Internet) Return-Path: Received: from iitmax.acc.iit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19296; Tue, 16 Feb 1993 11:39:08 +1100 (from nelsgar@elof.iit.edu) Received: from elof.iit.edu by iitmax.acc.iit.edu with SMTP id AA06492 (5.64+/IDA/NIU-1.3.1 for big-internet@munnari.oz.au); Mon, 15 Feb 93 18:38:32 -0600 Received: by elof.iit.edu (NX5.67c/NX3.0S) id AA04086; Mon, 15 Feb 93 18:38:30 -0600 Date: Mon, 15 Feb 93 18:38:30 -0600 From: Gary Nelson Message-Id: <9302160038.AA04086@elof.iit.edu> To: martillo@nero.clearpoint.com, yakov@watson.ibm.com Subject: Re: Metro Addressing Summary Cc: Christian.Huitema@sophia.inria.fr, big-internet@munnari.oz.au Thanks for sharing this important subject with me. I now have a good sendse of the work being done, and now I must respectfully ask to be retired from the distributrion list. Thanks very much, and keep up the excellent work. We'll cross pathes again. Best wishes gn From owner-big-internet@munnari.oz.au Tue Feb 16 14:26:35 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA24975; Tue, 16 Feb 1993 14:26:59 +1100 (from owner-big-internet) Return-Path: Received: from motgate.mot.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16834; Tue, 16 Feb 1993 10:19:04 +1100 (from lambert@phx.sectel.mot.com) Received: from pobox.mot.com ([129.188.137.100]) by motgate.mot.com with SMTP (5.65c/IDA-1.4.4/MOT-2.6 for ) id AA05002; Mon, 15 Feb 1993 17:18:29 -0600 Received: from phx.sectel.mot.com ([192.94.147.2]) by pobox.mot.com with SMTP (5.65c/IDA-1.4.4/MOT-2.6) id AA10978; Mon, 15 Feb 1993 17:18:26 -0600 Received: from oasis.sectel by phx.sectel.mot.com (4.1/SMI-4.1) id AA07015; Mon, 15 Feb 93 16:18:07 MST Date: Mon, 15 Feb 93 16:18:07 MST From: lambert@phx.sectel.mot.com (Paul Lambert) Message-Id: <9302152318.AA07015@ phx.sectel.mot.com> To: big-Internet@munnari.oz.au, atkinson@tengwar.itd.nrl.navy.mil Subject: Re: Metro addressing & Re: Address uniqueness Cc: ipsec@ans.net Ran, I have just a small clarification on your comments on network security protocols. > II. > On an unrelated note, let me explain quickly why security folks like > to have unique absolute addresses. The term "EID" means different > things to different people and so I'm not going to try to talk in > terms of EIDs here. I also still don't fully understand all parts of > PIP so I won't address it here either. PIP appears to be non-trivial > to secure, but perhaps that is because I don't understand PIP well > enough. > > The existing security protocols (SP3 and ISO NLSP) use frame > encapsulation to provide protection; I won't address either > specifically, but will try to describe a generic process. One takes > the real network layer datagram and protects using a transformation > that is reversible and provides some security properties (e.g. > confidentiality, authentication, integrity). One then treats the > output of that transformation as payload and puts it into a new > network layer datagram with a normal unprotected network header. > The protected information _cannot_ be modified or altered whilst in > transit without that modification causing the back transformation to > fail. The information in the unprotected header should not be > altered whilst in transit (except maybe a TTL field). At the receive > end, the protected data is transformed back into normal form for > processing. However the process of unprotecting it might rely on the > values of fields in the unprotected header to give clues as to how to > unprotect it (e.g. data from system A might use one kind of > transformation while data from system B might use a different kind of > transformation). > > Ran > atkinson@itd.nrl.navy.mil > Both SP3 (Security Protocol Layer 3) and NLSP (Network layer Security Protocol - ISO-IEC 11577) have variable length fields that are used to determine how a datagram should be unprotected. The Security Association Identifier (SAID, Key ID in SP3) determines the algorithm, cryptographic key, and all other information required to decrypt the protected information. These protocols do not rely on any information from lower layers. Except, ... for a mutant option of connection-oriented NLSP that uses the address information from an X.25 connection to determine the "security association". Paul From owner-Big-Internet@munnari.oz.au Tue Feb 16 16:32:21 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA28961; Tue, 16 Feb 1993 16:33:04 +1100 (from owner-Big-Internet) Return-Path: Received: from Sun.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28946; Tue, 16 Feb 1993 16:32:21 +1100 (from Bob.Hinden@Eng.Sun.COM) Received: from Eng.Sun.COM (zigzag-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA10692; Mon, 15 Feb 93 21:32:01 PST Received: from bigriver.Eng.Sun.COM (bigriver-248) by Eng.Sun.COM (4.1/SMI-4.1) id AA01720; Mon, 15 Feb 93 21:36:41 PST Received: by bigriver.Eng.Sun.COM (4.1/SMI-4.1) id AA08518; Mon, 15 Feb 93 21:31:58 PST Date: Mon, 15 Feb 93 21:31:58 PST From: Bob.Hinden@Eng.Sun.COM (Bob Hinden) Message-Id: <9302160531.AA08518@bigriver.Eng.Sun.COM> To: peter@goshawk.lanl.gov Cc: big-internet@munnari.oz.au, Bob.Hinden@Eng.Sun.COM In-Reply-To: <9302150022.AA19490@goshawk.lanl.gov> Subject: Re: Metro Addressing Content-Length: 739 Peter, I am not sure we are disagreeing. I agree that individual sites can be asked to change their addresses. I was responding to Paul's assertion that global renumbering could be made on a regular basis. I continue to be doubtful that this can be done successfully on a scale large enough to be part of an addressing architecture. Many problems come to mind. For example, during the period of transition there would need to be twice the number of network numbers used. Each host would have to be reachable by its new and old address. Can all hosts support two addresses on the same interface? Routers? The old address would have to kept around for a considerable time to allow everyone else to learn about the new address. Bob From owner-big-internet@munnari.oz.au Tue Feb 16 20:01:56 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AB05212; Tue, 16 Feb 1993 20:02:08 +1100 (from owner-big-internet) Return-Path: Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03773; Tue, 16 Feb 1993 19:14:49 +1100 (from tli@cisco.com) Received: by lager.cisco.com; Tue, 16 Feb 1993 00:14:21 -0800 Date: Tue, 16 Feb 1993 00:14:21 -0800 From: Tony Li Message-Id: <199302160814.AA03942@lager.cisco.com> To: martillo@nero.clearpoint.com Cc: bill.simpson@um.cc.umich.edu, big-internet@munnari.oz.au, martillo@nero.clearpoint.com In-Reply-To: Joachim Carlo Santos Martillo Ajami's message of Mon, 15 Feb 93 11:09:26 EST <9302151609.AA11872@nero.clearpoint.com> Subject: ARP versus ES-IS If the multihomed source host is routing, this host is acquiring information about network connectivity through the routing protocols and the lack of arp is not a problem in the example you cite. How do the routers on the respective media acquire the media address? Let's draw a picture: A ------------- H --------- B Where A and B are routers and H is our host. How does A get the media address of H? H can participate in routing and not send out a single packet on the media in common with A. If the multihomed source host is not routing, it would be an error for the return traffic to the source IP address to appear on another IP interface (unless that interface happen to be on an intermediate network hop to the correct source IP interface) and would indicate a topological misconfiguration which would probably cause problems even if the arp protocol were supported. Funny, it works just fine today. Just install a host route in the router and away you go. Tony From owner-Big-Internet@munnari.oz.au Wed Feb 17 01:21:20 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA13773; Wed, 17 Feb 1993 01:22:28 +1100 (from owner-Big-Internet) Return-Path: Received: from thumper.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13725; Wed, 17 Feb 1993 01:21:20 +1100 (from tsuchiya@thumper.bellcore.com) Received: from chiya.bellcore.com by thumper.bellcore.com (4.1/4.7) id for big-internet@munnari.oz.au; Tue, 16 Feb 93 09:20:55 EST Received: by chiya.bellcore.com (4.1/4.7) id for tsuchiya@thumper.bellcore.com; Tue, 16 Feb 93 09:20:53 EST Date: Tue, 16 Feb 93 09:20:53 EST From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Message-Id: <9302161420.AA05771@chiya.bellcore.com> To: Bob.Hinden@Eng.Sun.COM, peter@goshawk.lanl.gov Subject: Re: Metro Addressing Cc: big-internet@munnari.oz.au, tsuchiya@thumper.bellcore.com > > You are right that it is hard for a site to see how this can help > them, which is a good reason for the leadership of the Internet should > get out there and promote CIDR and renumbering as a reasonable and > tractable way of helping the Internet continue to grow. > > I suspect there is sufficient community effort out there that this > is not as big a deal as is being presented. > I've heard the story that the only way to get folks to go from whatever-it-was (NCP?) to TCP was by shutting NCP out of the backbones...... Well, threatening to cut off service is not such a good thing to do, but....... PX it right the first time is small enough that we should engineer as though we'll have to renumber eventually.... If we have renumbering capability (ie, auto prefix admin in private domains), then it *should* be easier to renumber 10^9 hosts than what we have now.... > > I have a hard time imagining that all sites can be convinced to renumber > at approximately the same time to solve a global internet problem. Sort > of like asking all telephone subscribers to change their telephone > numbers because the inter-exchange carriers decide to upgrade to SS8. I > just don't see it as possible. Large global changes like this will, > IMHO, be impossible. There are (at least) two differences between the the phone company case and our case. We have an advantage in that the address change is hidden behind subscribers, so it is invisible to almost everybody. They have an advantage that the change is limited to a relatively small number of machines (phone switches.....compared to the number of hosts in the internet.....). In any event, the phone company is perfectly able to renumber *millions* of customers at a time. It is painful, but it can be done...... PX From owner-Big-Internet@munnari.oz.au Wed Feb 17 02:25:03 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15547; Wed, 17 Feb 1993 02:26:09 +1100 (from owner-Big-Internet) Return-Path: Received: from thumper.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15524; Wed, 17 Feb 1993 02:25:03 +1100 (from tsuchiya@thumper.bellcore.com) Received: from chiya.bellcore.com by thumper.bellcore.com (4.1/4.7) id for Big-Internet@munnari.oz.au; Tue, 16 Feb 93 10:24:44 EST Received: by chiya.bellcore.com (4.1/4.7) id for Big-Internet@munnari.oz.au; Tue, 16 Feb 93 10:24:39 EST Date: Tue, 16 Feb 93 10:24:39 EST From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Message-Id: <9302161524.AA06064@chiya.bellcore.com> To: Big-Internet@munnari.oz.au Subject: addressing bof...... Bill Manning volunteered to document an addressing bof for columbus. (I would have said that Bill graciously volunteered, but, email being a limited medium, I don't know if he was gracious or not... :-) Before I send mail to cnri to see if it can be arranged, I'd like to see who will committ to having documentation and giving presentations. I'll present on pure provider-based. Tony, can you do something on you're scheme? Also, someone from sip and someone from tuba would be good..... It seems to me that, no matter what scheme is chosen, the assigner will have to have some recognized authority, so it would be good if somebody that can speak to this would be there.....Vint????? Finally, we really want the provider perspective..... In any event, the purpose of the meeting is to try to clearly delineate the pros and cons of the various schemes, and to document them....... PX From owner-Big-Internet@munnari.oz.au Wed Feb 17 02:23:12 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15501; Wed, 17 Feb 1993 02:24:16 +1100 (from owner-Big-Internet) Return-Path: Received: from [128.127.2.105] by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15475; Wed, 17 Feb 1993 02:23:12 +1100 (from kasten@ftp.com) Received: by ftp.com id AA08326; Tue, 16 Feb 93 10:21:09 -0500 Date: Tue, 16 Feb 93 10:21:09 -0500 Message-Id: <9302161521.AA08326@ftp.com> To: tli@cisco.com Subject: Re: ARP versus ES-IS From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: bill.simpson@um.cc.umich.edu, big-internet@munnari.oz.au > Could all you ES-IS fans tell me what's bad about ARP? > > No router discovery. No black hole detection. Real fun when > mixed-media bridging gets involved. No autoconfiguration. > > What would we do in a perfect world? an imperfect world? > > No media addresses inside of packets. > Router discovery/blackhole detection/failover protocol/default router. > Automatic address assignment. > Media level redirects. > Optimal route query. Tony, Out of curiosity, would you put all this into ARP++, or perhaps develop some low-level, medium-oriented protocol and a higher-level, IP-Host/IP-Router protocol? I wonder about the partitioning of the problem. The functions seem "right". -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From owner-Big-Internet@munnari.oz.au Wed Feb 17 02:32:08 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15704; Wed, 17 Feb 1993 02:33:11 +1100 (from owner-Big-Internet) Return-Path: Received: from thumper.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15684; Wed, 17 Feb 1993 02:32:08 +1100 (from tsuchiya@thumper.bellcore.com) Received: from chiya.bellcore.com by thumper.bellcore.com (4.1/4.7) id for big-internet@munnari.oz.au; Tue, 16 Feb 93 10:31:40 EST Received: by chiya.bellcore.com (4.1/4.7) id for tli@cisco.com; Tue, 16 Feb 93 10:31:37 EST Date: Tue, 16 Feb 93 10:31:37 EST From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Message-Id: <9302161531.AA06101@chiya.bellcore.com> To: deering@parc.xerox.com, tli@cisco.com Subject: Re: addressing Cc: big-internet@munnari.oz.au > > > My current understanding of the top level debate is > > > > Person Steve Paul Tony > > Top Level Countries Metro Continent > > > > Agreed? > > Tony, > > Your table is correct for you and me, but Paul wants to put Provider at the > top, not Metro. He mentioned my claim that it would be feasible to put Metro > at the top, but he certainly does not endorse it. That's right..... :-) > > Each additional level increases the amount of fragmentation of the address > space. Hierarchical addressing will always be less address-space-efficient > than flat routing if the address assignment has to satisfy any external > criteria, such as respecting organization boundaries or provider boundaries > or geographic boundaries. The more levels of hierarchy, the greater the > inefficiency. > I agree with this statement completely in terms of address space efficiency. In terms of quality of paths found, I agree with this statement with the caveat that, if the topology is strongly hierarchical *and* the levels in the address match the physical topology, then a tall-skinny address combined with a tall-skinny topology doesn't hurt you..... PX From owner-Big-Internet@munnari.oz.au Wed Feb 17 03:05:23 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA16704; Wed, 17 Feb 1993 03:06:20 +1100 (from owner-Big-Internet) Return-Path: Received: from thumper.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16679; Wed, 17 Feb 1993 03:05:23 +1100 (from tsuchiya@thumper.bellcore.com) Received: from chiya.bellcore.com by thumper.bellcore.com (4.1/4.7) id for big-internet@munnari.oz.au; Tue, 16 Feb 93 11:04:49 EST Received: by chiya.bellcore.com (4.1/4.7) id for big-internet@munnari.oz.au; Tue, 16 Feb 93 11:04:46 EST Date: Tue, 16 Feb 93 11:04:46 EST From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Message-Id: <9302161604.AA06175@chiya.bellcore.com> To: Scott_Brim@cornell.edu, big-internet@munnari.oz.au Subject: Re: addressing > > Paul, in saying you will impose a limit on the number of top-level > providers, are you committing us to worldwide support of regulated > monopolies, and closing the door for all time (or until we redo Internet > addressing) on new innovative providers? Talk about bucking the tide of > history, guy! Who gets to decide which providers are a "reasonable choice > for the users"? The ITU??? > Gee, doesn't the "market" decide these things..... :-) But you are absolutely right. *If* there turns out to be too many providers to advertise at the top level, then I would hope that the cost of being advertised at the top level would encourage small, local access providers to not want to be advertised at the top......but, of course, one can't ensure that this will be the case. Ultimately if there are too many providers to justify being at the top, then you need a layer of hierarchy above the provider level. Perhaps I have been operating under an unspoken assumption......that is, that putting provider at the top is a feature because it gives you a handle for policy routing decisions. If it turns out that you need the layer above provider, then my inclination would be to assign numbers that make sense from a policy routing perspective, not a geographical/ political perspective. For instance, it may make sense to group providers accoring to their access restriction class, or according to the service they provide. Not knowing how the internet will look in the future, it is hard know what will be the best thing to do. If we are concerned that it will be impossible to renumber the internet in the future, then I guess we have no choice but to hedge our bets and make a stab at an appropriate top-level today. If it turns out that it is easy to renumber in the future, then we can always change to another top-level in the future is some other choice emerges as making more sense. It should be just as easy (or hard) to *change* the top level as to *add* one. But, even if we do stick in a just-in-case level above provider, I feel strongly that we should still put the provider in the address in all cases, so that we can do provider selection...... Or, perhaps I should put it another way. Perhaps I should ask those people that don't think putting provider in the address is necessary to state how they will do provider selection (both on the source and destination sides.....). PX From owner-Big-Internet@munnari.oz.au Wed Feb 17 02:58:25 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA16491; Wed, 17 Feb 1993 02:59:33 +1100 (from owner-Big-Internet) Return-Path: Received: from [128.127.2.105] by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16459; Wed, 17 Feb 1993 02:58:25 +1100 (from kasten@ftp.com) Received: by ftp.com id AA09730; Tue, 16 Feb 93 10:55:24 -0500 Date: Tue, 16 Feb 93 10:55:24 -0500 Message-Id: <9302161555.AA09730@ftp.com> To: tsuchiya@thumper.bellcore.com Subject: Addressing Bof (was re: addressing) From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: tli@cisco.com, big-internet@munnari.oz.au, deering@parc.xerox.com > Is there an existing forum where discussion of this makes sense? > If not, do people think creating a bof for this is a good idea? In a word, YES! (sorry for shouting) One observation that I will make, we have two main types of addressing being discussed (metro/geographic and provider/network-topology). Much of the discussion has been circular ("this is wrong with A", "this is wrong with B" , or so it seems to me). When discussions get like this, it is often an indication that some kind of brick wall has been reached, that perhaps some new viewpoints or thoughts or ideas or insights are needed. For example, these two schemes are "top-down" addressing, _perhaps_ looking at Noel's "bottom-up" scheme might provide the insight needed. -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From owner-Big-Internet@munnari.oz.au Wed Feb 17 02:57:26 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA16462; Wed, 17 Feb 1993 02:58:32 +1100 (from owner-Big-Internet) Return-Path: Received: from [128.127.2.105] by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16425; Wed, 17 Feb 1993 02:57:26 +1100 (from kasten@ftp.com) Received: by ftp.com id AA09737; Tue, 16 Feb 93 10:55:27 -0500 Date: Tue, 16 Feb 93 10:55:27 -0500 Message-Id: <9302161555.AA09737@ftp.com> To: atkinson@tengwar.itd.nrl.navy.mil Subject: Re: metro addressing From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: big-Internet@munnari.oz.au > P.P.S. I also think that country-based addressing is not wise because > the boundaries of countries have never been, are not now, and are not > likely to be stable. Go from continent down to locality and avoid > political quagmires.. "Locality" has problems too. Look at Berlin -- it was two localities, now it is one. Also, there is New York City where there is periodic talk of Staten Island "seceeding" from the City and forming its own new city. Localities are probably a lot more stable, it is true, than countries, but not 100% stable. -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From owner-Big-Internet@munnari.oz.au Wed Feb 17 12:54:08 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA29128; Wed, 17 Feb 1993 12:55:20 +1100 (from owner-Big-Internet) Return-Path: Received: from OERV01.er.doe.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29108; Wed, 17 Feb 1993 12:54:08 +1100 (from hitchcoc@oerv01.er.doe.gov) Received: by er.doe.gov (5.57/OER-V1.0) id AA08127; Tue, 16 Feb 93 20:49:05 -0500 Date: Tue, 16 Feb 93 20:49:05 -0500 From: hitchcoc@oerv01.er.doe.gov (Dan Hitchcock) Message-Id: <9302170149.AA08127@er.doe.gov> To: Bob.Hinden@eng.sun.com, tsuchiya@thumper.bellcore.com Subject: Re: Metro Addressing Cc: big-internet@munnari.oz.au Note that no scheme for optimizing the useflulness of addresses will last "forever". What is needed is a scheme that reduces the number of exceptions to some reasonable fraction of the total and tools to make this sort of renumbering hidden from users. Dan Hitchcock From owner-Big-Internet@munnari.oz.au Wed Feb 17 12:54:30 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA29130; Wed, 17 Feb 1993 12:55:41 +1100 (from owner-Big-Internet) Return-Path: Received: from nero.clearpoint.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29114; Wed, 17 Feb 1993 12:54:30 +1100 (from martillo@nero.clearpoint.com) Received: by nero.clearpoint.com (4.1/1.34) id AA17542; Tue, 16 Feb 93 20:45:36 EST Date: Tue, 16 Feb 93 20:45:36 EST From: martillo@nero.clearpoint.com (Joachim Carlo Santos Martillo Ajami) Message-Id: <9302170145.AA17542@nero.clearpoint.com> To: tli@cisco.com Cc: bill.simpson@um.cc.umich.edu, big-internet@munnari.oz.au, martillo@nero.clearpoint.com In-Reply-To: Tony Li's message of Tue, 16 Feb 1993 17:01:23 -0800 <199302170101.AA15228@lager.cisco.com> Subject: ARP versus ES-IS From: Tony Li To: martillo@nero.clearpoint.com In-Reply-To: Joachim Carlo Santos Martillo Ajami's message of Tue, 16 Feb 93 18:58:07 EST <9302162358.AA16126@nero.clearpoint.com> Subject: ARP versus ES-IS Ok, so let me see if I understand the algorithm: Router A has a packet to send to host H. The media address is unknown. 1) A queues the packet. 2) A sends a broadcast ping to H. 3) H responds. 4) A learns the media address from the ping reply.. 5) A forwards the packet. How does this differ from ARP? Well, I see two differences - 1) there is no new protocol 2) there is no way to do "proxy ARP" unless you can change your media address on the fly Nor would you need to do proxy arp, since there is no arp. I believe that this scheme is otherwise equivalent to ARP. Actually, I only mean that ping should be used in the case of asymmetric path selection or in the case of packet transmission and reception which is purely unidirectional. c) After spending time debugging such configurations in the AT&T national signaling network, I truly despise such configurations and recommend strongly against them, but if such a configuration is truly necessary, and I have actually run into networks where they are necessary, to some extant in a manner analogous to the handling of SNMP traps, I would recommend that router A ping H before forwarding packets to H in order to make sure H's IP layer is actually up and running (successfully arp'ing H would not prove anything because of the possibility of a proxy). The automatic ping procedure would probably facilitate early detection and isolation of network anomalies. The ping procedure would also have forced address resolution before the actual transmission of IP packets. While I agree that asymmetric paths are NO fun to debug, they are frequently necessary, usually for non-technical reasons. If the multihomed source host is not routing, it would be an error for the return traffic to the source IP address to appear on another IP interface (unless that interface happen to be on an intermediate network hop to the correct source IP interface) and would indicate a topological misconfiguration which would probably cause problems even if the arp protocol were supported. Funny, it works just fine today. Just install a host route in the router and away you go. This response makes me wonder how long you have been in this business. Just over 2 years. But then again, I am a "very junior computer networking engineer". I don't do anything important. I just write routing protocols. Lots of people write routing protocols and they have been doing it for decades. It is nothing special. I have been in the business for 18 years. Now 18 years of experience does not mean I have any more insight into computer networking than someone with less experience (and I have certainly run into people with more experience who did not have a clue in the field), Congratulations. but I have run into IP implementations for PC AT's running Xenix and DOS, Prime Series 50s, DG machines, Wang Machines, IBM machines and some controller-based VAX VMS implementations where the host route hack would not work at all. Fine. They're broken when they are multihomed. I am not sure that they are broken. Why do you believe they are? Obviously by definition a router accepts IP packets on an IP interface which are not addressed to that IP interface, but which are addressed to the comms subnet interface to which the IP interface corresponds. But if the host is not a router, should that host accept IP packets not addressed to a given IP interface which are contained in frames addressed at the link layer to the associated comms subnet interface? Is this written into a requirements document somewhere? And if so, what was the logic behind making this requirement (I could identify cases mostly in security related areas and in the case of routing devices which contain logical subrouters [obviously not really a case of a multihomed host which does not route between its network interfaces but rather a similar case where distinct IP layers are necessary] where such a requirement would not be a good thing). That's also irrelevant. Other implementation work _just fine_ this way. It just might be that in those installations where multihoming works as you suggest associated anomalous behaviour has not been detected or if it has, it has not been yet associated with this particular definition of multihoming. The fact that these implementations are common would suggest that it is a useful capability that we should carry into IPv7. It might just mean that this definition of multihoming is found in some very common PD tcp/ip distributions. A lot of bugs have become very common in the same manner. The argument proves nothing. The issue is a question of interpretation. No, it's a question of what works. If this is your argument, the allegedly "common" implementations should be subjected to strict mathematical verification. Tony Joachim Carlo Santos Martillo Ajami The article represents noone's opinions other than the author's. From owner-Big-Internet@munnari.oz.au Wed Feb 17 15:00:20 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA02819; Wed, 17 Feb 1993 15:05:24 +1100 (from owner-Big-Internet) Return-Path: Received: from nero.clearpoint.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02712; Wed, 17 Feb 1993 15:00:20 +1100 (from martillo@nero.clearpoint.com) Received: by nero.clearpoint.com (4.1/1.34) id AA17840; Tue, 16 Feb 93 22:51:24 EST Date: Tue, 16 Feb 93 22:51:24 EST From: martillo@nero.clearpoint.com (Joachim Carlo Santos Martillo Ajami) Message-Id: <9302170351.AA17840@nero.clearpoint.com> To: tli@cisco.com Cc: bill.simpson@um.cc.umich.edu, big-internet@munnari.oz.au, martillo@nero.clearpoint.com In-Reply-To: Tony Li's message of Tue, 16 Feb 1993 18:18:02 -0800 <199302170218.AA18212@lager.cisco.com> Subject: ARP versus ES-IS From: Tony Li In-Reply-To: Joachim Carlo Santos Martillo Ajami's message of Tue, 16 Feb 93 20:45:36 EST <9302170145.AA17542@nero.clearpoint.com> Subject: ARP versus ES-IS Fine. They're broken when they are multihomed. I am not sure that they are broken. Why do you believe they are? RFC 1122, page 62: (A) A host MAY silently discard an incoming datagram whose destination address does not correspond to the physical interface through which it is received. They are broken in the sense that they do not perform this MAY clause. I find that the "MAY" clause is requirement in my application. Doesn't this passage say that both implementations of multihomed hosts are permissible? If your implementation of your application requires that a host not silently discard an incoming datagram whose destination address does not correspond to the physical interface through which it is received, I would suggest that either you should redesign your implementation to work with both sorts of multihomed hosts or you should make sure a big caveat is included in the documentation to the effect that some perfectly valid implementations of multihomed hosts will not work with your application as it is implemented. And by the way, if you implement your application under the assumption that a multihomed host *always* silently discards an incoming datagram whos destination address does not correspond to the physical interface through which it is received, your application will probably work with all valid multihomed hosts unless of course your application is somehow intrinsically intertwined with the non-discarding model of multihomed hosts. Tony Joachim Carlo Santos Martillo Ajami The article represents noone's opinions other than the author's. From owner-big-internet@munnari.oz.au Wed Feb 17 16:44:19 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA06718; Wed, 17 Feb 1993 16:44:22 +1100 (from owner-big-internet) Return-Path: Received: from thumper.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16033; Wed, 17 Feb 1993 02:46:11 +1100 (from tsuchiya@thumper.bellcore.com) Received: from chiya.bellcore.com by thumper.bellcore.com (4.1/4.7) id for big-internet@munnari.oz.au; Tue, 16 Feb 93 10:45:33 EST Received: by chiya.bellcore.com (4.1/4.7) id for dcrocker@Mordor.Stanford.EDU; Tue, 16 Feb 93 10:45:26 EST Date: Tue, 16 Feb 93 10:45:26 EST From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Message-Id: <9302161545.AA06138@chiya.bellcore.com> To: avalon@coombs.anu.edu.au, dcrocker@Mordor.Stanford.EDU Subject: Re: Relative Addressing Cc: big-internet@munnari.oz.au > > Based upon the kinds of problems I've seen with the use of "variable" > domain name length in email administrations, I'd strongly recommend > against such a scheme. Using the full, globally unique string ALWAYS > simplifies operations and management massively. > I won't argue that partial addresses is more complex. But, in the case of working with Pip, at least, there are two comments I want to make. First, the ID at least allows end systems to know if what they got is really for them, even if the address is partial. Second, there may some benefits to using only the "private" part of the address for internal operation......you get some (though never complete) isolation from external influences (like address changes). ....... PX From owner-big-internet@munnari.oz.au Wed Feb 17 16:54:46 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA07082; Wed, 17 Feb 1993 16:54:51 +1100 (from owner-big-internet) Return-Path: Received: from [128.127.2.105] by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16941; Wed, 17 Feb 1993 03:17:24 +1100 (from kasten@ftp.com) Received: by ftp.com id AA10612; Tue, 16 Feb 93 11:14:25 -0500 Date: Tue, 16 Feb 93 11:14:25 -0500 Message-Id: <9302161614.AA10612@ftp.com> To: tli@cisco.com Subject: Re: addressing From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: big-internet@munnari.oz.au, deering@parc.xerox.com > > Political boundaries have little to do with topology. > > Neither do continental boundaries, as your example of South American > connectivity shows. However, I think that as Internet service becomes > ubiquitous, aggregation by country will work quite well, from a quality-of- > routing perspective. > > True. But as Internet service becomes ubiquitous, the continental > boundaries again become natural barriers to connectivity and thus > provide demarcation of topology. I read this as saying that "eventually, continental boundaries will start to closely approximate provider boundaries". Is this what you mean? > Yes. That's why I advocate putting countries at the top level. I was > describing a *feasible* approach, not necessarily a *good* approach. > (We seem to be having trouble communicating, but I don't know if the > problem is at the sender or the receiver.) > > At the receiver. I'm confused. My current understanding of the top > level debate is > > Person Steve Paul Tony > Top Level Countries Metro Continent > > Agreed? If this is the case, then you three want geographical-based addressing and "merely" differ as to where the top of the geography is? -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From owner-big-internet@munnari.oz.au Wed Feb 17 17:41:04 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA08541; Wed, 17 Feb 1993 17:41:09 +1100 (from owner-big-internet) Return-Path: Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20904; Wed, 17 Feb 1993 06:30:01 +1100 (from tli@cisco.com) Received: by lager.cisco.com; Tue, 16 Feb 1993 11:29:30 -0800 Date: Tue, 16 Feb 1993 11:29:30 -0800 From: Tony Li Message-Id: <199302161929.AA28006@lager.cisco.com> To: kasten@ftp.com Cc: bill.simpson@um.cc.umich.edu, big-internet@munnari.oz.au In-Reply-To: (Frank Kastenholz's message of Tue, 16 Feb 93 10:21:09 -0500 <9302161521.AA08326@ftp.com> Subject: ARP versus ES-IS Out of curiosity, would you put all this into ARP++, or perhaps develop some low-level, medium-oriented protocol and a higher-level, IP-Host/IP-Router protocol? I wonder about the partitioning of the problem. The functions seem "right". I dunno. I was worrying about functionality. I suspect that the next step really depends on which IPv7 contender is chosen. F'rinstance, if we go TUBA, I would very much want to retain ESIS (if possible -- it's not clear). If we go via SIP, I would adopt Steve's philosophy and have one minimal protocol, and one with bells and whistles. Etc. ad nauseum... Tony From owner-big-internet@munnari.oz.au Wed Feb 17 17:52:00 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA08822; Wed, 17 Feb 1993 17:52:09 +1100 (from owner-big-internet) Return-Path: Received: from ucsd.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19725; Wed, 17 Feb 1993 05:35:32 +1100 (from tots!tots.Logicon.COM!tep@UCSD.EDU) Received: from tots.UUCP by ucsd.edu; id AA04954 sendmail 5.67/UCSD-2.2-sun via UUCP Tue, 16 Feb 93 09:56:46 -0800 From: tots!tots.Logicon.COM!tep@UCSD.EDU Received: from hotspot by tots.Logicon.COM (3.2/4.17) id AA00465; Tue, 16 Feb 93 09:38:18 PST Received: by hotspot.tots.Logicon.COM (4.1/4.02-client) id AA08024; Tue, 16 Feb 93 09:53:33 PST Date: Tue, 16 Feb 93 09:53:33 PST Message-Id: <9302161753.AA08024@hotspot.tots.Logicon.COM> To: Eng.Sun.COM!Tom.Kessler@ucsd.EDU Cc: atkinson@itd.nrl.navy.mil, big-internet@munnari.oz.au In-Reply-To: Tom Kessler's message of Mon, 8 Feb 93 14:14:53 PST <9302082214.AA26557@bigriver.Eng.Sun.COM> Subject: Metro Addressing Reply-To: tep@tots.Logicon.COM X-Organization: Logicon, Inc., San Diego, California Date: Mon, 8 Feb 93 14:14:53 PST From: Eng.Sun.COM!Tom.Kessler@ucsd.EDU (Tom Kessler) Content-Length: 740 I think that for metro addressing to work well for large private internets that are connected in more than metro you need to treat all the hosts as multi-homed in terms of metro. You might think about having multiple logical network interfaces and you would choose which "interface" to use based on what gethostbyname() told you the destination was. When you look up the name from the outside you might see multiple SIP addresses for the host and you'd choose the one in the "nearest/most convenient" metro. Another possibility would be to assign a "virtual metro" id to these largish sort of networks. I would think that some heuristic like having more than 4 internet attachment points and more than 500 networks/subnets would work. I think that another way to look at this is to consider an organization that runs its own large internal network as its own "provider" and use provider-based addressing. Consider G.E. and its current class-A IP address... Tom E. Perrine (tep) | tep@Logicon.COM |Voice: +1 619 597 7221 Logicon, Inc. | sun!suntan!tots!tep | or : +1 619 455 1330 4010 Sorrento Valley Blvd| | FAX: +1 619 552 0729 San Diego CA 92121-1498 | Every child is a gifted child ! From owner-big-internet@munnari.oz.au Wed Feb 17 18:39:38 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA10267; Wed, 17 Feb 1993 18:39:43 +1100 (from owner-big-internet) Return-Path: Received: from nero.clearpoint.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26592; Wed, 17 Feb 1993 11:07:15 +1100 (from martillo@nero.clearpoint.com) Received: by nero.clearpoint.com (4.1/1.34) id AA16126; Tue, 16 Feb 93 18:58:07 EST Date: Tue, 16 Feb 93 18:58:07 EST From: martillo@nero.clearpoint.com (Joachim Carlo Santos Martillo Ajami) Message-Id: <9302162358.AA16126@nero.clearpoint.com> To: tli@cisco.com Cc: bill.simpson@um.cc.umich.edu, big-internet@munnari.oz.au, martillo@nero.clearpoint.com In-Reply-To: Tony Li's message of Tue, 16 Feb 1993 00:14:21 -0800 <199302160814.AA03942@lager.cisco.com> Subject: ARP versus ES-IS Date: Tue, 16 Feb 1993 00:14:21 -0800 From: Tony Li To: martillo@nero.clearpoint.com Cc: bill.simpson@um.cc.umich.edu, big-internet@munnari.oz.au, martillo@nero.clearpoint.com In-Reply-To: Joachim Carlo Santos Martillo Ajami's message of Mon, 15 Feb 93 11:09:26 EST <9302151609.AA11872@nero.clearpoint.com> Subject: ARP versus ES-IS If the multihomed source host is routing, this host is acquiring information about network connectivity through the routing protocols and the lack of arp is not a problem in the example you cite. How do the routers on the respective media acquire the media address? Let's draw a picture: A ------------- H --------- B Where A and B are routers and H is our host. How does A get the media address of H? H can participate in routing and not send out a single packet on the media in common with A. 1) A is forwarding the packet to H whose ip address is contained in the IP packet but which has not been resolved. 2) A sends to H using the broadcast MAC address. 3) Either (a) the path through A was the correct path bidirectionally to H from some source S several hops away or (b) another path should have been used or (c) packets are routed from S->H along one path and from H->S along a different path. a) If the path through A is correct, then H will in most cases send a packet back through A and A will resolve H's IP address to a MAC addr. (In the case of something like SNMP traps, I believe the trap source [S] should have pinged H before sending the trap in which case the ping request and response caused address resolution.) b) If the path through A is incorrect, in a correctly configured network, A should eventually get its routes updated. And the issue of A resolving H's IP address to a MAC address should not arise except as a transient error condition. c) After spending time debugging such configurations in the AT&T national signaling network, I truly despise such configurations and recommend strongly against them, but if such a configuration is truly necessary, and I have actually run into networks where they are necessary, to some extant in a manner analogous to the handling of SNMP traps, I would recommend that router A ping H before forwarding packets to H in order to make sure H's IP layer is actually up and running (successfully arp'ing H would not prove anything because of the possibility of a proxy). The automatic ping procedure would probably facilitate early detection and isolation of network anomalies. The ping procedure would also have forced address resolution before the actual transmission of IP packets. If the multihomed source host is not routing, it would be an error for the return traffic to the source IP address to appear on another IP interface (unless that interface happen to be on an intermediate network hop to the correct source IP interface) and would indicate a topological misconfiguration which would probably cause problems even if the arp protocol were supported. Funny, it works just fine today. Just install a host route in the router and away you go. This response makes me wonder how long you have been in this business. I have been in the business for 18 years. Now 18 years of experience does not mean I have any more insight into computer networking than someone with less experience (and I have certainly run into people with more experience who did not have a clue in the field), but I have run into IP implementations for PC AT's running Xenix and DOS, Prime Series 50s, DG machines, Wang Machines, IBM machines and some controller-based VAX VMS implementations where the host route hack would not work at all. The issue is a question of interpretation. For simplicity ignore the case where routers and devices which support routing might actually contain multiple subrouters. A router has a single IP layer associated with multiple network interfaces. One can argue -- and certainly many implementations work in this way -- that a multihomed host which is not supposed to route should actually have a separate IP layer associated with each IP interface. From this perspective, an implementation for which the host route hack worked is actually doing a limited amount of internal routing. There is a way to get the host route hack to work even if there is a separate IP layer for each network interface. Each interface would get assigned all the host network addresses, but that approach is not aesthetically appealing. By the way, I am not actually arguing for the elimination of ARP. I consider this discussion just an exercise in trying to understand why a given architecture contains the features which it does. When I was teaching at Harvard, I often assigned my students such exercises. In point of fact, I consider creating a virtual network layer and resolving virtual network addresses to physical network addresses to be naturally partitioned problems (IP is one way of addressing the first problem while ARP is one way of addressing the second problem). Tony Joachim Carlo Santos Martillo Ajami The article represents noone's opinions other than the author's. From owner-big-internet@munnari.oz.au Wed Feb 17 19:19:45 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA11401; Wed, 17 Feb 1993 19:19:59 +1100 (from owner-big-internet) Return-Path: Received: from vela.acs.oakland.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26631; Wed, 17 Feb 1993 11:10:05 +1100 (from bill.simpson@um.cc.umich.edu) Received: from via.ws07.merit.edu by vela.acs.oakland.edu with SMTP id AA20182 (5.65c+/IDA-1.4.4); Tue, 16 Feb 1993 19:09:37 -0500 Date: Tue, 16 Feb 93 16:48:52 EDT From: "William Allen Simpson" Message-Id: <962.bill.simpson@um.cc.umich.edu> To: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Cc: big-internet@munnari.oz.au Reply-To: bsimpson@morningstar.com Subject: Re: Metro Addressing > In any event, the phone company is perfectly able to renumber *millions* > of customers at a time. It is painful, but it can be done...... > Sure, North Korea just did it by decree yesterday. Of course, the reported reason was to make it hard for anyone to find anyone else. Bill.Simpson@um.cc.umich.edu From owner-big-internet@munnari.oz.au Wed Feb 17 21:42:04 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15030; Wed, 17 Feb 1993 21:42:06 +1100 (from owner-big-internet) Return-Path: Received: from ucsd.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20975; Wed, 17 Feb 1993 06:35:17 +1100 (from tots!tots.Logicon.COM!tep@UCSD.EDU) Received: from tots.UUCP by ucsd.edu; id AA12396 sendmail 5.67/UCSD-2.2-sun via UUCP Tue, 16 Feb 93 10:56:24 -0800 From: tots!tots.Logicon.COM!tep@UCSD.EDU Received: from hotspot by tots.Logicon.COM (3.2/4.17) id AA00516; Tue, 16 Feb 93 09:48:07 PST Received: by hotspot.tots.Logicon.COM (4.1/4.02-client) id AA08064; Tue, 16 Feb 93 10:03:22 PST Date: Tue, 16 Feb 93 10:03:22 PST Message-Id: <9302161803.AA08064@hotspot.tots.Logicon.COM> To: coombs.anu.edu.au!avalon@ucsd.EDU Cc: big-internet@munnari.oz.au In-Reply-To: Darren Reed's message of Sat, 13 Feb 93 22:52:01 EST <9302131152.AA10138@coombs.anu.edu.au> Subject: Relative Addressing Reply-To: tep@tots.Logicon.COM X-Organization: Logicon, Inc., San Diego, California From: coombs.anu.edu.au!avalon@ucsd.EDU (Darren Reed) Date: Sat, 13 Feb 93 22:52:01 EST Reply-To: ucsd!coombs.anu.edu.au!avalon X-Mailer: ELM [version 2.3 PL11] Is there any reason why everyone wants to use complete, absolute addresses in packets and not a nice relative address ? How often do you use your absolute mail address when sending email ? For email, you can get away with "joe@cray" or "joe@cray.cs" and surface mail is similar (you don't need to put in the country or state if you send your neighbour mail). (What do I mean by 'relative address' ? An address which is essentially the route to take to reach the endpoint, similar to those used by PIP in the RD and RH fields). > This is something that has been in UUCP forever, of course, and has caused numerous problems. Why should the end-user system need to compute routes? That is what the service provider's infrastructure is for. Also, this is hell for mobile sites. The people with laptops and modems are finding this out; there are new standards coming from BellCore about telephone numbers because of it. (The new standard will require the local phone company to accept +1-areacodelocal-number for local calls, so that your laptop's phone book doens't have to know what area code it is in.) Darren Tom E. Perrine (tep) | tep@Logicon.COM |Voice: +1 619 597 7221 Logicon, Inc. | sun!suntan!tots!tep | or : +1 619 455 1330 4010 Sorrento Valley Blvd| | FAX: +1 619 552 0729 San Diego CA 92121-1498 | Every child is a gifted child ! From owner-big-internet@munnari.oz.au Wed Feb 17 22:00:37 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15435; Wed, 17 Feb 1993 22:00:44 +1100 (from owner-big-internet) Return-Path: Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21609; Wed, 17 Feb 1993 07:11:53 +1100 (from tli@cisco.com) Received: by lager.cisco.com; Tue, 16 Feb 1993 12:11:29 -0800 Date: Tue, 16 Feb 1993 12:11:29 -0800 From: Tony Li Message-Id: <199302162011.AA00890@lager.cisco.com> To: kasten@ftp.com Cc: big-internet@munnari.oz.au, deering@parc.xerox.com In-Reply-To: (Frank Kastenholz's message of Tue, 16 Feb 93 11:14:25 -0500 <9302161614.AA10612@ftp.com> Subject: addressing > True. But as Internet service becomes ubiquitous, the continental > boundaries again become natural barriers to connectivity and thus > provide demarcation of topology. I read this as saying that "eventually, continental boundaries will start to closely approximate provider boundaries". Is this what you mean? Not quite. Eventually things will start to look a lot like the US today: within the continent there are lots of providers, but all of them are interconnected with links on the continent itself. The intercontinental links will be less common than intracontinental links simply due to cost. Thus, this provides a convenient "cut set" in the graph. Tony From owner-big-internet@munnari.oz.au Wed Feb 17 22:14:14 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15821; Wed, 17 Feb 1993 22:14:19 +1100 (from owner-big-internet) Return-Path: Received: from thumper.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21853; Wed, 17 Feb 1993 07:28:30 +1100 (from tsuchiya@thumper.bellcore.com) Received: from chiya.bellcore.com by thumper.bellcore.com (4.1/4.7) id for big-internet@munnari.oz.au; Tue, 16 Feb 93 15:28:12 EST Received: by chiya.bellcore.com (4.1/4.7) id for tsuchiya@thumper.bellcore.com; Tue, 16 Feb 93 15:28:10 EST Date: Tue, 16 Feb 93 15:28:10 EST From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Message-Id: <9302162028.AA06824@chiya.bellcore.com> To: Scott_Brim@cornell.edu, tsuchiya@thumper.bellcore.com Subject: Re: addressing bof...... Cc: big-internet@munnari.oz.au Scott Brim has graciously (in Scott's case, I'm sure it was gracious, as Scott is nothing if not gracious :-) offered to coordinate the ordering of Pizza for the addressing BOF, if it turns out to be an evening event....... Thank-you Scott, PX From owner-big-internet@munnari.oz.au Wed Feb 17 22:32:28 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA16293; Wed, 17 Feb 1993 22:32:42 +1100 (from owner-big-internet) Return-Path: Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22835; Wed, 17 Feb 1993 08:20:20 +1100 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <11565>; Tue, 16 Feb 1993 13:19:40 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Tue, 16 Feb 1993 13:19:34 -0800 To: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Cc: Big-Internet@munnari.oz.au, deering@parc.xerox.com Subject: Re: addressing bof...... In-Reply-To: Your message of "Tue, 16 Feb 93 07:24:39 PST." <9302161524.AA06064@chiya.bellcore.com> Date: Tue, 16 Feb 1993 13:19:32 PST Sender: Steve Deering From: Steve Deering Message-Id: <93Feb16.131934pst.12171@skylark.parc.xerox.com> > I'll present on pure provider-based. Tony, can you > do something on you're scheme? Also, someone from > sip and someone from tuba would be good..... I'd be happy to present metro-based addressing, and I've been meaning to write it up for over a year now, so this will serve as extra impetus. Categorizing it into Pip vs SIP vs TUBA is wrong, if that's what you had in mind. The addressing hierarchy issues are largely orthogonal to the choice of packet format. Steve From owner-Big-Internet@munnari.oz.au Wed Feb 17 23:41:52 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17896; Wed, 17 Feb 1993 23:42:14 +1100 (from owner-Big-Internet) Return-Path: Received: from mitsou.inria.fr by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17883; Wed, 17 Feb 1993 23:41:52 +1100 (from huitema@mitsou.inria.fr) Received: by mitsou.inria.fr (5.65c/IDA-1.2.8) id AA05124; Wed, 17 Feb 1993 13:44:37 +0100 Message-Id: <199302171244.AA05124@mitsou.inria.fr> To: Tony Li Cc: big-internet@munnari.oz.au Subject: Re: addressing In-Reply-To: Your message of "Tue, 16 Feb 93 12:11:29 PST." <199302162011.AA00890@lager.cisco.com> Date: Wed, 17 Feb 93 13:44:36 +0100 From: Christian Huitema Tony, A continent is a very arbitrary abstraction. The fact that there is a North American Free trade zone that matches the continent boundaries is an historical exception. If you look at former empires, e.g. Persian, Greek, Roman, Arabic, Carolingian, German, Spanish-Austrian, Russian, Mongol, Turkish, British, French, you name it, you will observe that their boundaries almost never coincidated with continents: there would be a little bit of Europe, part of Africa and some of Asia, or nearly all of Europe but not England or not France, or a chunk of Russia + part of China and some of the middle East -- you can find example for almost all combinations. There are good reasons to that. For example, communications will more easily cross seas than travel around deserts of mountains, or would rather follow language groups than geographical proximity. Having a "continental" top level in the Internet is thus essentially useless. It would not be useful now (want to coordinate Lybia and South-Africa?), and as only very scarce chances to become useful at any point in the future. Christian Huitema From owner-big-internet@munnari.oz.au Thu Feb 18 00:06:30 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA18756; Thu, 18 Feb 1993 00:06:36 +1100 (from owner-big-internet) Return-Path: Received: from thumper.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23347; Wed, 17 Feb 1993 08:44:14 +1100 (from tsuchiya@thumper.bellcore.com) Received: from chiya.bellcore.com by thumper.bellcore.com (4.1/4.7) id for Big-Internet@munnari.oz.au; Tue, 16 Feb 93 16:42:30 EST Received: by chiya.bellcore.com (4.1/4.7) id for tsuchiya@thumper.bellcore.com; Tue, 16 Feb 93 16:42:28 EST Date: Tue, 16 Feb 93 16:42:28 EST From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Message-Id: <9302162142.AA07037@chiya.bellcore.com> To: deering@parc.xerox.com, tsuchiya@thumper.bellcore.com Subject: Re: addressing bof...... Cc: Big-Internet@munnari.oz.au > > > I'll present on pure provider-based. Tony, can you > > do something on you're scheme? Also, someone from > > sip and someone from tuba would be good..... > > I'd be happy to present metro-based addressing, and I've been meaning > to write it up for over a year now, so this will serve as extra impetus. THanks, > > Categorizing it into Pip vs SIP vs TUBA is wrong, if that's what you had > in mind. The addressing hierarchy issues are largely orthogonal to the > choice of packet format. > Yes, that's right. I just thought that maybe the tuba folks would have an addressing scheme in mind that is different from what you and I and Tony are describing...... Tony....haven't heard from you yet... PX From owner-big-internet@munnari.oz.au Thu Feb 18 01:19:20 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21360; Thu, 18 Feb 1993 01:19:29 +1100 (from owner-big-internet) Return-Path: Received: from thor.oar.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18064; Wed, 17 Feb 1993 23:49:00 +1100 (from henryc@oar.net) From: henryc@oar.net Received: for henryc@oar.net by thor.oar.net (5.65c+RONSKI/921206.2314) id AA04262; Wed, 17 Feb 1993 07:48:46 -0500 Date: Wed, 17 Feb 1993 07:48:46 -0500 Message-Id: <199302171248.AA04262@thor.oar.net> To: tli@cisco.com Subject: Re: addressing Cc: big-internet@munnari.oz.au >> True. But as Internet service becomes ubiquitous, the continental >> boundaries again become natural barriers to connectivity and thus >> provide demarcation of topology. > >I read this as saying that "eventually, continental boundaries will >start to closely approximate provider boundaries". Is this what you mean? That may or may not be true. Let's say provider X is doing business here in North America and wishes to connect Europe. They run a long wire across the big water and suddenly they're connected to two continents. Another provider that might do business exclusively in Europe wouldn't need such a long wire to connect a site in Asia from Europe. The point is that not all wide-area providers will only do business within one continent, and while that statement may be true in lots of cases today, it certainly won't be in the future. Henry From owner-Big-Internet@munnari.oz.au Thu Feb 18 01:33:54 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21752; Thu, 18 Feb 1993 01:34:03 +1100 (from owner-Big-Internet) Return-Path: Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21744; Thu, 18 Feb 1993 01:33:54 +1100 (from dcrocker@Mordor.Stanford.EDU) Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA09129; Wed, 17 Feb 93 06:33:45 -0800 Message-Id: <9302171433.AA09129@Mordor.Stanford.EDU> To: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Cc: Big-Internet@munnari.oz.au Subject: Re: addressing bof...... Org: The Branch Office, Sunnyvale CA Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Tue, 16 Feb 93 10:24:39 -0500. <9302161524.AA06064@chiya.bellcore.com> Date: Wed, 17 Feb 93 06:33:45 -0800 From: Dave Crocker X-Mts: smtp I've already sent a query to cnri and the Internet area directors, requesting permission. As soon as one of the AD's approve, we can coordinate on the time. Dave From owner-Big-Internet@munnari.oz.au Thu Feb 18 03:28:10 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA24940; Thu, 18 Feb 1993 03:28:19 +1100 (from owner-Big-Internet) Return-Path: Received: from chsun.chuug.ch by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24923; Thu, 18 Feb 1993 03:28:10 +1100 (from poole@magnolia.eunet.ch) Received: from magnolia.eunet.ch by chsun.chuug.ch (5.65c8/1.34) id AA19305; Wed, 17 Feb 1993 17:28:36 +0100 Message-Id: <199302171628.AA19305@chsun.chuug.ch> Received: from magnolia.eunet.ch by magnolia.eunet.ch id <00398-0@magnolia.eunet.ch>; Wed, 17 Feb 1993 17:30:28 +0100 Subject: Re: addressing To: henryc@oar.net Date: Wed, 17 Feb 1993 17:30:25 +0100 (MET) Cc: tli@cisco.com, big-internet@munnari.oz.au In-Reply-To: <199302171248.AA04262@thor.oar.net> from "henryc@oar.net" at Feb 17, 93 07:48:46 am X-Mailer: ELM [version 2.4 PL11] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 469 From: Simon Poole Sender: poole@magnolia.eunet.ch > Europe. The point is that not all wide-area providers will only do > business within one continent, and while that statement may be true > in lots of cases today, it certainly won't be in the future. It's actually not even true today, we (EUnet) do business in Europe and Africa and a couple of our competitors span more than continent. -- EUnet Switzerland Simon Poole Zweierstrasse 35 Tel: +41 1 291 45 80 CH-8004 Zuerich Fax: +41 1 291 46 42 poole@eunet.ch From owner-big-internet@munnari.oz.au Thu Feb 18 04:31:12 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA26512; Thu, 18 Feb 1993 04:31:20 +1100 (from owner-big-internet) Return-Path: Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24066; Wed, 17 Feb 1993 09:23:23 +1100 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <11816>; Tue, 16 Feb 1993 14:22:44 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Tue, 16 Feb 1993 14:22:38 -0800 To: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Cc: big-internet@munnari.oz.au, deering@parc.xerox.com Subject: Re: addressing In-Reply-To: Your message of "Tue, 16 Feb 93 08:04:46 PST." <9302161604.AA06175@chiya.bellcore.com> Date: Tue, 16 Feb 1993 14:22:28 PST Sender: Steve Deering From: Steve Deering Message-Id: <93Feb16.142238pst.12171@skylark.parc.xerox.com> > ...For instance, it may make sense to group > providers accoring to their access restriction class, or according to > the service they provide. If some users would benefit from one grouping criterion (e.g., access restriction class) and some would benefit from another (e.g., service type), would you define two parallel, top levels? (That might be reasonable -- for SIP, I am advocating both a provider top level and a country top level -- but I'd like to know if that is what you have in mind.) What if there are more than just a couple such orthogonal criteria for grouping -- would you support any number of policy-useful address clusterings? I think that expecting your address hierarchy to encode such policy considerations is overloading the notion of address; it's hard enough to design an adressing hierarchy to satisfy concerns of scaling, route quality, and administration, without adding policy concerns. > Or, perhaps I should put it another way. Perhaps I should ask > those people that don't think putting provider in the address > is necessary to state how they will do provider selection (both > on the source and destination sides.....). If a site is multihomed to multiple providers, the site's boundary router(s) may select the first-hop provider for outgoing traffic based on any number of criteria, such as QOS/flow information in the packets, mapping tables of source or destination address prefixes to specific providers, time of day, etc. If the site is singly-homed to a local-access provider, which in turn attaches to a number of different long-haul providers, the site may register its selection criteria with the local-access provider, similar to the way I register my preferred long-distance carrier with my local phone company. Hosts can override the automatic or default provider-selection mechanisms by using SIP-style "very loose" source routes, which can request routing through chunks of topology belonging to specific providers (using a provider- based portion of the address space to identify the chunks). If a receiver really wants to specify the last-hop provider for incoming packets, it can ask its correspondents to source-route through that provider. The willingness of senders to honor such requests would presumably depend on which end has to pay for the packet delivery. Steve From owner-big-internet@munnari.oz.au Thu Feb 18 04:57:05 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA27133; Thu, 18 Feb 1993 04:57:15 +1100 (from owner-big-internet) Return-Path: Received: from uu2.psi.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28244; Wed, 17 Feb 1993 12:15:56 +1100 (from craig@aland.bbn.com) Received: from port13.sunnyvale.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA05343 for big-internet@munnari.oz.au; Tue, 16 Feb 93 20:15:34 -0500 Received: by aland.bbn.com (4.1/3.1.090690-BBN) id AA05563; Tue, 16 Feb 93 17:13:21 PST Message-Id: <9302170113.AA05563@aland.bbn.com> To: big-internet@munnari.oz.au Subject: interested in reviewing an IPv7 paper? Reply-To: Craig Partridge From: Craig Partridge Date: Tue, 16 Feb 93 17:13:21 -0800 Sender: craig@aland.bbn.com Hi folks: I'm currently receiving articles about the various proposals for IPv7 for publication in IEEE Network. Our goal is to publish them in May, which means we need to turn the reviews around very fast (like, by late next week). I've got some reviewers lined up but I'm sending this out to see if anyone on this list is interested in reviewing an article? Reviewers should be willing to read carefully - IEEE Network expects careful technical reviews for accuracy, completeness and readability. Furthermore, reviews are anonymous, so you don't get any glory, just the knowledge you've helped us present the IPv7 proposals more clearly to the community at large (IEEE Network has 16,000+ subscribers) and my thanks. If you're interested, SEND A NOTE TO ME ONLY!!! (NOT THE LIST) at the address below. Thanks! Craig editor-in-chief, IEEE Network Magazine E-mail: craig@aland.bbn.com or craig@bbn.com From owner-big-internet@munnari.oz.au Thu Feb 18 05:08:40 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA27298; Thu, 18 Feb 1993 05:08:44 +1100 (from owner-big-internet) Return-Path: Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29020; Wed, 17 Feb 1993 12:49:30 +1100 (from tsuchiya@thumper.bellcore.com) Received: from thumper.bellcore.com by mulga.cs.mu.OZ.AU with SMTP (5.64+1.3.1+0.50); id AA19763 Wed, 17 Feb 1993 12:49:13 +1100 (from tsuchiya@thumper.bellcore.com) Received: from chiya.bellcore.com by thumper.bellcore.com (4.1/4.7) id for big-internet@munnari.oz.au; Tue, 16 Feb 93 20:46:25 EST Received: by chiya.bellcore.com (4.1/4.7) id for tsuchiya@thumper.bellcore.com; Tue, 16 Feb 93 20:46:24 EST Date: Tue, 16 Feb 93 20:46:24 EST From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Message-Id: <9302170146.AA07519@chiya.bellcore.com> To: deering@parc.xerox.com, tsuchiya@thumper.bellcore.com Subject: Re: addressing Cc: big-internet@munnari.oz.au > > > ...For instance, it may make sense to group > > providers accoring to their access restriction class, or according to > > the service they provide. > > If some users would benefit from one grouping criterion (e.g., access > restriction class) and some would benefit from another (e.g., service > type), would you define two parallel, top levels? (That might be reasonable > -- for SIP, I am advocating both a provider top level and a country top > level -- but I'd like to know if that is what you have in mind.) What if > there are more than just a couple such orthogonal criteria for grouping -- > would you support any number of policy-useful address clusterings? I think > that expecting your address hierarchy to encode such policy considerations > is overloading the notion of address; it's hard enough to design an > adressing hierarchy to satisfy concerns of scaling, route quality, and > administration, without adding policy concerns. Well, the reason for this kind of clustering *is* to try to maintain route quality. I wouldn't cluster for that reason alone. In general, I see address hierarchy as a necessary evil to be avoided when it isn't necessary. But, as long as you've got to have it, I think it is best to try to get extra leverage out of it. I can't answer your specific question because it is a future thing. I can easily imagine clustering according to backbone type, though (ATMs clustered together, frame relays, smds, SIPs, Pips, and whatever else we end up with). As for clustering on access restriction, I tend to think of backbones with access restrictions as (eventually) serving a relatively small percentage of the internet (I know that isn't the case today, but as commercialism increases....). So, one could easily belong to a niche backbone-cluster and a few service types backbone clusters..... PX From owner-big-internet@munnari.oz.au Thu Feb 18 05:12:05 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA27340; Thu, 18 Feb 1993 05:12:11 +1100 (from owner-big-internet) Return-Path: Message-Id: <9302171812.27340@munnari.oz.au> Received: from BBN.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26184; Wed, 17 Feb 1993 10:52:15 +1100 (from lyman@BBN.COM) From: "Lyman Chapin" Subject: Re: [Fwd] ISO wants Collaboration with Internet Community To: big-internet@munnari.oz.au Cc: iab@venera.isi.edu, iesg@cnri.reston.va.us In-Reply-To: <199302122237.AA12858@venera.isi.edu> Date: Tue, 16 Feb 93 17:46:21 EDT Mail-System-Version: Ran, Taking your comments out of order - > 3) I'd like to see an official statement from the IAB to the IETF > on just what they presented to ISO SC6. The implication is that > the IAB might be favouring TUBA by this action and I hope that is > _not_ the case. No one needs a repeat of the July IETF meeting. I circulated such a summary to the ietf list earlier today. SC6 is interested in CLNP, and the IAB sent them information about TUBA, which is the principal IETF activity that involves CLNP. I don't think this constitutes "favouring" TUBA, but I made sure in my presentation to the SC6/WG2 meeting to put TUBA in context by also describing the other related IETF work, on SIP, PIP, IPv7 criteria, etc. SC6 is not, however, engaged in standardizing SIP, PIP, or IPv7 criteria; they *are* engaged in standardizing CLNP. At this point, SC6 is a lot more interested in the Internet and its work on internetwork protocols and addressing than vice versa; but anyone who feels strongly that SC6 should be looking at PIP, for example, as a next-generation replacement for the current CLNP, please let me know! > > 1) As long as ISO SC6 makes all the decisions about CLNP, > the normally technically oriented IETF development process > won't apply to evolution of that network layer protocol. During the SC6/WG2 discussion last Thursday, the person standing in for the SC6 chairman (who has recently resigned) was instructed to find out what it would take to recognize contributions from the IAB/IETF in the same way in which SC6 recognizes contributions from IEEE (for example, IEEE does the technical development work on the 802 LAN standards, and this is adopted (with, to be fair, an occassional glitch) as-is by SC6). This led to a suggestion from several people that SC6 explicitly agree that all future technical work on CLNP will be done by a WG of the IETF. No one disagreed with this idea. I don't know whether such an arrangement will actually be made, but it's significant that a group such as SC6 would so clearly express its belief that the IETF is the right place to carry out technical work on internetworking protocols. > > IETF can make suggestions to ISO, but the past history is that > ISO has a highly political process -- much much more so > than the IETF usually does. > > 2) I really resent the manner in which people are already starting > political lobbying in favor of TUBA/ISO without fully examining > all of the alternatives on the table for their technical merits. > The next generation IP decision should be made on TECHNICAL > MERIT rather than POLITICAL CORRECTNESS. I agree. But keep in mind that Tony Whyman and most of the other people at the SC6 working group meetings last week are clear partisans for CLNP; CLNP is the ISO standard, and this was an ISO meeting of ISO people. As I said in the report I sent around earlier, much of my presentation last Thursday was designed to impress upon the SC6 participants the fact that the only way to achieve their goal is to make the case on technical grounds in the IETF - it won't happen just because SC6 can generate liaison con- tributions that point out how much simpler everything would be if the Internet would just adopt ISO's standard. > > 4) noop is not the right list for IPvN discussion. While I expect > it to be very noisy, big-internet is more nearly the right place > for IPvN general comments. > >Sincerely, > >Ran >atkinson@itd.nrl.navy.mil - Lyman From owner-big-internet@munnari.oz.au Thu Feb 18 05:22:23 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA27568; Thu, 18 Feb 1993 05:22:32 +1100 (from owner-big-internet) Return-Path: Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29669; Wed, 17 Feb 1993 13:18:39 +1100 (from tli@cisco.com) Received: by lager.cisco.com; Tue, 16 Feb 1993 18:18:02 -0800 Date: Tue, 16 Feb 1993 18:18:02 -0800 From: Tony Li Message-Id: <199302170218.AA18212@lager.cisco.com> To: martillo@nero.clearpoint.com Cc: bill.simpson@um.cc.umich.edu, big-internet@munnari.oz.au, martillo@nero.clearpoint.com In-Reply-To: Joachim Carlo Santos Martillo Ajami's message of Tue, 16 Feb 93 20:45:36 EST <9302170145.AA17542@nero.clearpoint.com> Subject: ARP versus ES-IS How does this differ from ARP? Well, I see two differences - 1) there is no new protocol 2) there is no way to do "proxy ARP" unless you can change your media address on the fly Nor would you need to do proxy arp, since there is no arp. Nor would you provide existing capabilities that proxy arp provides. I believe that this scheme is otherwise equivalent to ARP. Actually, I only mean that ping should be used in the case of asymmetric path selection or in the case of packet transmission and reception which is purely unidirectional. I see no way for any host and/or router to determine that this is the case. Thus, it must be done always. Fine. They're broken when they are multihomed. I am not sure that they are broken. Why do you believe they are? RFC 1122, page 62: (A) A host MAY silently discard an incoming datagram whose destination address does not correspond to the physical interface through which it is received. They are broken in the sense that they do not perform this MAY clause. I find that the "MAY" clause is requirement in my application. No, it's a question of what works. If this is your argument, the allegedly "common" implementations should be subjected to strict mathematical verification. Uh oh. You said the V word. No, thank you, I've already spent a lifetime worrying about mathematical correctness. I would prefer to get real work done. Tony From owner-big-internet@munnari.oz.au Thu Feb 18 05:45:55 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA28071; Thu, 18 Feb 1993 05:46:11 +1100 (from owner-big-internet) Return-Path: Received: from coombs.anu.edu.au by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16816; Wed, 17 Feb 1993 22:58:18 +1100 (from avalon@coombs.anu.edu.au) Received: by coombs.anu.edu.au (5.61/1.0) id AA22530; Wed, 17 Feb 93 22:58:02 +1100 From: avalon@coombs.anu.edu.au (Darren Reed) Message-Id: <9302171158.AA22530@coombs.anu.edu.au> Subject: Re: Relative Addressing To: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Date: Wed, 17 Feb 93 22:58:01 EST Cc: dcrocker@Mordor.Stanford.EDU, big-internet@munnari.oz.au In-Reply-To: <9302161545.AA06138@chiya.bellcore.com>; from "Paul Tsuchiya" at Feb 16, 93 10:45 am Reply-To: avalon@coombs.anu.edu.au X-Mailer: ELM [version 2.3 PL11] In some email I received from Paul Tsuchiya, Sie wrote: > > I won't argue that partial addresses is more complex. But, in the > case of working with Pip, at least, there are two comments I want > to make. First, the ID at least allows end systems to know if what > they got is really for them, even if the address is partial. Second, > there may some benefits to using only the "private" part of the > address for internal operation......you get some (though never > complete) isolation from external influences (like address changes). ....... Well only needing to know the partial address also makes it easier for mobile nets since 'inside' hosts don't need to worry about what their net number is, so a change makes no difference. Then, by building an address as a packet goes from one point to the other, you generate the right reply address (although it would not be bad if there was other support for an address change such as a redirect also). Darren. From owner-big-internet@munnari.oz.au Thu Feb 18 05:52:13 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA28158; Thu, 18 Feb 1993 05:52:37 +1100 (from owner-big-internet) Return-Path: Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27885; Wed, 17 Feb 1993 12:01:50 +1100 (from tli@cisco.com) Received: by lager.cisco.com; Tue, 16 Feb 1993 17:01:23 -0800 Date: Tue, 16 Feb 1993 17:01:23 -0800 From: Tony Li Message-Id: <199302170101.AA15228@lager.cisco.com> To: martillo@nero.clearpoint.com Cc: bill.simpson@um.cc.umich.edu, big-internet@munnari.oz.au, martillo@nero.clearpoint.com In-Reply-To: Joachim Carlo Santos Martillo Ajami's message of Tue, 16 Feb 93 18:58:07 EST <9302162358.AA16126@nero.clearpoint.com> Subject: ARP versus ES-IS Ok, so let me see if I understand the algorithm: Router A has a packet to send to host H. The media address is unknown. 1) A queues the packet. 2) A sends a broadcast ping to H. 3) H responds. 4) A learns the media address from the ping reply.. 5) A forwards the packet. How does this differ from ARP? Well, I see two differences - 1) there is no new protocol 2) there is no way to do "proxy ARP" unless you can change your media address on the fly I believe that this scheme is otherwise equivalent to ARP. c) After spending time debugging such configurations in the AT&T national signaling network, I truly despise such configurations and recommend strongly against them, but if such a configuration is truly necessary, and I have actually run into networks where they are necessary, to some extant in a manner analogous to the handling of SNMP traps, I would recommend that router A ping H before forwarding packets to H in order to make sure H's IP layer is actually up and running (successfully arp'ing H would not prove anything because of the possibility of a proxy). The automatic ping procedure would probably facilitate early detection and isolation of network anomalies. The ping procedure would also have forced address resolution before the actual transmission of IP packets. While I agree that asymmetric paths are NO fun to debug, they are frequently necessary, usually for non-technical reasons. If the multihomed source host is not routing, it would be an error for the return traffic to the source IP address to appear on another IP interface (unless that interface happen to be on an intermediate network hop to the correct source IP interface) and would indicate a topological misconfiguration which would probably cause problems even if the arp protocol were supported. Funny, it works just fine today. Just install a host route in the router and away you go. This response makes me wonder how long you have been in this business. Just over 2 years. But then again, I am a "very junior computer networking engineer". I don't do anything important. I just write routing protocols. I have been in the business for 18 years. Now 18 years of experience does not mean I have any more insight into computer networking than someone with less experience (and I have certainly run into people with more experience who did not have a clue in the field), Congratulations. but I have run into IP implementations for PC AT's running Xenix and DOS, Prime Series 50s, DG machines, Wang Machines, IBM machines and some controller-based VAX VMS implementations where the host route hack would not work at all. Fine. They're broken when they are multihomed. That's also irrelevant. Other implementation work _just fine_ this way. The fact that these implementations are common would suggest that it is a useful capability that we should carry into IPv7. The issue is a question of interpretation. No, it's a question of what works. Tony From owner-big-internet@munnari.oz.au Thu Feb 18 07:34:21 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA00633; Thu, 18 Feb 1993 07:34:32 +1100 (from owner-big-internet) Return-Path: Received: from europe.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19726; Thu, 18 Feb 1993 00:35:26 +1100 (from abochann@brussels.cisco.com) Received: from brussels.cisco.com by europe.cisco.com with TCP; Wed, 17 Feb 93 14:34:58 +0100 Received: by brussels.cisco.com; Wed, 17 Feb 93 14:33:33 +0100 From: Alex Bochannek Message-Id: <9302171333.AA05853@brussels.cisco.com> Subject: Re: addressing To: Christian.Huitema@sophia.inria.fr (Christian Huitema) Date: Wed, 17 Feb 93 14:33:31 MET Cc: tli@cisco.com, big-internet@munnari.oz.au In-Reply-To: <199302171244.AA05124@mitsou.inria.fr>; from "Christian Huitema" at Feb 17, 93 1:44 pm Reply-To: abochann@cisco.com X-Mailer: ELM [version 2.3 PL11] I hate to waste bandwidth and I think this point has been beaten to death anyway, but I'd like to comment on this. As Frank pointed out there are two main concepts here: - The Geopolitical Addressing. - The Network-Topological Addressing. There are strong arguments for and against both, but I believe the former one has one big conceptual flaw: Geopolitical entities are not static. There have been sufficient examples how these entities can change quite easily and being from Berlin I have seen it firsthand. Christian's observation is also very very true and I believe about twenty or thirty years ago there was a definition taught in schools where there were only five continents whereas today it is defined as seven or six usually. On the other hand I found people way more concerned about their actual network topology than the geographical locations of their machines. And they can easily accept that their addresses change when they switch the provider while the concept of addresses dependent on geography seems strange to them. Also the examples of multinational companies show easily that the addressing should be tightly coupled to the network topology. I think we need to understand that communication infrastructure is virtually independent of geography. The best counter-example would be the transportation infrastructure which is indeed very much linked to the geography. Bottomline: The topology of a 'data-highway' may or may not have anything to do with it's physical setup. If the shortest path from door to door in a network would be to go to the other coast first it is fine. Taking the car and drive through the whole country and back would be stupid. > Tony, > > A continent is a very arbitrary abstraction. The fact that there is a North > American Free trade zone that matches the continent boundaries is an > historical exception. If you look at former empires, e.g. Persian, Greek, > Roman, Arabic, Carolingian, German, Spanish-Austrian, Russian, Mongol, > Turkish, British, French, you name it, you will observe that their boundaries > almost never coincidated with continents: there would be a little bit of > Europe, part of Africa and some of Asia, or nearly all of Europe but not > England or not France, or a chunk of Russia + part of China and some of the > middle East -- you can find example for almost all combinations. There are > good reasons to that. For example, communications will more easily cross > seas than travel around deserts of mountains, or would rather follow language > groups than geographical proximity. > > Having a "continental" top level in the Internet is thus essentially useless. > It would not be useful now (want to coordinate Lybia and South-Africa?), and > as only very scarce chances to become useful at any point in the future. > > Christian Huitema -- Alex Bochannek TAC : +32 2 643 26-30 Technical Support Analyst Direct: +32 2 643 26-38 Cisco Systems International S.A. Fax : +32 2 643 26-27 250 avenue Louise, 8th Floor RFC822: abochann@cisco.com 1050 Brussels, Belgium From owner-Big-Internet@munnari.oz.au Thu Feb 18 11:26:02 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA06402; Thu, 18 Feb 1993 11:26:20 +1100 (from owner-Big-Internet) Return-Path: Received: from SERVER.AF.MIL by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06396; Thu, 18 Feb 1993 11:26:02 +1100 (from jonson@server.af.mil) Received: by server.af.mil (5.59/25-eef) id AA10795; Wed, 17 Feb 93 18:13:27 CST From: Matt Jonson Message-Id: <9302180013.AA10795@server.af.mil> Subject: Re: Metro addressing & Re: Address uniqueness To: atkinson@tengwar.itd.nrl.navy.mil (Ran Atkinson) Date: Wed, 17 Feb 93 18:13:25 CST Cc: big-Internet@munnari.oz.au In-Reply-To: <9302141932.ZM1567@tengwar.itd.nrl.navy.mil>; from "Ran Atkinson" at Feb 14, 93 7:32 pm X-Mailer: ELM [version 2.3 PL11] > Subject: Re: Metro addressing & Re: Address uniqueness > > % Sure, a small number of large private networks could be treated as > % distinct providers or distinct metros, but where would you draw the > % line between a "big" private net and a "not-so-big" private net, such > % that the number of "big" nets remains manageably small, and the > % operators of "not-so-big" nets remain content without their own > % prefixes? (I wonder how many organizations in the U.S. currently > % operate a private network between two or more metro areas, and how > % many will do so in the future.) > > This is the crux of the matter. I'm not sure how you write a rule > that draws the line, but I suspect that we could reach consensus on > which cases "deserve" a private net prefix and which ones don't. In > my mind NRL probably doesn't, but the whole USN net or DISA net or > IBM's VNET probably do. The more this gets discussed the more it seems that the top prefix (at least) needs to be assigned within managerial boundaries. i.e. giving the prefix to the entity that will actively assign (or delegate the assignment of) the addresses within the space. Just a curiosity question, but who will delegate the addresses if there are several providers in a metro, and the metro owns the prefix. Who arbitrates the space? Someone in city hall? Same type question with continents. I guess if we go to Continents we really end up going back to countries for management. What about Countries that are multi-continental (including territories...)? It seems to make the most sense to follow the wires, i.e. territories are within the prefix of the country they belong to. One thing we may need to consider about who should delegate addresses is whether we are creating work for an agency that doesn't currently exist...and whether it is reasonable to require it to exist... With providers, the managerial route is clear, but the question becomes one of potential scaling. However, if someone (say the ISOC) owns the right to give out a prefix to anyone in the world, and potential providers have to apply for that prefix from them, it seems there is a reasonable control over that growth. Defining the provider of course, is the interesting question. Conceivably all the following are reasonable providers: - a Company that does its own in-house long-haul networking. - a Government agency that does its own long-haul networking. - a company that provides long-haul service - a Government that owns its Telecomm services I don't think you're a "provider" if you purchase long-haul service from someone else and then sell it locally... I guess what I'm getting at here is that if you don't provide "long-haul" [okay just what is that :-)] service, you probably aren't a provider. Is anybody worried that the number of long-haul service providers will outnumber the number of metro areas in the world? If I'm missing the boat, let me know. This almost seems political big government vs capitalism ;-). /matt -- Lt Matthew W Jonson jonson@server.af.mil snail-mail: Network Systems Engineer 205-416-4075 SSC/SSDN USAF DDN Program Office AV: 596-4075 Gunter AFB, AL 36114 These are not official U.S. Government Choice opinions, but are my own. From owner-big-internet@munnari.oz.au Thu Feb 18 12:16:56 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA07913; Thu, 18 Feb 1993 12:16:59 +1100 (from owner-big-internet) Return-Path: Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29693; Thu, 18 Feb 1993 07:00:01 +1100 (from tli@cisco.com) Received: by lager.cisco.com; Wed, 17 Feb 1993 11:59:35 -0800 Date: Wed, 17 Feb 1993 11:59:35 -0800 From: Tony Li Message-Id: <199302171959.AA09062@lager.cisco.com> To: Christian.Huitema@sophia.inria.fr Cc: big-internet@munnari.oz.au In-Reply-To: Christian Huitema's message of Wed, 17 Feb 93 13:44:36 +0100 <199302171244.AA05124@mitsou.inria.fr> Subject: addressing A continent is a very arbitrary abstraction. True, in some cases. We need some abstraction to provide top level aggregation. Continental aggregation has already proven very useful with CIDR (and we haven't even deployed it yet!) by allowing us to aggregate noise and confine it to the local continent. [lots of political entities don't follow continental boundaries] True, and I would consider this as a good argument against using countries as the top level abstraction -- countries frequently don't match topology. Having a "continental" top level in the Internet is thus essentially useless. It would not be useful now (want to coordinate Lybia and South-Africa?), and as only very scarce chances to become useful at any point in the future. ??? You're presupposing that we want to do political addressing, which is something that we need to AVOID. Tony From owner-big-internet@munnari.oz.au Thu Feb 18 12:50:29 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA08868; Thu, 18 Feb 1993 12:51:20 +1100 (from owner-big-internet) Return-Path: Received: from Sun.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01132; Thu, 18 Feb 1993 08:08:52 +1100 (from Bob.Hinden@Eng.Sun.COM) Received: from Eng.Sun.COM (zigzag-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA08211; Wed, 17 Feb 93 13:07:24 PST Received: from bigriver.Eng.Sun.COM (bigriver-248) by Eng.Sun.COM (4.1/SMI-4.1) id AA05628; Wed, 17 Feb 93 13:12:20 PST Received: from chestnut.Eng.Sun.COM by bigriver.Eng.Sun.COM (4.1/SMI-4.1) id AA06457; Wed, 17 Feb 93 13:07:19 PST Date: Wed, 17 Feb 93 13:07:19 PST From: Bob.Hinden@Eng.Sun.COM (Bob Hinden) Message-Id: <9302172107.AA06457@bigriver.Eng.Sun.COM> Received: by chestnut.Eng.Sun.COM (5.0/SMI-SVR4) id AA01668; Wed, 17 Feb 93 13:05:49 PST To: kasten@ftp.com Cc: big-internet@munnari.oz.au, deering@parc.xerox.com In-Reply-To: <9302161614.AA10612@ftp.com> Subject: Re: addressing Content-Length: 371 Frank, > I read this as saying that "eventually, continental boundaries will > start to closely approximate provider boundaries". Is this what you mean? "Eventually" some of contents will merge back together via continental drift. :-) Then we will need some other sort of scheme. Interesting what changing the time scale does to the scope of the problem. Bob From owner-big-internet@munnari.oz.au Thu Feb 18 13:07:21 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA09240; Thu, 18 Feb 1993 13:07:25 +1100 (from owner-big-internet) Return-Path: Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29911; Thu, 18 Feb 1993 07:11:03 +1100 (from tli@cisco.com) Received: by lager.cisco.com; Wed, 17 Feb 1993 12:10:48 -0800 Date: Wed, 17 Feb 1993 12:10:48 -0800 From: Tony Li Message-Id: <199302172010.AA09715@lager.cisco.com> To: abochann@cisco.com Cc: Christian.Huitema@sophia.inria.fr, tli@cisco.com, big-internet@munnari.oz.au In-Reply-To: Alex Bochannek's message of Wed, 17 Feb 93 14:33:31 MET <9302171333.AA05853@brussels.cisco.com> Subject: addressing I believe about twenty or thirty years ago there was a definition taught in schools where there were only five continents whereas today it is defined as seven or six usually. Geeze... Ok, ok. I'll call them Tony's Arbitrarily Chosen Really Large Land Masses. On the other hand I found people way more concerned about their actual network topology than the geographical locations of their machines. Not surprising. They have little choice about where they are. They may have multiple choices about their interconnections. And they can easily accept that their addresses change when they switch the provider while the concept of addresses dependent on geography seems strange to them. So? IPv7 will be a major change to the concept of anyone running a network today. F'rinstance, we've clearly indoctrinated folks into network classes. I think we need to understand that communication infrastructure is virtually independent of geography. The best counter-example would be the transportation infrastructure which is indeed very much linked to the geography. Ah, but this is NOT true. Natural barriers (oceans, desserts, mountains) discourage people from installing infrastructure. This is clearly visible in the topology of the Internet today. How much BW is there between the west coast and the east coast of the US today? How much between the east coast and Europe? The topology of a 'data-highway' may or may not have anything to do with it's physical setup. If we can ignore things like virtual links for one moment, the topology is _by definition_ the physical setup. Tony From owner-big-internet@munnari.oz.au Thu Feb 18 14:36:03 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA11794; Thu, 18 Feb 1993 14:38:48 +1100 (from owner-big-internet) Return-Path: Received: from p.lanl.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06023; Thu, 18 Feb 1993 11:08:50 +1100 (from peter@goshawk.lanl.gov) Received: from goshawk.lanl.gov by p.lanl.gov (5.65/1.14) id AA09451; Wed, 17 Feb 93 17:08:30 -0700 Received: from localhost.lanl.gov by goshawk.lanl.gov (4.1/5.17) id AA19194; Wed, 17 Feb 93 17:08:28 MST Message-Id: <9302180008.AA19194@goshawk.lanl.gov> To: Christian Huitema Cc: Tony Li , big-internet@munnari.oz.au Subject: Re: addressing In-Reply-To: Your message of Wed, 17 Feb 93 13:44:36 +0100. <199302171244.AA05124@mitsou.inria.fr> Date: Wed, 17 Feb 93 17:08:28 MST From: peter@goshawk.lanl.gov Christian, While political boundaries know no continental bounds, communications transmission facilities do. If there is any doubt, please check out undersea cable maps or satellite footprints. Perhaps we should say "continental" is a buzzword for alignment with *TAT*, TPC* and PacRim cable facilities. While it is not necessary to align switching along the lines of transmission, it is likely that major interconnects for switching will occur at or near transmission exchanges. It should also be noted that an addressing plan needs to meet requirements beyond those of the routing system. For example, it must also be possible to administer the allocation of addresses. Often, continental (or national) entities are the best way of doing so, witness the RIPE NCC and U.S. NIC. cheers, peter From owner-Big-Internet@munnari.oz.au Thu Feb 18 17:57:07 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA16881; Thu, 18 Feb 1993 17:57:23 +1100 (from owner-Big-Internet) Return-Path: Received: from is.rice.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16875; Thu, 18 Feb 1993 17:57:07 +1100 (from bmanning@is.rice.edu) Received: from sabine.is.rice.edu by is.rice.edu (AA29413); Thu, 18 Feb 93 00:56:52 CST Received: by sabine.is.rice.edu (AA00700); Thu, 18 Feb 93 00:56:50 CST From: bmanning@is.rice.edu (William Manning) Message-Id: <9302180656.AA00700@sabine.is.rice.edu> Subject: toasters To: big-internet@munnari.oz.au Date: Thu, 18 Feb 93 0:56:47 CST X-Mailer: ELM [version 2.3 PL11] Would someeone like to summarize the toaster thread of about a year back? It would seem that there would be some number of addressable devices that I might claim to be under a single (my) administrative control. This number of addresses might be about 2-3 hundred. So do I tell my provider a CIDR-like prefix for all my stuff? Do I have to worry about how to "manage" my own little part of the addressing world? -- Regards, Bill Manning bmanning@rice.edu PO Box 1892 713-285-5415 713-527-6099 Houston, Texas R.U. (o-kome) 77251-1892 From owner-big-internet@munnari.oz.au Thu Feb 18 17:53:04 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17355; Thu, 18 Feb 1993 18:10:53 +1100 (from owner-big-internet) Return-Path: Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10463; Thu, 18 Feb 1993 13:52:23 +1100 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <11984>; Wed, 17 Feb 1993 18:50:39 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Wed, 17 Feb 1993 18:50:32 -0800 To: Tony Li Cc: big-internet@munnari.oz.au, deering@parc.xerox.com Subject: Re: addressing In-Reply-To: Your message of "Wed, 17 Feb 93 11:59:35 PST." <199302171959.AA09062@lager.cisco.com> Date: Wed, 17 Feb 1993 18:50:21 PST Sender: Steve Deering From: Steve Deering Message-Id: <93Feb17.185032pst.12171@skylark.parc.xerox.com> > Continental aggregation has already proven very useful > with CIDR (and we haven't even deployed it yet!) by allowing us to > aggregate noise and confine it to the local continent. That's not much confinement! > True, and I would consider this as a good argument against using > countries as the top level abstraction -- countries frequently don't > match topology. Under metro-based addressing, all providers serving a metro interconnect within that metro (insert standard caveat about partition healing). Since the metros are internally connected, the countries are, as a consequence, internally connected, which is all that is needed to satisfy the topological requirements of hierarchical routing. (Note that there is no constraint on the extent of a provider -- providers may interconnect any subset of metros in any number of countries.) Steve From owner-big-internet@munnari.oz.au Thu Feb 18 18:52:18 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA19270; Thu, 18 Feb 1993 18:53:04 +1100 (from owner-big-internet) Return-Path: Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10854; Thu, 18 Feb 1993 14:08:32 +1100 (from tli@cisco.com) Received: by lager.cisco.com; Wed, 17 Feb 1993 19:08:24 -0800 Date: Wed, 17 Feb 1993 19:08:24 -0800 From: Tony Li Message-Id: <199302180308.AA24614@lager.cisco.com> To: deering@parc.xerox.com Cc: big-internet@munnari.oz.au, deering@parc.xerox.com In-Reply-To: Steve Deering's message of Wed, 17 Feb 1993 18:50:21 PST <93Feb17.185032pst.12171@skylark.parc.xerox.com> Subject: addressing > Continental aggregation has already proven very useful > with CIDR (and we haven't even deployed it yet!) by allowing us to > aggregate noise and confine it to the local continent. That's not much confinement! That does NOT imply that it's the only confinement. > True, and I would consider this as a good argument against using > countries as the top level abstraction -- countries frequently don't > match topology. Under metro-based addressing, all providers serving a metro interconnect within that metro (insert standard caveat about partition healing). Since the metros are internally connected, the countries are, as a consequence, internally connected, The point is that this may not hold true. Since countries may be physically separated, the metros may not be connected. The old British Empire would seem to be an obvious example. which is all that is needed to satisfy the topological requirements of hierarchical routing. I disagree. Hierarchical routing will work in any case. It will just be grossly inefficient. This is salient because we will never have a _perfect_ addressing plan. We can only provide for good efficiency. Tony From owner-big-internet@munnari.oz.au Thu Feb 18 19:50:14 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA20816; Thu, 18 Feb 1993 19:50:27 +1100 (from owner-big-internet) Return-Path: Received: from Sun.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16180; Thu, 18 Feb 1993 17:38:28 +1100 (from Bob.Hinden@Eng.Sun.COM) Received: from Eng.Sun.COM (zigzag-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA05041; Wed, 17 Feb 93 22:38:18 PST Received: from bigriver.Eng.Sun.COM (bigriver-248) by Eng.Sun.COM (4.1/SMI-4.1) id AA02740; Wed, 17 Feb 93 22:43:19 PST Received: by bigriver.Eng.Sun.COM (4.1/SMI-4.1) id AA14485; Wed, 17 Feb 93 22:38:14 PST Date: Wed, 17 Feb 93 22:38:14 PST From: Bob.Hinden@Eng.Sun.COM (Bob Hinden) Message-Id: <9302180638.AA14485@bigriver.Eng.Sun.COM> To: Tony Li Cc: big-internet@munnari.oz.au In-Reply-To: <199302172010.AA09715@lager.cisco.com> Subject: addressing Content-Length: 569 Tony, > Ah, but this is NOT true. Natural barriers (oceans, desserts, > mountains) discourage people from installing infrastructure. This is > clearly visible in the topology of the Internet today. How much BW is > there between the west coast and the east coast of the US today? How > much between the east coast and Europe? Tariffs may be a bigger factor. It is my understanding that a lot of inter-Europe traffic goes to the US and back. It turns out that it is cheaper to get a line to the US than it is between countries many European countries. Bob From owner-big-internet@munnari.oz.au Thu Feb 18 22:02:57 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA24923; Thu, 18 Feb 1993 22:03:06 +1100 (from owner-big-internet) Return-Path: Received: from mitsou.inria.fr by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21717; Thu, 18 Feb 1993 20:20:50 +1100 (from huitema@mitsou.inria.fr) Received: by mitsou.inria.fr (5.65c/IDA-1.2.8) id AA06990; Thu, 18 Feb 1993 10:23:12 +0100 Message-Id: <199302180923.AA06990@mitsou.inria.fr> To: peter@goshawk.lanl.gov Cc: Tony Li , big-internet@munnari.oz.au Subject: Re: addressing In-Reply-To: Your message of "Wed, 17 Feb 93 17:08:28 MST." <9302180008.AA19194@goshawk.lanl.gov> Date: Thu, 18 Feb 93 10:23:11 +0100 From: Christian Huitema >Christian, > >While political boundaries know no continental bounds, communications >transmission facilities do.... Well, even this is a debatable statement. The decision to build a given communication infrastructure is an investment decision, based on a cost benefit ratio. One may, to an extent, agree that the cost is a function of geography although the relative costs of crossing mountains or urban areas vs laying a cable at the bottom of an ocean or launching a satellite is not so clear cut. But one should also consider that expected return is function of the "political" boundaries, or rather of the economical and cultural relations between the entities. As a result, you find out that the pattern of installed links does not strictly follow geography. Want examples? Take North-Atlantic for once. Not so long ago, I was proposed a cheaper tariff for a Nice-Princeton connection than for a Nice-Paris link of same capacity. Even now, you get more services, at a much cheaper price, between western Europe and the US than between Western and Eastern Europe. Or even between France and Italy. Then consider other parts of the world. You could have thought that the former CEI republics would build a network through Russia; you would be wrong; Turkish speaking republics get their links through Turkey, by satellite. This may perhaps have to do with regulation. But it also be the case that a large demand causes economies of scale, and that competition brings the prices down. That is also observed in other industries, e.g. airlines, where transatlantic flights are often cheaper than US domestic or European internal flights. The purpose of communications is to make people closer from one another. Incorporating boundaries in the addresses is not necessarily a way to achieve that. Christian Huitema From owner-Big-Internet@munnari.oz.au Fri Feb 19 01:06:00 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA00373; Fri, 19 Feb 1993 01:06:40 +1100 (from owner-Big-Internet) Return-Path: Received: from interlock.ans.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00341; Fri, 19 Feb 1993 01:06:00 +1100 (from dennis@ans.net) Received: by interlock.ans.net id AA17993 (InterLock SMTP Gateway 1.1 for big-internet@munnari.oz.au); Thu, 18 Feb 1993 09:04:25 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 18 Feb 1993 09:04:25 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 18 Feb 1993 09:04:25 -0500 Date: Thu, 18 Feb 1993 09:04:26 -0500 From: Dennis Ferguson Message-Id: <199302181404.AA58846@foo.ans.net> To: tli@cisco.com Subject: Re: addressing Cc: big-internet@munnari.oz.au, deering@parc.xerox.com Tony, > Under metro-based addressing, all providers serving a metro interconnect > within that metro (insert standard caveat about partition healing). > Since the metros are internally connected, the countries are, as a > consequence, internally connected, > > The point is that this may not hold true. Since countries may be > physically separated, the metros may not be connected. The old > British Empire would seem to be an obvious example. The easy answer to this might be to simply divide "political" countries into separate "networking" countries when this makes sense given likely connectivity, or is otherwise convenient. I think the ISO has figured this out already. While my knowledge of political geography is weak I suspect at least some of the following ISO "countries" are actually part of the same political country. FR "France" "208" GF "French Guiana" "742" GP "Guadeloupe" MQ "Martinique" NC "New Caledonia" "546" PF "French Polynesia" "547" PM "St Pierre and Miquelon" "308" Dennis Ferguson From owner-Big-Internet@munnari.oz.au Fri Feb 19 04:27:08 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA05926; Fri, 19 Feb 1993 04:27:20 +1100 (from owner-Big-Internet) Return-Path: Received: from uunet by munnari.oz.au with UUCP (5.83--+1.3.1+0.50) id AA05921; Fri, 19 Feb 1993 04:27:08 +1100 (from peter@goshawk.lanl.gov) From: peter@goshawk.lanl.gov Received: from p.lanl.gov by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA01913; Thu, 18 Feb 93 12:18:17 -0500 Received: from goshawk.lanl.gov by p.lanl.gov (5.65/1.14) id AA01947; Thu, 18 Feb 93 10:11:38 -0700 Received: from localhost.lanl.gov by goshawk.lanl.gov (4.1/5.17) id AA25670; Thu, 18 Feb 93 10:11:37 MST Message-Id: <9302181711.AA25670@goshawk.lanl.gov> To: Christian Huitema Cc: Tony Li , big-internet@munnari.oz.au Subject: Re: addressing In-Reply-To: Your message of Thu, 18 Feb 93 10:23:11 +0100. <199302180923.AA06990@mitsou.inria.fr> Date: Thu, 18 Feb 93 10:11:37 MST >>> The purpose of communications is to make people closer from one another. >>> Incorporating boundaries in the addresses is not necessarily a way to achieve >>> that. I hope my computers never complain to me about the boundaries in the addresses it sees coming from the DNS. If it does I will certainly know the master/server roles will have been reversed. cheers, peter From owner-big-internet@munnari.oz.au Fri Feb 19 11:09:20 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA20110; Fri, 19 Feb 1993 11:20:53 +1100 (from owner-big-internet) Return-Path: Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08946; Fri, 19 Feb 1993 06:20:14 +1100 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <11621>; Thu, 18 Feb 1993 11:19:42 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Thu, 18 Feb 1993 11:19:36 -0800 To: Matt Jonson Cc: big-internet@munnari.oz.au, deering@parc.xerox.com Subject: Re: Metro addressing & Re: Address uniqueness In-Reply-To: Your message of "Wed, 17 Feb 93 16:13:25 PST." <9302180013.AA10795@server.af.mil> Date: Thu, 18 Feb 1993 11:19:30 PST Sender: Steve Deering From: Steve Deering Message-Id: <93Feb18.111936pst.12171@skylark.parc.xerox.com> > Just a curiosity question, but who will delegate the addresses if there > are several providers in a metro, and the metro owns the prefix. Who > arbitrates the space? Someone in city hall? Those are good questions. I would propose that a national numbering authority (e.g., a national chapter of the ISOC) would allocate blocks of addresses to providers operating within each metro, for those providers to dole out to their subscribers. However, those blocks of address would not "belong" to the providers and would have no significance for routing, since providers could keep their addresses when they switched to different providers in the same metro. Sites that did not connect to any provider could apply directly to the national authority to get a site prefix within the metro of most-likely future connection. Thus, I think we could avoid the need for metro authorities. Another interesting question is whether or not sites would have to pay "rent" for their site prefixes, to pay the administration costs of the national authority and to provide a way of detecting when a site prefix is no longer in use and can be reassigned to a new site. This would have the undesirable effect of creating a monopoly in the renting of addresses. There are, however, precedents for such numbering monopolies, such as the IEEE which sells blocks of 802.1/Ethernet addresses. Perhaps we can fund IETF activities through the rental of Internet addresses?? Steve From owner-big-internet@munnari.oz.au Fri Feb 19 12:23:08 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22661; Fri, 19 Feb 1993 12:41:10 +1100 (from owner-big-internet) Return-Path: Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11221; Fri, 19 Feb 1993 07:45:17 +1100 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <11629>; Thu, 18 Feb 1993 12:44:08 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Thu, 18 Feb 1993 12:44:00 -0800 To: Christian Huitema Cc: big-internet@munnari.oz.au Subject: Re: addressing In-Reply-To: Your message of "Thu, 18 Feb 93 01:23:11 PST." <199302180923.AA06990@mitsou.inria.fr> Date: Thu, 18 Feb 1993 12:43:51 PST Sender: Steve Deering From: Steve Deering Message-Id: <93Feb18.124400pst.12171@skylark.parc.xerox.com> > The purpose of communications is to make people closer from one another. > Incorporating boundaries in the addresses is not necessarily a way to achieve > that. It is not necessarily something that prevents that, either. Steve From owner-big-internet@munnari.oz.au Fri Feb 19 13:22:10 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA25070; Fri, 19 Feb 1993 13:39:59 +1100 (from owner-big-internet) Return-Path: Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08222; Fri, 19 Feb 1993 05:55:37 +1100 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <11596>; Thu, 18 Feb 1993 10:55:00 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Thu, 18 Feb 1993 10:54:48 -0800 To: Tony Li Cc: big-internet@munnari.oz.au, deering@parc.xerox.com Subject: Re: addressing In-Reply-To: Your message of "Wed, 17 Feb 93 19:08:24 PST." <199302180308.AA24614@lager.cisco.com> Date: Thu, 18 Feb 1993 10:54:45 PST Sender: Steve Deering From: Steve Deering Message-Id: <93Feb18.105448pst.12171@skylark.parc.xerox.com> > [Confining noise by continent] is not much confinement! > > That does NOT imply that it's the only confinement. Then why not let your next level down (country, provider, whatever) be the top level? Then the noise will be confined to that finer-grain cluster. Assuming the number of next-level-down clusters is in the hundreds or low thousands, the top-level routing will still be tractable. If you choose countries as your top level, the amount of noise at the top level, though non-zero (yes, countries do merge, partition, appear, and disappear), will be negligible (countries do not merge, partition, appear, or disappear at a rate that would be a significant burden to top- level routing). A top level of providers would be subject to more "churn", but probably also not an unmanageable amount. > Under metro-based addressing, all providers serving a metro interconnect > within that metro (insert standard caveat about partition healing). > Since the metros are internally connected, the countries are, as a > consequence, internally connected, > > The point is that this may not hold true. Since countries may be > physically separated, the metros may not be connected. You are right. My statement that interconnection of providers within metros implies interconnection of providers within countries was incorrect, regardless of physical contiguity of the country. I was implicitly assuming that countries would, as the number of Internet sites became significant, naturally develop intra-country, inter-metro internet infrastructure (whether though "national" backbones or through interconnection of various independent service providers) so that traffic between two metros in the same (contiguous) country would not have to pass through other countries (except as a means of healing a temporary partition of the national infrastructure). Physically-discontiguous chunks of the same country get different country codes, e.g., Geenland gets a different country code than Denmark. > which is all that is needed to > satisfy the topological requirements of hierarchical routing. > > I disagree. Hierarchical routing will work in any case. It will just > be grossly inefficient. Do you disagree that hierarchical routing requires that each chunk of topology labeled with an address prefix be internally connected? Do you disagree because partitioned chunks can be healed by tunneling (which is a way of restoring "connectedness") and/or because longest-match routing allows sub-chunks to be partitioned from a chunk and routed at the inter-chunk level (which is a way of flattening part of the hierarchy), or do you disagree for some other reason? > This is salient because we will never have a _perfect_ addressing plan. > We can only provide for good efficiency. Efficiency is a multi-dimenensional measurement; of course we can never achieve maximum efficiency along all axes of interest. The inefficiency of hierarchical routing is usually expressed in terms of path length. If path length is measured in terms of speed-of-light delay (which dominates switching delay on long-haul paths), geographic addressing is pretty efficient. It encourages the development of infra-structure that has low- delay delivery paths, so that, for example, traffic from the north of France to the south of France does not have to pass through New York just because the two communicating sites subscribe to different providers. (If the sites really *want* to have their traffic pass through New York, they can accomplish that by loose source routing.) Steve From owner-big-internet@munnari.oz.au Sat Feb 20 00:46:25 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA14312; Sat, 20 Feb 1993 00:46:27 +1100 (from owner-big-internet) Return-Path: Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05970; Fri, 19 Feb 1993 19:53:04 +1100 (from tli@cisco.com) Received: by lager.cisco.com; Fri, 19 Feb 1993 00:52:42 -0800 Date: Fri, 19 Feb 1993 00:52:42 -0800 From: Tony Li Message-Id: <199302190852.AA06094@lager.cisco.com> To: deering@parc.xerox.com Cc: big-internet@munnari.oz.au, deering@parc.xerox.com In-Reply-To: Steve Deering's message of Thu, 18 Feb 1993 10:54:45 PST <93Feb18.105448pst.12171@skylark.parc.xerox.com> Subject: addressing > [Confining noise by continent] is not much confinement! > > That does NOT imply that it's the only confinement. Then why not let your next level down (country, provider, whatever) be the top level? Key point: I expect that there will be a lot of "noise" that comes out of countries and providers for various reasons. For example, partition healing and route optimization would both introduce noise. Such more specific routes which reach outside of the top level are probably more difficult (i.e., require manual intervention) to recover. Please note that I have no objection to country/provider/whatever hierarchy _within_ the continent. The concept of a "flat" continent is most amusing, but wholly unworkable. Assuming the number of next-level-down clusters is in the hundreds or low thousands, the top-level routing will still be tractable. If you choose countries as your top level, the amount of noise at the top level, though non-zero (yes, countries do merge, partition, appear, and disappear), will be negligible (countries do not merge, partition, appear, or disappear at a rate that would be a significant burden to top- level routing). I disagree. Perhaps my implementor's hat is showing, but I don't believe that the noise is anything significantly less than a factor of two over say, a 50 year period. I certainly want to assume this during the design to insure that we don't under-engineer things this time. While I agree that "all countries" is still tractable for "big" routers, this still implies that "small" routers cannot hold a full routing table. This implies that we end up using default and that low end routers may not be up to providing the best "quality" routing that is available. While it would help me financially, I do NOT believe that everyone that wants to do routing should buy a $50k cisco 7000. ;-) I believe that ubiquitous, cheap, low end routers, connected to digital services which allow arbitrary topology changes on demand will drive IPv7 routing away from default routing and towards a full routing table. Do you disagree that hierarchical routing requires that each chunk of topology labeled with an address prefix be internally connected? Do you disagree because partitioned chunks can be healed by tunneling (which is a way of restoring "connectedness") and/or because longest-match routing allows sub-chunks to be partitioned from a chunk and routed at the inter-chunk level (which is a way of flattening part of the hierarchy), or do you disagree for some other reason? I disagree for both of the reasons that you list. Efficiency is a multi-dimenensional measurement; of course we can never achieve maximum efficiency along all axes of interest. The inefficiency of hierarchical routing is usually expressed in terms of path length. If path length is measured in terms of speed-of-light delay (which dominates switching delay on long-haul paths), geographic addressing is pretty efficient. Agreed. Another measurement of "efficiency" is the complexity of the storage that must be maintained in a default free router. It encourages the development of infra-structure that has low- delay delivery paths, so that, for example, traffic from the north of France to the south of France does not have to pass through New York just because the two communicating sites subscribe to different providers. (If the sites really *want* to have their traffic pass through New York, they can accomplish that by loose source routing.) Given ANY addressing architecture, a robust policy routing protocol should allow you to select ANY path in the network which conforms to policy. This includes loops, etc... ;-) Tony From owner-Big-Internet@munnari.oz.au Sat Feb 20 03:30:45 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA18812; Sat, 20 Feb 1993 03:31:00 +1100 (from owner-Big-Internet) Return-Path: Received: from OERV01.er.doe.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18804; Sat, 20 Feb 1993 03:30:45 +1100 (from hitchcoc@oerv01.er.doe.gov) Received: by er.doe.gov (5.57/OER-V1.0) id AA16809; Fri, 19 Feb 93 11:26:18 -0500 Date: Fri, 19 Feb 93 11:26:18 -0500 From: hitchcoc@oerv01.er.doe.gov (Dan Hitchcock) Message-Id: <9302191626.AA16809@er.doe.gov> To: deering@parc.xerox.com, tli@cisco.com Subject: Re: addressing Cc: big-internet@munnari.oz.au Perhaps some abstraction on this addressing problem would be useful: In the first place the useful point to point distance function for the map of the world that we want to create is the cost per bandwidth delivered at the expected traffic level. Thus the "distance" from NY to London might be the cost of a T1 per month/1.544; the "distance" between Pittsburg SC Center and San Diego SC center might be the cost of a DS3/month/45, and the distance between the POP in DC and my house in Bethesda and the DC POP might be the cost of an ISDN circuit/.056, in units of $/month/megabit/sec. Now this new metric is going to distort the topology of the earth significantly, I expect but if providers are going to make money on this business it is perhaps the most relevant one. Note that in this topology London and Paris are probably both closer to NYC than they are to each other. In this topology, what is a "metro", I would assert that it is a set of endpoints whose distances from each other are "close" to equal. So in topological terms one could cover our world with "metros" as the quotient topology in this relation where 3 points are in the same "metro" if the distances between them fall in some range. Of course points in this topology can be in more than one "metro". In addition, different services might provide multiple metros on top of one another from differnet services, e.g. cellular service, ISDN, Cable TV,... Now consider a single "metro" with a large number of points. The costs of connecting these points, at least for services which run over wires and fiber are dominated by the costs of installing the media. Furthermore the topology of the media is tied to the existing rights of way, poles, etc. Therefore, at the lowest level of aggregation, having endpoints come to a common first interconnection is probable for many but not all customers. Even cellular se vices are constrained to use existing towers, at least in the US where costs are lawyer driven. This is of course not necessarily true in today's internet bec- ause the density of endpoints is relatively small compared to the density of access points to the physical communications infrastructure so every end connection justifies custom bypass. However, in the BIG internet of the future which supports the NII,...one can anticipate that the density of network endpoints will be comparable to the density of interconnects to the physical telecom infrastructure (perhaps the experience with local cable tv providers could give us a second point of validation here) These considerations suggest that in "metros" a metro based address is useful, with the possibility of supermetros and bypass addresses for multi-metro com- panies, etc. However, clear ability to identify the backbone provider of your choice and the local provider at destination systems is also important if for no other reason than to make billing and accounting possible at reasonable cost. Remember users pay the costs for generating the bills too! Therefore, it seems essential to have a part either of the packet header or the address, a provider id field, I guess my preference would be to have it be in the address so providers' gateways could listen for that field... Unfortunately this means that someone has to manage the metro addresses. which requires some administrative hierarchy which has to be paid for. This sort of plan does not cover all cases but would form a basis for discussion of the types of things that might be possible and economically likely. It would, for example be useful to construct a map of the world with this new metric just to see what the real topology we face today is. Dan Hitchcock From owner-Big-Internet@munnari.oz.au Sat Feb 20 04:39:16 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA20407; Sat, 20 Feb 1993 04:39:36 +1100 (from owner-Big-Internet) Return-Path: Received: from nero.clearpoint.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20401; Sat, 20 Feb 1993 04:39:16 +1100 (from martillo@nero.clearpoint.com) Received: by nero.clearpoint.com (4.1/1.34) id AA05363; Thu, 4 Feb 93 08:09:39 EST Date: Thu, 4 Feb 93 08:09:39 EST From: martillo@nero.clearpoint.com (Joachim Carlo Santos Martillo Ajami) Message-Id: <9302041309.AA05363@nero.clearpoint.com> To: Christian.Huitema@sophia.inria.fr, tli@cisco.com, big-internet@munnari.oz.au, jjmhome!big-internet%munnari.oz.au@crackers.clearpoint.com Cc: martillo@nero.clearpoint.com Subject: Metro Addressing Summary Date: Wed, 3 Feb 93 14:17:41 -0500 To: martillo@nero.clearpoint.com Subject: Re: Metro Addressing Summary From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: Christian.Huitema@sophia.inria.fr, tli@cisco.com, big-internet@munnari.oz.au > > * Many people believe that "addresses" should not be too tightly coupled to > > the topology. Or at least, many can be coupled to have said precisely that. > Addresses MUST be very very tightly coupled to the topology. This is the > definition of an address, since it defines a point on the topology. What > MUST NOT be coupled to the topology in any way is the Endpoint Identifier. > Is this supposed to be a general principle? Certainly, one can build > very complex physical network topologies with IEEE P802.1d MAC > bridging, yet the physical addresses used in a given network are > arbitrary. As the 802 'address' does not, in fact, identify a point on the network topology, it is not a true address. If I unplug my PC from the IP Subnet to which it is now attached, carry the PC to California, and plug it back in, the PC has changed its position on the network topology, however it will keep the same 802 number. This belief is a common misconception among engineers who do not understand the underlying mathematics of networks and who have been befuddled by the terminology associated with computer networks. If I take a Constellation Auriga (an EISA/ISA bus host resident bridge router), put it into a PC, configure it with two logical subbridges (Auriga IP interfaces), assign lb0 (logical subbridge 0) ip address netid0.hostid0, configure the Auriga to run the standard ip routing protocols, connect the PC ip interface to the same ip network as lb0 (i.e. give the PC ip address netid0.hostid1), I can move my PC to California connect lb1 to a local ip network running the standard ip routing protocols, get lb1 a local ip network address (either by manual assignment, by listening and challenge, by a dynamic ip address server if one is running or by some other procedure), and lo and behold my PC has changed its position in the network layer network topology and yet it has kept the same ip address and it talks to everybody in the ip internetwork just fine. On the other hand, I have a PC with a standard PRONET-10 adaptor and move it from one physical network to another, I could very well have to reconfigure the PC PRONET-10 adaptor physical address. In short, Kastenholz' example is completely meaningless. The 802 number _is_, in fact, an end-point identifier. The fact that we call them addresses does not change this fact (I can call the thing I drive to work in each morning an apple, that doesn't mean that I can bake a pie with it). For the IP router, the IP subnetwork ids label the endpoints between which the IP routers select paths. To consider "endpoint identifiers" entities fundamentally different from network "addresses" implies some serious confusion and misunderstanding of the mathematics which underlies computer networking technology. An analogy with telephony is relevant. Just because central office switches and toll switches work at different layers in the telephone network hierarchy, there is no reason to believe central office switches and toll switches do anything fundamentally different. The computer networking terminology may obscure the truth because a term is used for a MAC layer packet switch (bridge) which is completely different from the term for a network layer packet switch (router). Mathematically, there is no distinction between bridges and routers. Both bridges and routers switch packets on the basis of a topological path selection algorithm. It happens that P802.1d bridges use a broadcast path selection algorithm rather than a shortest path first selection algorithm as is commonly used for network layer packet switches. But such a happenstance is pure implementation decision. A MAC bridge could be implemented which used a shortest path first selection algorithm while a broadcast path selection algorithm like spanning tree could be used for network layer path selection. If Kastenholz had actually read and understood the P802.1d MAC bridging specification and the RFC 1247 OSPF Version 2 specification by J. Moy (who knows how to write an excellent specification document), he would note that spanning tree operates by pruning the equivalent topological graph where MAC bridges and LAN segments are vertices and MAC ports are graph arcs whereas OSPF procedures select paths through the equivalent topological graph (pp 3-6) where vertices are routers and networks while graph arcs are the links from the routers to the networks (except in the special case of unnumbered serial links). In OSPF, the network vertices are identified by network addresses (which contain the subnetwork id), which is a conventionalization to make exchanging path selection information simpler. In spanning tree, the LAN segment vertices could be viewed as identified by the MAC addresseses of attached end hosts. In effect, this conventionalization is used as part of the filtering procedure to cut down on network flooding. Just as there is no mathematical distinction between between first order packet switches (bridges) and second order packet switches (routers), there is no mathematical distinction between first order vertex labels (endpoint identifiers or MAC addresses which can be used to identify the LAN segment to which a communications subnet end host attaches) and second order vertex labels (network ids or network addresses which contain the network ids and which can be used to identify the network to which a network end host attaches). And here is the punch line: "Routers and bridges, from the standpoint of mathematical theory, perform the exact same sorts of mathematical operations on precisely the same sorts of mathematical objects and select paths between precisely the same sorts of mathematical objects which are called network addresses when path selection takes place at the network layer and which are called end point identifiers when path selection takes place at the MAC layer." Or to use Kastenholz' type of prosody, if he calls it mastication, and I call it chewing, we are still doing the same thing. Anyway, not realizing the basic mathematical equivalence of bridging and routing is only excusable in a very junior computer networking engineer. The Address/EID split does not imply that only one or the other can ever be used for forwarding packets through networks. Bridging, as a technique is certainly a valid technique for relatively "small" networks (typical rules of thumb that I've seen used for how big "too" big is 50-100 segments or 5,000 nodes; naturally this increases as bridges get more CPU and memory). Another ridiculous comment. Bridging as a technique is the same as routing as a technique. And these limits are technological (e.g. limited by medium bandwidth or access method) or implementation dependent (e.g. choosing a broadcast path selection algorithm like spanning tree) and are not fundamental to graph theory. Conservatively estimating, using current technology but a better path selection algorithm, bridges could probably be used to interconnect 10,000 nodes in a single subnetwork. Routers using appropriate path selection techniques at the network layer should be able to interconnect about 10,000 subnetworks. An internetwork so built using bridges to build subnetworks and routers judiciously to interconnect subnetworks should be able to provide connectivity for O(100,000,000) end hosts which would be a fair-sized network. The construction of very large internetworks becomes a much more tractable problem when first order packet switches (bridges) are used effectively in addition to second order packet switches (routers). And of course building wide-area backbones from (multiprotocol) routers is just silly and a waste of network addresses. I would also point out that one of the mechanisms discussed for assigning EIDs to nodes was to use the 802 number. -- Frank Kastenholz Joachim Carlo Santos Martillo Ajami The article represents noone's opinions other than the author's. P.S. I go through the analysis of bridging and routing in gory detail in a paper, "Routing in a Bridged Network" (rtebridg.ps), which is available on hsdndev.harvard.edu. From owner-Big-Internet@munnari.oz.au Sat Feb 20 05:18:19 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21084; Sat, 20 Feb 1993 05:18:33 +1100 (from owner-Big-Internet) Return-Path: Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21076; Sat, 20 Feb 1993 05:18:19 +1100 (from tli@cisco.com) Received: by lager.cisco.com; Fri, 19 Feb 1993 10:18:02 -0800 Date: Fri, 19 Feb 1993 10:18:02 -0800 From: Tony Li Message-Id: <199302191818.AA24892@lager.cisco.com> To: Bob.Hinden@eng.sun.com Cc: big-internet@munnari.oz.au In-Reply-To: Bob Hinden's message of Fri, 19 Feb 93 09:17:35 PST <9302191717.AA04777@bigriver.Eng.Sun.COM> Subject: addressing I don't think it unreasonable to select design points for 5 to 10 years out which can only be done with high end solutions today. But we don't have to. We can address now to have a current low end router be default free. The cost at this point is nil. Tony From owner-big-internet@munnari.oz.au Sat Feb 20 06:58:09 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA23116; Sat, 20 Feb 1993 06:58:17 +1100 (from owner-big-internet) Return-Path: Message-Id: <9302191958.23116@munnari.oz.au> Received: from research.att.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19506; Sat, 20 Feb 1993 03:59:02 +1100 (from hgs@research.att.com) Received: by inet; Fri Feb 19 11:02 EST 1993 Date: Fri, 19 Feb 93 11:02:35 EST From: hgs@research.att.com (Henning G. Schulzrinne) To: dennis@ans.net Subject: Re: addressing Cc: big-internet@munnari.oz.au The ITU or whoever assigns country codes has also split political countries geographically. (again, I can't vouch for the current political affiliation or non-affiliation of the below). 262 Reunion (France) 33 France 508 St. Pierre et Miquelon (France) 590 French Antilles (St. Barthelemy, St. Martin, Guadeloupe) 594 French Guiana 689 French Polynesia (The first digit of the country code reflects the global region, roughly, but puts Africa and Greenland both in Area 2...) --- Henning Schulzrinne (hgs@research.att.com) AT&T Bell Laboratories (MH 2A-244) 600 Mountain Ave; Murray Hill, NJ 07974 phone: +1 908 582-2262; fax: +1 908 582-5809 From owner-Big-Internet@munnari.oz.au Sat Feb 20 07:04:40 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA23228; Sat, 20 Feb 1993 07:04:56 +1100 (from owner-Big-Internet) Received: from gateway.mitre.org by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23225; Sat, 20 Feb 1993 07:04:40 +1100 (from barns@cove.mitre.org) Return-Path: Received: from cove.mitre.org by gateway.mitre.org (5.61/SMI-2.2) id AA23932; Fri, 19 Feb 93 15:04:33 -0500 Received: by cove.mitre.org (4.1/SMI-4.1) id AA04647; Fri, 19 Feb 93 15:04:19 EST Message-Id: <9302192004.AA04647@cove.mitre.org> To: big-internet@munnari.oz.au Cc: barns@cove.mitre.org Subject: Re: addressing In-Reply-To: Tony Li's message of "Fri, 19 Feb 93 00:52:42 PST." <199302190852.AA06094@lager.cisco.com> Date: Fri, 19 Feb 93 15:04:14 -0500 From: barns@cove.mitre.org Tony's message reminds me of something that has been nagging me for a long time. Everyone agrees that there are options (and most people dislike some of them) but is the list complete? You can have full routing tables, default routes, hierarchically scoped locally-full tables, etc., but at least in principle you could have routing table fullness that responds to demand. Is it not possible to have demand- based route fetching without constraining the connection/flow/?? to a specific route? By route fetching, I mean to imply a process analogous to DNS name resolution, but distinct from it, with the distribution of knowledge organized in a way that is chosen to be good for routing performance. I don't mean to restrict this to any particular model of how centralized or decentralized the route computation process is. Caching (or "learning") is undoubtedly implied. Yes, there are non-trivial issues here but is it "obvious" that they are harder to resolve than the issues that come up with the other options (which are consuming megabytes of email on this list)? I feel like I've been through about three years of reiteration of the same discussion of two alternatives (call them metro and provider if you must), each of which is demonstrably obnoxious under some very plausible scenario. Perhaps I'm just too uninformed, but I'd think people would be looking for some really different approach that would "jump out of the system" and I haven't noticed it happen. (Well, Noel is sort of trying, but in a different direction - I think.) Is there anything here or should I forget it? /Bill Barns From owner-big-internet@munnari.oz.au Sat Feb 20 08:41:52 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA25053; Sat, 20 Feb 1993 08:41:57 +1100 (from owner-big-internet) Return-Path: Received: from SERVER.AF.MIL by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19670; Sat, 20 Feb 1993 04:05:41 +1100 (from jonson@server.af.mil) Received: by server.af.mil (5.59/25-eef) id AA01874; Fri, 19 Feb 93 10:51:39 CST From: Matt Jonson Message-Id: <9302191651.AA01874@server.af.mil> Subject: Re: addressing To: deering@parc.xerox.com (Steve Deering) Date: Fri, 19 Feb 93 10:51:37 CST Cc: tli@cisco.com, big-internet@munnari.oz.au In-Reply-To: <93Feb18.105448pst.12171@skylark.parc.xerox.com>; from "Steve Deering" at Feb 18, 93 10:54 am X-Mailer: ELM [version 2.3 PL11] > Subject: Re: addressing > > This is salient because we will never have a _perfect_ addressing plan. > > We can only provide for good efficiency. > > Efficiency is a multi-dimenensional measurement; of course we can never > achieve maximum efficiency along all axes of interest. The inefficiency > of hierarchical routing is usually expressed in terms of path length. > If path length is measured in terms of speed-of-light delay (which dominates > switching delay on long-haul paths), geographic addressing is pretty Speed of light delay dominates in the U.S. on long-haul paths, but what about the country that can't get T-1 + bandwidths between switches? It would be best to minimize the queueing delays by minimizing hop count wouldn't it? This is still one of the biggest sources of delay we have in the (aargh) Milnet. Emerging infrastructure in other countries may go through the same kind of evolution we have gone through here... Is this an important consideration for metro...? > efficient. It encourages the development of infra-structure that has low- > delay delivery paths, so that, for example, traffic from the north of France > to the south of France does not have to pass through New York just because > the two communicating sites subscribe to different providers. (If the > sites really *want* to have their traffic pass through New York, they can > accomplish that by loose source routing.) /matt -- Lt Matthew W Jonson jonson@server.af.mil snail-mail: Network Systems Engineer 205-416-4075 SSC/SSDN USAF DDN Program Office AV: 596-4075 Gunter AFB, AL 36114 Right: any opinions expressed herein are entirely my own, not the Government's From owner-big-internet@munnari.oz.au Sat Feb 20 10:24:19 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA27159; Sat, 20 Feb 1993 10:24:42 +1100 (from owner-big-internet) Return-Path: Received: from Sun.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19938; Sat, 20 Feb 1993 04:18:28 +1100 (from Bob.Hinden@Eng.Sun.COM) Received: from Eng.Sun.COM (zigzag-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA13658; Fri, 19 Feb 93 09:17:38 PST Received: from bigriver.Eng.Sun.COM (bigriver-248) by Eng.Sun.COM (4.1/SMI-4.1) id AA14936; Fri, 19 Feb 93 09:22:55 PST Received: by bigriver.Eng.Sun.COM (4.1/SMI-4.1) id AA04777; Fri, 19 Feb 93 09:17:35 PST Date: Fri, 19 Feb 93 09:17:35 PST From: Bob.Hinden@Eng.Sun.COM (Bob Hinden) Message-Id: <9302191717.AA04777@bigriver.Eng.Sun.COM> To: Tony Li Cc: big-internet@munnari.oz.au In-Reply-To: <199302190852.AA06094@lager.cisco.com> Subject: re: addressing Content-Length: 1522 Tony, > I disagree. Perhaps my implementor's hat is showing, but I don't > believe that the noise is anything significantly less than a factor of > two over say, a 50 year period. I certainly want to assume this > during the design to insure that we don't under-engineer things this > time. While I agree that "all countries" is still tractable for "big" > routers, this still implies that "small" routers cannot hold a full > routing table. This implies that we end up using default and that low > end routers may not be up to providing the best "quality" routing that > is available. While it would help me financially, I do NOT believe > that everyone that wants to do routing should buy a $50k cisco 7000. > ;-) > > I believe that ubiquitous, cheap, low end routers, connected to > digital services which allow arbitrary topology changes on demand > will drive IPv7 routing away from default routing and towards a full > routing table. I don't think it unreasonable to select design points for 5 to 10 years out which can only be done with high end solutions today. The scaling we have been seeing in hardware should easily be able to handle this. For example it took a high end router to do ethernet wire speed (~14Kpps) around five years ago. Now the same money will buy ~100Kpps. Todays low end $3-5K routers can do what it took a high end router to do five years ago. I am sure that CISCO and the other router vendors will continue to build faster/cheaper routers over time. :-) Bob From owner-big-internet@munnari.oz.au Sat Feb 20 15:44:28 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03037; Sat, 20 Feb 1993 15:44:33 +1100 (from owner-big-internet) Return-Path: Received: from nero.clearpoint.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20537; Sat, 20 Feb 1993 04:45:47 +1100 (from martillo@nero.clearpoint.com) Received: by nero.clearpoint.com (4.1/1.34) id AA20566; Wed, 10 Feb 93 19:47:48 EST Date: Wed, 10 Feb 93 19:47:48 EST From: martillo@nero.clearpoint.com (Joachim Carlo Santos Martillo Ajami) Message-Id: <9302110047.AA20566@nero.clearpoint.com> To: yakov@watson.ibm.com Cc: Christian.Huitema@sophia.inria.fr, big-internet@munnari.oz.au In-Reply-To: yakov@watson.ibm.com's message of Wed, 3 Feb 93 14:00:13 EST <9302031853.AA04693@nero.clearpoint.com> Subject: Metro Addressing Summary From: yakov@watson.ibm.com To: martillo@nero.clearpoint.com, Christian.Huitema@sophia.inria.fr, big-internet@munnari.oz.au Subject: Metro Addressing Summary Ref: Your note of Wed, 3 Feb 93 13:07:13 EST >Is this supposed to be a general principle ? Certainly, one can >build very complex physical network topologies with IEEE P802.1d >MAC bridging, yet the physical addresses used in a given network >are arbitrary. Building complex topologies is certainly one of the issues. However, there is another thing to consider -- building LARGE topologies. So, the question to ask is how well IEEE P802.1d MAC bridging is suitable for building LARGE topologies. Yakov. Hi Yakov, Granted, STP bridging suffers limitations in the building of networks with very large diameters. A different path selection procedure might support larger diameters but I would suggest that the problem of building very LARGE networks is made more tractable by first building comms subnets of big diameters (which could actually be IBM SR-bridged token rings) using first order packet switches (bridges) and then connecting these comms subnets in a large network topology using second order packet switches (routers). I have no doubt that building very LARGE topologies is possible using purely 2nd order packet switching technology but the approach may be needlessly complex. I also have no doubt that building very LARGE topologies is possible using purely first order packet switching technology but that approach is needlessly complex. Using the mixed first and second order packet switching probably simplifies the approach and in the case of IBM products actually makes fairly effective use of the logical subbridge architecture which -- I believe -- the 6611 supports. The observation of the benefits of the mixed approach is fundamental to the architecture of very large networks and is relatively independent of the nature (DV vs LS vs BROADCAST etc.) of the first order and second order routing protocols. Interestingly enough the mixed first/2nd order approach simplifies configuration and eliminates, obviates or reduces the problems associated with multiprotocol internetworks as described by Nick Lippis in "Too Many Protocols Can Break the Corporate Backbone" in Data Communications, February 1993, p. 27 and as described by Kelly Jackson Higgins in "When Nets Collide: Multiple protocols have created a world of multiple managers, multiple transmissions, multiple addresses and multiple headaches" in Communications Week, February 8, 1993, p.35. Joachim Carlo Santos Martillo Ajami The article represents noone's opinions other than the author's. From owner-big-internet@munnari.oz.au Sat Feb 20 18:48:22 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA07622; Sat, 20 Feb 1993 18:48:26 +1100 (from owner-big-internet) Return-Path: Received: from thumper.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24263; Sat, 20 Feb 1993 08:01:51 +1100 (from tsuchiya@thumper.bellcore.com) Received: from chiya.bellcore.com by thumper.bellcore.com (4.1/4.7) id for big-internet@munnari.oz.au; Fri, 19 Feb 93 15:40:53 EST Received: by chiya.bellcore.com (4.1/4.7) id for big-internet@munnari.oz.au; Fri, 19 Feb 93 15:40:51 EST Date: Fri, 19 Feb 93 15:40:51 EST From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Message-Id: <9302192040.AA13005@chiya.bellcore.com> To: big-internet@munnari.oz.au Subject: addressing bof announcement..... Gang, The addressing bof has been scheduled for the Monday evening slot at Columbus. This puts it opposite the BGP Deployment and VC Routing meetings, but it was the best conflict resolution we could do. I will chair the meeting. Bill Manning will be scribe, which in this case means detailed minutes (got that Bill?). Scott Brim will coordinate ordering Pizza. The meeting will start with presentations by myself, Steve Deering, and Tony Li on our favorite address assignments strategies. Note that we will *not* be presenting these strategies in the context of any of the IPv7 proposals..... Following this will be a well-ordered and rat-hole free discussion of the pros and cons of the various schemes, with the primary objective being agreement on what the pros and cons are. Documentation of these pros and cons will form the basis of an ongoing concensus process. A secondary goal is to produce recommendations, though reaching that kind of concensus might be difficult..... I'm willing to entertain other speakers, but I want to try to maintain focus on basic principals rather than have many presentations of schemes with just minor variations....... PX From owner-big-internet@munnari.oz.au Sat Feb 20 19:26:57 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA08492; Sat, 20 Feb 1993 19:27:04 +1100 (from owner-big-internet) Return-Path: Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26645; Sat, 20 Feb 1993 09:56:13 +1100 (from tli@cisco.com) Received: by lager.cisco.com; Fri, 19 Feb 1993 14:55:30 -0800 Date: Fri, 19 Feb 1993 14:55:30 -0800 From: Tony Li Message-Id: <199302192255.AA10173@lager.cisco.com> To: barns@cove.mitre.org Cc: big-internet@munnari.oz.au Subject: Re: addressing Bill, Tony's message reminds me of something that has been nagging me for a long time. Everyone agrees that there are options (and most people dislike some of them) but is the list complete? You can have full routing tables, default routes, hierarchically scoped locally-full tables, etc., but at least in principle you could have routing table fullness that responds to demand. Is it not possible to have demand- based route fetching without constraining the connection/flow/?? to a specific route? By route fetching, I mean to imply a process analogous to DNS name resolution, but distinct from it, with the distribution of knowledge organized in a way that is chosen to be good for routing performance. I don't mean to restrict this to any particular model of how centralized or decentralized the route computation process is. Caching (or "learning") is undoubtedly implied. Yes, this is very possible. In fact, this is one of the features that we would like to add to SDRP. Noel has a very nice name for this feature, but I don't recall what it is. Tony From owner-big-internet@munnari.oz.au Sun Feb 21 06:57:42 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA24455; Sun, 21 Feb 1993 06:57:45 +1100 (from owner-big-internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21771; Sun, 21 Feb 1993 04:18:25 +1100 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA29646; Sat, 20 Feb 93 12:17:38 -0500 Date: Sat, 20 Feb 93 12:17:38 -0500 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9302201717.AA29646@ginger.lcs.mit.edu> To: barns@cove.mitre.org, tli@cisco.com Subject: Re: addressing Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu Noel has a very nice name for this feature, but I don't recall what it is. The terminology (and thus concepts) Bill used (which seems to be pretty heavily routing table oriented) is sort of at right angles from the way Nimrod (which is S-D pair route computation on demand) looks at the whole issue of i) route computation, ii) how to distribute the data used in the route computation process, and iii) what the data which is distributed looks like. (These are given in dependency order; item iii) is the most primitive, and the others are built up on it.) This makes it a little hard to tell exactly what it is you are thinking of, but I suspect you are thinking of the "incoming abstaction algorithm" (which may also be called Local Abstraction Control, or LAC). It isn't so much route fetching, as it is map fetching (i.e. step ii above); i.e. getting a more detailed map. With the enhanced map, you can obviously calculate more potential routes (in step i). This is one of the reasons I really like Map Distribution algorithms (the class of things that SPF and LS fall into), since the fact that phases ii) and iii) are clearly separated allows you more variation in how to do each. The intertwining of ii) and iii) in DV systems makes it more difficult to do computation of routes on demand, particularly with locally-requested optimizations. (Please, I didn't mean to restart the debate about the relative values of DV and MD; just pointing out *one specific* point). Noel From owner-Big-Internet@munnari.oz.au Sun Feb 21 14:42:39 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA05823; Sun, 21 Feb 1993 14:42:56 +1100 (from owner-Big-Internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05806; Sun, 21 Feb 1993 14:42:39 +1100 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA00551; Sat, 20 Feb 93 22:42:21 -0500 Date: Sat, 20 Feb 93 22:42:21 -0500 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9302210342.AA00551@ginger.lcs.mit.edu> To: barns@cove.mitre.org, tli@cisco.com Subject: Re: addressing Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu the fact that phases ii) and iii) are clearly separated ... The intertwining of ii) and iii) Pardon my inability to type, but I (obviously) meant "i) and ii)", not "ii) and iii)" here. Noel From owner-Big-Internet@munnari.oz.au Mon Feb 22 02:11:16 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21135; Mon, 22 Feb 1993 02:11:23 +1100 (from owner-Big-Internet) Return-Path: Message-Id: <9302211511.21135@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21132; Mon, 22 Feb 1993 02:11:16 +1100 (from J.Crowcroft@cs.ucl.ac.uk) Received: from mortimer.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Sun, 21 Feb 1993 15:11:06 +0000 To: big-internet@munnari.oz.au Subject: address assignent Date: Sun, 21 Feb 93 15:11:04 +0000 From: Jon Crowcroft a very big international company here are just about to go IP on their largely propietary network they already have a worldwide address allocation with (roughly ) continental structured 24 bit addresses i ntheir own protocol architecture, and were trying to get a class A number and use subnetting over this (seemed bvious to them...) - i suggested they try lots of Cs and CIDR, but they were loath coz of lack of products anyone care to help me help them? (they have 45,000 systems in london alone, and make extensive use of multicast) jon From owner-Big-Internet@munnari.oz.au Mon Feb 22 05:09:07 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA24278; Mon, 22 Feb 1993 05:09:14 +1100 (from owner-Big-Internet) Return-Path: Received: from p.lanl.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24275; Mon, 22 Feb 1993 05:09:07 +1100 (from peter@goshawk.lanl.gov) Received: from goshawk.lanl.gov by p.lanl.gov (5.65/1.14) id AA28615; Sun, 21 Feb 93 11:09:01 -0700 Received: from localhost.lanl.gov by goshawk.lanl.gov (4.1/5.17) id AA19252; Sun, 21 Feb 93 11:09:00 MST Message-Id: <9302211809.AA19252@goshawk.lanl.gov> To: Jon Crowcroft Cc: big-internet@munnari.oz.au Subject: Re: address assignent In-Reply-To: Your message of Sun, 21 Feb 93 15:11:04 +0000. <9302211511.21135@munnari.oz.au> Date: Sun, 21 Feb 93 11:09:00 MST From: peter@goshawk.lanl.gov Jon, I can only report what has been said publicly viz. CIDR. CISCO, Wellfleet, Proteon, 3Com and BBN have all reported they are targeting BGP-4 for their routers. Everybody says something like (mumble, mumble) mid summer for early availability. ANS, Sprint, EBONE have commited to CIDR and from a regional techs meeting here in the U.S. many regionals have already commited to CIDR using block allocations out of C space. As a group, the transit networks are planning their roll out of BGP-4 and there are several meetings planned by the transit providers to coordinate their BGP-4 peering. You might recommend they hold off, and send someone to the Columbus IETF so they can get a first hand report of how BGP-4 development and deployment is going. You should also point them to the bgp deployment mailing list: bgpd-request@merit.edu. Given their size, it could easily make sense for them to get a block of class Bs which they CIDR into a single inter-domain routing entry later on, but allows them to subnet internally today. It is not optimal in the global sense, but it may be the right solution at this time. Big outstanding questions: when do they absolutely need to advertise out to the global Internet? If its late this year then they should be able to use C's. If they really need to turn on right away, I would see them in a block of B's. It sounds like they have a big conversion/transition project in the works so the latter time mark sounds right, but this is speculation on my part. Class A addresses should not be used anymore. They are the Internet savings account. People with class As and only use a tiny fraction ( < 1 %) of their address space (16 million hosts!) should be renumbering and turning their A back in. cheers, peter From owner-Big-Internet@munnari.oz.au Mon Feb 22 19:34:33 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA19129; Mon, 22 Feb 1993 19:34:48 +1100 (from owner-Big-Internet) Return-Path: Received: from mitsou.inria.fr by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19120; Mon, 22 Feb 1993 19:34:33 +1100 (from huitema@mitsou.inria.fr) Received: by mitsou.inria.fr (5.65c/IDA-1.2.8) id AA16891; Mon, 22 Feb 1993 09:36:54 +0100 Message-Id: <199302220836.AA16891@mitsou.inria.fr> To: hitchcoc@oerv01.er.doe.gov (Dan Hitchcock) Cc: deering@parc.xerox.com, tli@cisco.com, big-internet@munnari.oz.au Subject: Re: addressing In-Reply-To: Your message of "Fri, 19 Feb 93 11:26:18 EST." <9302191626.AA16809@er.doe.gov> Date: Mon, 22 Feb 93 09:36:52 +0100 From: Christian Huitema >This sort of plan does not cover all cases but would form a basis for discussion >of the types of things that might be possible and economically likely. It >would, for example be useful to construct a map of the world with this new >metric just to see what the real topology we face today is. > >Dan Hitchcock Dan, Your observation on distances is absolutely correct. One could object that this is based on current history, and that in the long run geographical "realities" will prevail, but, as I mentioned in a previous message, I believe that the telecommunication costs are primarily governed by economics, not geographics. Your map exercise, however, is likely to be "interesting". There is no particular reason to believe that you can simply go away with a 2D map, or even with a spherical surface. I sort of have the feeling that the space has at least one dimension per major telco hub, or maybe 2d per country. I am not even sure that you can map on a finite dimension linear space! Christian Huitema From owner-Big-Internet@munnari.oz.au Mon Feb 22 20:30:25 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA20475; Mon, 22 Feb 1993 20:30:35 +1100 (from owner-Big-Internet) Return-Path: Received: from mitsou.inria.fr by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20470; Mon, 22 Feb 1993 20:30:25 +1100 (from huitema@mitsou.inria.fr) Received: by mitsou.inria.fr (5.65c/IDA-1.2.8) id AA16981; Mon, 22 Feb 1993 10:33:12 +0100 Message-Id: <199302220933.AA16981@mitsou.inria.fr> To: peter@goshawk.lanl.gov Cc: Jon Crowcroft , big-internet@munnari.oz.au Subject: Re: address assignent In-Reply-To: Your message of "Sun, 21 Feb 93 11:09:00 MST." <9302211809.AA19252@goshawk.lanl.gov> Date: Mon, 22 Feb 93 10:33:12 +0100 From: Christian Huitema >You might recommend they hold off, and send someone to the Columbus IETF >so they can get a first hand report of how BGP-4 development and deployment >is going... Peter, You get exactly zero brownie points for that! The IETF is not supposed to be a place where you go and look, but a place where you meet and work! Please don't advertize it as a cheap way to get up to date information for outsiders... Christian Huitema From owner-Big-Internet@munnari.oz.au Tue Feb 23 01:51:10 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA29443; Tue, 23 Feb 1993 01:51:24 +1100 (from owner-Big-Internet) Return-Path: Received: from nero.clearpoint.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29440; Tue, 23 Feb 1993 01:51:10 +1100 (from martillo@nero.clearpoint.com) Received: by nero.clearpoint.com (4.1/1.34) id AA26307; Mon, 22 Feb 93 09:41:30 EST Date: Mon, 22 Feb 93 09:41:30 EST From: martillo@nero.clearpoint.com (Joachim Carlo Santos Martillo Ajami) Message-Id: <9302221441.AA26307@nero.clearpoint.com> To: Christian.Huitema@sophia.inria.fr Cc: peter@goshawk.lanl.gov, J.Crowcroft@cs.ucl.ac.uk, big-internet@munnari.oz.au In-Reply-To: Christian Huitema's message of Mon, 22 Feb 93 10:33:12 +0100 <199302220933.AA16981@mitsou.inria.fr> Subject: address assignent To: peter@goshawk.lanl.gov Cc: Jon Crowcroft , big-internet@munnari.oz.au Subject: Re: address assignent Date: Mon, 22 Feb 93 10:33:12 +0100 From: Christian Huitema >You might recommend they hold off, and send someone to the Columbus IETF >so they can get a first hand report of how BGP-4 development and deployment >is going... Peter, You get exactly zero brownie points for that! The IETF is not supposed to be a place where you go and look, but a place where you meet and work! Please don't advertize it as a cheap way to get up to date information for outsiders... Christian Huitema What is this outsider stuff? As far as I know, the IETF is open to anyone and in fact requires no qualifications. In fact, if my experiance as a contractor at the major computer manufacturers is any indication, in computer and communications engineering there is a simple rule of thumb: those, who can, do, those, who can't, do standards. Joachim Carlo Santos Martillo Ajami The article represents noone's opinions other than the author's. From owner-Big-Internet@munnari.oz.au Tue Feb 23 09:25:18 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA11701; Tue, 23 Feb 1993 09:25:29 +1100 (from owner-Big-Internet) Return-Path: Received: from p.lanl.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11693; Tue, 23 Feb 1993 09:25:18 +1100 (from peter@goshawk.lanl.gov) Received: from goshawk.lanl.gov by p.lanl.gov (5.65/1.14) id AA08303; Mon, 22 Feb 93 15:25:06 -0700 Received: from localhost.lanl.gov by goshawk.lanl.gov (4.1/5.17) id AA00802; Mon, 22 Feb 93 15:25:05 MST Message-Id: <9302222225.AA00802@goshawk.lanl.gov> To: Christian Huitema Cc: Jon Crowcroft , big-internet@munnari.oz.au Subject: Re: address assignent In-Reply-To: Your message of Mon, 22 Feb 93 10:33:12 +0100. <199302220933.AA16981@mitsou.inria.fr> Date: Mon, 22 Feb 93 15:25:04 MST From: peter@goshawk.lanl.gov Christian, I don't consider people who are planning to bring a huge network onto the Internet as "outsider"s. Also, such a person will undoubtedly bring a perspective to the BGP deployment working group that could be very valuable. Many IETF efforts would benefit from closer contact with "customers" in the process of standards setting. cheers, peter From owner-Big-Internet@munnari.oz.au Tue Feb 23 19:14:56 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03181; Tue, 23 Feb 1993 19:15:11 +1100 (from owner-Big-Internet) Return-Path: Received: from mitsou.inria.fr by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03168; Tue, 23 Feb 1993 19:14:56 +1100 (from huitema@mitsou.inria.fr) Received: by mitsou.inria.fr (5.65c/IDA-1.2.8) id AA19067; Tue, 23 Feb 1993 09:17:49 +0100 Message-Id: <199302230817.AA19067@mitsou.inria.fr> To: peter@goshawk.lanl.gov Cc: Jon Crowcroft , big-internet@munnari.oz.au Subject: Re: address assignent In-Reply-To: Your message of "Mon, 22 Feb 93 15:25:04 MST." <9302222225.AA00802@goshawk.lanl.gov> Date: Tue, 23 Feb 93 09:17:48 +0100 From: Christian Huitema Peter, I was merely criticizing your wordings, not the idea that the manager of a large network should participate to the BGP (and others) working groups. The point is that one should not come to the IETF to "visit and get info" but to "participate to the work". I absolutely agree with you that "Many IETF efforts would benefit from closer contact with "customers" in the process of standards setting". Christian Huitema From owner-Big-Internet@munnari.oz.au Tue Feb 23 19:36:19 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03715; Tue, 23 Feb 1993 19:36:27 +1100 (from owner-Big-Internet) Return-Path: Message-Id: <9302230836.3715@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03706; Tue, 23 Feb 1993 19:36:19 +1100 (from J.Crowcroft@cs.ucl.ac.uk) Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 23 Feb 1993 08:34:57 +0000 To: peter@goshawk.lanl.gov Cc: Christian Huitema , big-internet@munnari.oz.au Subject: Re: address assignent In-Reply-To: Your message of "Mon, 22 Feb 93 15:25:04 MST." <9302222225.AA00802@goshawk.lanl.gov> Date: Tue, 23 Feb 93 08:34:53 +0000 From: Jon Crowcroft >very valuable. Many IETF efforts would benefit from closer contact >with "customers" in the process of standards setting. peter precisely why i bought this up! thanks for the feedback... jon From owner-Big-Internet@munnari.oz.au Wed Feb 24 02:18:33 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15437; Wed, 24 Feb 1993 02:18:43 +1100 (from owner-Big-Internet) Return-Path: Received: from p.lanl.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15430; Wed, 24 Feb 1993 02:18:33 +1100 (from peter@goshawk.lanl.gov) Received: from goshawk.lanl.gov by p.lanl.gov (5.65/1.14) id AA09913; Tue, 23 Feb 93 08:18:24 -0700 Received: from localhost.lanl.gov by goshawk.lanl.gov (4.1/5.17) id AA08984; Tue, 23 Feb 93 08:18:23 MST Message-Id: <9302231518.AA08984@goshawk.lanl.gov> To: Christian Huitema Cc: Jon Crowcroft , big-internet@munnari.oz.au Subject: Re: address assignent In-Reply-To: Your message of Tue, 23 Feb 93 09:17:48 +0100. <199302230817.AA19067@mitsou.inria.fr> Date: Tue, 23 Feb 93 08:18:22 MST From: peter@goshawk.lanl.gov Christian, I am sure we are not getting crosswise on this issue, especially since we seem to share the same goals and objectives for the IETF. cheers, peter From owner-Big-Internet@munnari.oz.au Wed Feb 24 07:02:54 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA23232; Wed, 24 Feb 1993 07:08:17 +1100 (from owner-Big-Internet) Return-Path: Message-Id: <9302232008.23232@munnari.oz.au> Received: from [192.246.52.2] by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23120; Wed, 24 Feb 1993 07:02:54 +1100 (from miker@jupiter.fuentez.com) From: miker@jupiter.fuentez.com Date: Tue, 23 Feb 93 14:58 EST To: big-internet@munnari.oz.au Folks: Please add me to the big-internet mailing list. Content-Type: text Content-Length: 587 Please note that I've just put a piece of our corporate net on the Internet, and I'm not sure whether the domain info I got from our connection providers (PSI) has bubbled into the main domain name servers. If you get problems in domain name resolution, the mail server for fuentez.com is at 192.246.52.2 and is called jupiter.fuentez.com. Thanks in advance, Mike Robitaille 11781 Lee Jackson Highway miker@fuentez.com Fairfax. VA 22033 Fuentez Systems Concepts, Inc (703) 273-1447 Fax: (703) 273-2972 From owner-Big-Internet@munnari.oz.au Fri Feb 26 04:10:53 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA24316; Fri, 26 Feb 1993 04:11:57 +1100 (from owner-Big-Internet) Return-Path: Received: from thumper.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24306; Fri, 26 Feb 1993 04:10:53 +1100 (from tsuchiya@thumper.bellcore.com) Received: from chiya.bellcore.com by thumper.bellcore.com (4.1/4.7) id for big-internet@munnari.oz.au; Thu, 25 Feb 93 12:10:25 EST Received: by chiya.bellcore.com (4.1/4.7) id for ietf@cnri.reston.va.us; Thu, 25 Feb 93 12:10:24 EST Date: Thu, 25 Feb 93 12:10:24 EST From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Message-Id: <9302251710.AA22296@chiya.bellcore.com> To: big-internet@munnari.oz.au, ietf@cnri.reston.va.us Subject: IPv7 address bof call for participation and announcement.... On Monday night of the Columbus IETF, a bof on the topic of address assignment for IPv7 will be held. The purpose of the bof is to discuss and document the pros and cons of various techniques, especially provider-oriented versus geography-oriented schemes. A secondary goal (if possible) is to make recommendations. Steve Deering, Tony Li, and Paul Tsuchiya will be making presentations of the schemes they endorse (said schemes will be documented in advance of the bof.....) I believe the choice of addressing scheme has far-reaching consequences, for instance with respect to how providers must be interconnected, how often private networks must modify their addresses, who owns addresses, and so on. Thus, I'd like to see good representation of providers, private network administrators, and potential address assignment authorities (IANA and ISOC.....) at the meeting. I'm not exactly sure how to format this representation--something less than a panel but more than just voices from the audience..... I'm looking for people who can provide such representation, and I'm looking for ideas on how best to format the meeting. Please respond to me only. I'll summarize the ideas..... Thanks, PX