From owner-Big-Internet@munnari.oz.au Fri Jan 1 00:48:48 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA10070; Fri, 1 Jan 1993 00:49:09 +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 AA10058; Fri, 1 Jan 1993 00:48:48 +1100 (from craig@aland.bbn.com) Received: from port12.sunnyvale.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) id AA17441; Thu, 31 Dec 92 08:48:32 -0500 Received: by aland.bbn.com (4.1/3.1.090690-BBN) id AA22019; Thu, 31 Dec 92 05:39:01 PST Message-Id: <9212311339.AA22019@aland.bbn.com> To: ljm@ftp.com (leo j mclaughlin iii) Cc: big-internet@munnari.oz.au Subject: Re: having the market decide From: Craig Partridge Date: Thu, 31 Dec 92 05:39:01 -0800 Sender: craig@aland.bbn.com >> We didn't handle this process as cleanly as we might have for SNMP/CMOT. >> Having had the experience, I'd like to see us do it better this time around. > > Having witnessed a good bit of this, I'm not sure if we could do much > better than we did with SNMP/CMOT. Leo: Sigh... actually, you came in rather late. SNMP was a reaction to HEMS, (my proposal with Glenn Trewitt) not CMOT. At the Summer '87 IETF, Marty and Jeff got up and said they didn't think the HEMS spec and prototype implementation would be done by January '88, and so they'd developed something simpler (namely SGMP). CMOT really materialized about the same time, after Marshall Rose (yep, him), was asked by Dave Crocker (Marshall's then boss) to go look in on a CMIP over TCP meeting and rather than just sit there, Marshall spent the meeting helping the CMIP folks solve the key problems of putting CMIP over TCP. The result was that by winter of '88, we had three camps: * CMOT, which claimed it should be accepted because it was OSI and a small test implementation would be finished by fall '88. * SGMP, which claimed it should be accepted because it had been deployed in some regionals. * HEMS, which claimed it should be accepted because it was technically superior to CMOT and SGMP and the prototype implementation had been completed. All three proposals had vendors behind them, who stated they were prepared to implement the spec. The IAB held a review meeting to try to decide which standard to pick and instead concluded that all three sets of claims were valid and it didn't know how to decide. The only way that we got to a decision at all was that I stood up and offered to withdraw HEMS as a contender if that would result in a solution. (Read Marshall's, Open Book, if you want substantiation). The result was that the SGMP folks agreed to develop SNMP and address some of the limitations of SGMP, and the CMOT folks agreed to be labelled the "future solution" with SNMP being implemented as an "interim" solution. There was no notion the market would decide, rather the IAB/IETF was trying to dictate what would happen. The market did, in fact, actually make the decision. But there was much pain too -- CMOT lingered on, leading to confusing standards decisions and muddled articles in the media. Even though many of the limitations of SNMP, now being fixed in SMP, were known before SNMP was deployed, they were accepted because SNMP was not a long term solution. I'd like to avoid that kind of muddle this time. Obviously, this is my personal view of the history. I'm sure others have slightly different views -- as one of the designers of HEMS, I'm sure I have a different perspective from other participants. But I think this is essentially an accurate portrayal of the situation. Yes, in the end, SNMP did OK and we're all grateful. But getting to this point hurt more than it should have. Craig From owner-Big-Internet@munnari.oz.au Fri Jan 1 03:58:57 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA14816; Fri, 1 Jan 1993 03:59:04 +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 AA14813; Fri, 1 Jan 1993 03:58:57 +1100 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA10454; Thu, 31 Dec 92 11:58:40 -0500 Date: Thu, 31 Dec 92 11:58:40 -0500 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9212311658.AA10454@ginger.lcs.mit.edu> To: craig@aland.bbn.com, ljm@ftp.com Subject: Re: having the market decide Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu The only way that we got to a decision at all was that I stood up and offered to withdraw HEMS as a contender if that would result in a solution. (Read Marshall's, Open Book, if you want substantiation). Reading the book not needed; I recall the scene very clearly. The IAB had convened a meeting (somewhere in CA?), chaired by Vint Cerf, to decide what to do about network management. (I was on site for somthing else, I forget what, and wandered in after my meeting was over.) I can still see Craig rising slowly to his feet to announce that, in the interests of progress, he was offering to withdraw HEMS. I often wish others in the Internet could have taken a lesson from him.... the level of respect he currently enjoys is due in no small part to his actions that day, so it wasn't a total loss by any means. * SGMP, which claimed it should be accepted because it had been deployed in some regionals. * HEMS, which claimed it should be accepted because it was technically superior to CMOT and SGMP and the prototype implementation had been completed. I think this is a slight gloss on the technical differences; the SGMP/SNMP camp weren't 100% motivated by quick-deployment feeling. I think the SGMP/SNMP camp definitely had philosophical differences with the HEMS camp over where exactly to place the split between mechanism in the client and in the server; i.e. how complex do you want the servers to be. The impression I got was that the SNMP/SGMP people felt the server should be the absolute minimum, even at the cost of extra complexity in the client; this lead to the simple read/write model of SGMP/SNMP. Perhaps SNMP was a little too simple (i.e. the lack of an ability to read out a group of related objects in a consistent state), but I'm not sure their basic philosophy was wrong. (Separate debate! :-) The result was that ... CMOT ... agreed to be labelled the "future solution" with SNMP being implemented as an "interim" solution. There was no notion the market would decide, rather the IAB/IETF was trying to dictate what would happen. This was certainly true of the IAB, but I have a strong feeling that the SNMP camp went away pleased, quietly satisfied that SNMP was going to gain an ineradicable toehold, and that CMOT would never amount to much (i.e. they had a good model of the future); and I have a guess that the CMOT people went away with a nagging feeling that they had gotten a bad bargain. Obviously, this is my personal view of the history. I'm sure others have slightly different views ... But I think this is essentially an accurate portrayal of the situation. Generally quite accurate, from my perspective, with the minor adjustments noted above. But getting to this point hurt more than it should have. Yes, and let's try and do better this time, huh? :-) "Experience is a dear master, but fools will learn at no other." We may have paid once, but let's try and use that experience to figure out how not to do it again! Noel From owner-Big-Internet@munnari.oz.au Fri Jan 1 04:51:50 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA16300; Fri, 1 Jan 1993 04:52:05 +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 AA16297; Fri, 1 Jan 1993 04:51:50 +1100 (from craig@aland.bbn.com) Received: from port12.sunnyvale.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) id AA00972; Thu, 31 Dec 92 12:48:28 -0500 Received: by aland.bbn.com (4.1/3.1.090690-BBN) id AA23838; Thu, 31 Dec 92 09:50:02 PST Message-Id: <9212311750.AA23838@aland.bbn.com> To: big-internet@munnari.oz.au Subject: what to do differently Reply-To: Craig Partridge From: Craig Partridge Date: Thu, 31 Dec 92 09:50:02 -0800 Sender: craig@aland.bbn.com John Curran asked me to try to be specific about what I think we should do differently for IPv7 based on experience with the network management decision process. So, here are a few suggestions. * Understand our requirements. For network management, our only requirement was that we "be able to manage the Internet." As a result, design goals differed very widely. One of SGMP's goal was to make the code in the server small. One of HEMS' goal was to try to balance the load on the servers and the network. So far as I remember, CMOT never addressed this question. One side effect was that on many technical questions, the debate rapidly became on of philosophy instead -- so technical questions didn't get answered because they were viewed as "religious" rather than technical. I think developing the criteria document helps this problem some. But we need to be firm about having people answer questions in detail -- not argue about design philosophy. * Force folks to put implementations where their mouths are. At the IAB review meeting, CMOT won hands down in terms of major corporate backing, press publicity, folks willing to say they would support it, and government types and potential customers saying they'd buy it. SGMP had 3 implementations which had been deployed; HEMS had 1 that had only been used in a test on a few machines; CMOT had a demo. Yet CMOT was given tremendous credibility based on the endorsements, which proved to be worthless. I believe the moral here is don't listen too hard to any vendor who doesn't have an implementation. I'm not sure what to do about users who claim they want one thing and buy another. * Assume IETF affects but doesn't fully control the decision. It seems to me that part of the network management problem (in retrospect) is that the IETF/IAB had a stake in being the deciding agency. So, for example, even as CMOT became increasingly irrelevant, it was promoted to Draft Standard status because the IETF/IAB so much wanted to believe that CMOT was going to be the future protocol. It seems to me that the IETF role now is to try to make sure that poor proposals or proposals that lack key features are not given an IETF imprimature. In other words, don't let any protocol get to, say Proposed Standard, without demonstrating that it meets our MUST requirements in the criteria document. Craig From owner-Big-Internet@munnari.oz.au Fri Jan 1 18:23:02 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA05309; Fri, 1 Jan 1993 18:23: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 AA05306; Fri, 1 Jan 1993 18:23:02 +1100 (from ljm@ftp.com) Received: from ljm.leather-lace.ftp.com by ftp.com via PCMAIL with DMSP id AA29648; Fri, 1 Jan 93 02:23:02 -0500 Date: Fri, 1 Jan 93 02:23:02 -0500 Message-Id: <9301010723.AA29648@ftp.com> To: craig@aland.bbn.com Subject: Re: having the market decide From: ljm@ftp.com (leo j mclaughlin iii) Reply-To: ljm@ftp.com Cc: big-internet@munnari.oz.au Sender: ljm@ftp.com Repository: babyoil.ftp.com Originating-Client: leather-lace.ftp.com >>> We didn't handle this process as cleanly as we might have for SNMP/CMOT. >>> Having had the experience, I'd like to see us do it better this time around. >> >> Having witnessed a good bit of this, I'm not sure if we could do much >> better than we did with SNMP/CMOT. > >Sigh... actually, you came in rather late. SNMP was a reaction to HEMS, >(my proposal with Glenn Trewitt) not CMOT. At the Summer '87 IETF, Marty >and Jeff got up and said they didn't think the HEMS spec and prototype >implementation would be done by January '88, and so they'd developed something >simpler (namely SGMP). CMOT really materialized about the same time, after >Marshall Rose (yep, him), was asked by Dave Crocker (Marshall's then boss)... Yup, and don't forget Keith...he was at Wollyworld with the rest of us. > >There was no notion the market would decide, rather the IAB/IETF was trying >to dictate what would happen.... It was certainly taken for granted that the market would decide in (at least in our little piece of) the SNMP camp. The tremendous rush to push out those first, feeble SNMP mgt stations ended up being justified by the immediate positive push toward SNMP at the following Interop and (in the longer term) by the spread of SNMP outside the Internet community. >.... But there was much pain too -- CMOT lingered on, leading to >confusing standards decisions and muddled articles in the media. Even though >many of the limitations of SNMP, now being fixed in SMP, were known before >SNMP was deployed, they were accepted because SNMP was not a long term >solution.... Well, um, er, they were accepted because certain parties were effective in limiting distractions within the SNMP camp about such dread issues as proxy-SNMP and security. Whether this was good or bad is open to debate, but it certainly served to keep folk concentrated on fielding implementations of the protocol as it existed. > >I'd like to avoid that kind of muddle this time. > Why? IMHO, the IETF succeeds because it not only allows but encourages protocol 'competition' by requiring some significant degree of implementation and operational experience. My thesis is that SNMP would not have gone from conception to world-wide, multi-protocol embracing reality were it not for the existance of other competing protocols spuring development and productization, that this is true of people, protocols, and products in general, and that IPv7 (whatever form that may take) will come about more quickly and gain wider acceptance in the presence of other claimants. enjoy, leo j mclaughlin iii ljm@ftp.com From owner-Big-Internet@munnari.oz.au Tue Jan 5 02:38:46 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA27225; Tue, 5 Jan 1993 02:38:53 +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 AA27222; Tue, 5 Jan 1993 02:38:46 +1100 (from kasten@ftp.com) Received: by ftp.com id AA21572; Mon, 4 Jan 93 10:38:32 -0500 Date: Mon, 4 Jan 93 10:38:32 -0500 Message-Id: <9301041538.AA21572@ftp.com> To: Craig Partridge Subject: Re: what to do differently From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: big-internet@munnari.oz.au > > * Force folks to put implementations where their mouths are. > > At the IAB review meeting, CMOT won hands down in terms of major corporate > backing, press publicity, folks willing to say they would support it, and > government types and potential customers saying they'd buy it. > > SGMP had 3 implementations which had been deployed; HEMS had 1 that had > only been used in a test on a few machines; CMOT had a demo. When SGMP turned into SNMP at least two implementations were publically available (CMU and MIT). This was, in my mind, A MAJOR FACTOR in determining the "outcome" of the "Network Management Wars". At that time we (where I was working) were not sure whether to do SNMP or CMOT. We decided to adopt a wait-and-see attitude. However, during that time the CMU and MIT implementations were made available, so I decided to do a little testing and playing with them -- just to learn more about SNMP, etc, etc. In a matter of a week or two I had a trivial PC-based agent and a primitive PC-based "manager" (I use that term very very loosely :-). We then decided to go with SNMP since we had an existance proof of its usefulness, workability, simplicity, etc etc. -- Frank Kastenholz From owner-Big-Internet@munnari.oz.au Tue Jan 5 05:32:55 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA02313; Tue, 5 Jan 1993 05:33:03 +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 AA02310; Tue, 5 Jan 1993 05:32:55 +1100 (from braden@ISI.EDU) Received: by zephyr.isi.edu (5.65c/5.61+local-9) id ; Mon, 4 Jan 1993 10:31:24 -0800 Date: Mon, 4 Jan 1993 10:31:24 -0800 From: braden@ISI.EDU (Bob Braden) Message-Id: <199301041831.AA25984@zephyr.isi.edu> To: big-internet@munnari.oz.au Subject: Re: having the market decide > > > >There was no notion the market would decide, rather the IAB/IETF was trying > >to dictate what would happen... Early in the process (I could pull the dates out of old minutes and messages if you want), the IAB initiated and held a meeting of the three camps, hoping that a technical concensus would emerge. It appeared to the IAB that (1) network management was a terribly important but hitherto neglected area of Internet protocol development, and (2) that the community would be best served by having a SINGLE standard in this this area. Craig played a rather heroic role at that meeting. Yes, it was the IAB's management model at the time that the IAB was the only "authority" in a position to make a final choice among the three, and that the good of the community demanded that such a choice be made. However, as controversy and large ($$$$$$) forces began to buffet the network management area, the IAB reconsidered its own management model, and decided (my memory says about 9 months later) that neither the objective technical situation nor the political realities would support such a choice imposed by the IAB. Therefore, the IAB explicitly decided to let the market decide. You may regard this as an empty decision, given the circumstances, and it felt somewhat gutless, but it was the right, as well as the only possible) decision, I believe. Bob Braden (for himself and History) [I also believe that the IETF enterprise will prosper in the future if and only if the "New World Order" creates a management structure that the IETF membership will allow to make tough decisions on behalf of the community as a whole]. From owner-Big-Internet@munnari.oz.au Fri Jan 8 19:35:28 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA19227; Fri, 8 Jan 1993 19:35:33 +1100 (from owner-Big-Internet) Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AB19220; Fri, 8 Jan 1993 19:35:28 +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 AA12337 Fri, 8 Jan 1993 19:35:27 +1100 (from kre@cs.mu.OZ.AU) Received: from ub-gate.UB.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03008; Thu, 7 Jan 1993 05:17:05 +1100 (from solensky@andr.UB.com) Return-Path: Received: from sunny.andr.UB.com (sunny.andr.UB.com) by ub-gate.UB.com (4.1/SMI-4.1[UB-1.8]) id AA23592; Wed, 6 Jan 93 10:16:58 PST Received: from fenway.andr.UB.com by sunny.andr.UB.com (4.1/SMI-4.1) id AA04186; Wed, 6 Jan 93 13:17:05 EST Received: by fenway.andr.UB.com (4.1/SMI-4.1) id AA17843; Wed, 6 Jan 93 13:15:55 EST Date: Wed, 6 Jan 93 13:15:55 EST From: Frank T Solensky Message-Id: <9301061815.AA17843@fenway.andr.UB.com> To: kre@munnari.oz.au Subject: New growth charts Resent-To: Big-Internet@munnari.OZ.AU Resent-Date: Fri, 08 Jan 1993 19:35:18 +1100 Resent-Message-Id: <3532.726482118@cs.mu.OZ.AU> Resent-From: Robert Elz The monthly NFSnet growth charts have just been made available at munnari.oz.au:big-internet/nsf-netnumbers-9301.ps via anonymous FTP. The prediction made for the number of networks at this point of time was _way_ off (7958 predicted, 8561 actual): so much so that I had to add an extra datapoint in the middle of the month in order to find a place that I could start estimating the final trend line. The number of networks continues to almost double annually: there were 4305 networks in the NSFNet policy routing database one year ago. Looking at the first graph again, one can almost see a trend over the last six or seven months in the predicted-vs-actuals network counts: throughout the summer, the current trend line lies above the actual data points; the converse is true over the last couple of months. This is made more clear on the graph of the third page which simply zooms into the 1992 section of the graph. Fourth page: I added more intermediate data points in order to place a greater weight on the end of the time series. The difference between the two trend lines is barely perceptible, but it does come closer. I _hope_ over the next month or so that I'll be able to get a better fit in this section by adding more recent datapoints and throwing out older ones, but so far this is the best fit. Fifth page: the revised trend line. It peaks out at just under 185k nets. It's also worth keeping in mind that these are CIDR-less counts -- I also hope at some point to be able to see how much of the recent growth is due to organizations being assigned multiple Cs rather than a single B and to project out how much CIDR will help in that regard.. -- Frank From owner-Big-Internet@munnari.oz.au Sat Jan 9 04:25:34 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA08612; Sat, 9 Jan 1993 04:26:01 +1100 (from owner-Big-Internet) Return-Path: Received: from SAFFRON.ACC.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08580; Sat, 9 Jan 1993 04:25:34 +1100 (from fbaker@acc.com) Received: by saffron.acc.com (4.1/SMI-4.1) id AA00345; Fri, 8 Jan 93 09:25:23 PST Date: Fri, 8 Jan 93 09:25:23 PST From: fbaker@acc.com (Fred Baker) Message-Id: <9301081725.AA00345@saffron.acc.com> To: solensky@andr.UB.com Subject: Re: New growth charts Cc: Big-Internet@munnari.OZ.AU, kre@munnari.oz.au Frank: Your charts call to mind a conversation between God and Jerimiah. Jerimiah was complaining that things were getting pretty tough; God replied (making reference to the way that armies in battle were organized c. 650 BC) "If you are getting tired running with the foot soldiers, what will you do when the chariots come?" Both projections seem to indicate slightly accellerating growth over the next (roughly) two years, and then growth at the rate acheived for (roughly) two more. The question, the difference between the projections, is: what is the peak growth *rate*? I wonder if there is any seasonal behavior that should be accounted for in the models? That, of course, we can't know based on one year's data, but are there more years we can look at? Could it possibly be that the rate of network installation correlates to holiday seasons (Christmas, August in Europe, ...) either in giving the operations staff a breather to add them or in slowing up the rate of requests? If so, the fluctuations around the trend line may need to be smoothed out somewhat. It seems to me that what we can deduce at the moment is that the real peak network count probably lies somewhere between the estimates of your first and last charts, which is to say 70K < reality < 185K From owner-Big-Internet@munnari.oz.au Sat Jan 9 06:56:52 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA14869; Sat, 9 Jan 1993 06:57:11 +1100 (from owner-Big-Internet) Return-Path: Received: from ub-gate.UB.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14856; Sat, 9 Jan 1993 06:56:52 +1100 (from solensky@andr.UB.com) Received: from sunny.andr.UB.com (sunny.andr.UB.com) by ub-gate.UB.com (4.1/SMI-4.1[UB-1.8]) id AA26833; Fri, 8 Jan 93 11:56:16 PST Received: from fenway.andr.UB.com by sunny.andr.UB.com (4.1/SMI-4.1) id AA08642; Fri, 8 Jan 93 14:56:25 EST Received: by fenway.andr.UB.com (4.1/SMI-4.1) id AA20527; Fri, 8 Jan 93 14:55:09 EST Date: Fri, 8 Jan 93 14:55:09 EST From: Frank T Solensky Message-Id: <9301081955.AA20527@fenway.andr.UB.com> To: ULLMANN@PROCESS.COM, fbaker@acc.com Subject: RE: New growth charts Cc: big-internet@munnari.oz.au FB: Fred Baker RU: Robert Ullmann, quoted with permission -------------- RU>I have a question and an observation. RU> RU>Question: what sort of maths do you use to predict where the RU>(e.g.) inflection point is on the line? I don't see in the data RU>anything that would validly predict the inflection point except RU>to say "not yet" and "probably not soon." The curve is fitted using non-linear regression techniques. It's an iterative process: you start off with initial guestimates of the parameters, fit the curve, look at the errors and how they change when a slight delta is added to each parameter and come up with an estimate for how each parameter needs to be changed, then start the process over again until the deltas are sufficiently small. This takes about 10 to 20 iterations to get the deltas down to about 1 ppM). The model that was the best fit for the previous month is used as the starting point for fitting the curve the following month. FB>Both projections seem to indicate slightly accellerating growth over FB>the next (roughly) two years, and then growth at the rate acheived for FB>(roughly) two more. The question, the difference between the FB>projections, is: what is the peak growth *rate*? FB> FB>It seems to me that what we can deduce at the moment is that the real FB>peak network count probably lies somewhere between the estimates of FB>your first and last charts, which is to say FB> 70K < reality < 185K RU>Observation: [a large] percent of our customer base is not on the RU>"connected IP Internet" (although more have mail, and some are RU>on the fringes); [most] do not have real network number RU>assignments. IMHO, the pent-up demand is huge, and already RU>exceeds the number of nets theoretically available. RU> RU>I suspect the data points are going to continue to exceed the RU>sucessive expectations. Oh, well... I include the second graph -- showing how the peak level changes each month -- as a cautionary statement against taking these estimates too seriously too far out into the future. At this point, even projecting the following _month's_ count has proved to be tricky, never mind the following year. Since the inflection point is (in the logistic curve, by definition) when the data hits half the peak level, the inflection point winds up getting modified each time as well. And, as you say, all one can really be sure about at this point is that we're not anywhere near the peak yet. The model is also limited to being based only on the observed network counts up to this point -- it'd be pretty hard to factor in any sort of estimates on general market potential. When I first made this sort of presentation at the Vancouver IETF, it was pointed out that one might observe how many Fortune 1000 companies were connected, but this would tend to lose sight of the fact that a hugh majority of the businesses in this country are made up of 25 people or less. In a similar vein, if one figured in the percentage of colleges and universities that were connected, one wouldn't be prepared for efforts like K-12 that have started up since that time (Interestingly enough, this is not unlike the situation around how the logistic curve itself was originally developed: Verhulst used this approach to project the US population in 1838 out to 1950. It proved to be very accurate though the end of the 19th century but didn't anticipate the levels of immigration that followed. Or, in reference Fred's story about God and Jerimiah, we're not counting the chariots yet). I tend to agree with Robert on this: these charts are still about three orders of magnitude lower than the IAB's predictions of 10**9 nets within the decade. I tend to think that their figure probably isn't too far off the mark. FB>..I wonder if there is any seasonal behavior that should be accounted for FB>in the models? .. Now that you mention it, there _does_ seem to be more growth in the (northern-hemisphere) fall months. In late '89 (early '90), this was when 440 nets from MILNET were added in one month (bringing the total up to a whopping 1317 nets); late '91 was when the policy of assigning multiple Class C addresses started. From last September, though, there hasn't been a specific cause that I can think of that would explain the jump around the trend lines so maybe there is a underlying cyclical pattern to it as well.. -- Frank From owner-Big-Internet@munnari.oz.au Sat Jan 9 07:56:35 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA16349; Sat, 9 Jan 1993 07:56:47 +1100 (from owner-Big-Internet) Return-Path: Message-Id: <9301082056.16349@munnari.oz.au> Received: from alcor.process.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16341; Sat, 9 Jan 1993 07:56:35 +1100 (from ULLMANN@PROCESS.COM) Date: Fri, 8 Jan 1993 15:55 -0500 From: ULLMANN@PROCESS.COM (Robert L Ullmann) To: big-internet@munnari.oz.au Cc: ipv7@world.std.com Subject: updated draft/status/new mail list for IPv7 proposal Hi, This is a status update on the IPv7 protocol described in draft-ullmann-ipv7-02.txt, just updated (4 January). Even if you have read previous versions, you should review this. There is also a companion document on routing not released yet. To outline what this IPv7 is about, it: * Meets all of the criteria musts, and most of the shoulds (and all of them at least as well as v4). * Provides a new IP version that interoperates with the existing one; it does NOT require a costly transition plan; it is deployed as a new version as vendors routinely do. * Uses Administrative Domains in the addressing; this is a political necessity as the Internet expands. * Allows 10^6 hosts in each net; 10^8 nets in each AD, and 10^8 ADs. (Enough? :-) The layer boundaries are done with flexible masks, of course. * Separates the forwarding-decision complexity from the routing explosion, and provides a method to make forwarding decision time near-linear with the number of datagrams. (I.e. much less than the ~N(d) * log N(r) typical in v4 routers.) * This also provides for datagrams following flows in a very general model. (E.g. allowing a flow to be bandwidth reserved for any use between two sites, not just particular machines.) * Also upgrades TCP to remove its current painful limitations. (With present CPU and LAN speeds, e.g. 200 mips/100mbps, both sequence space and window in TCPv4 are too small.) * Provides for ICMP messages to travel through both versions and be interpreted properly to the extent needed by existing implementations. * And miscellaneous other good stuff, so go read it. The discussion list is ipv7@world.std.com Remember that subscription requests go to ipv7-request@world.std.com, not to the list. Archive of the list is world.std.com:/pub/ipv7/... Best Regards, Robert From owner-Big-Internet@munnari.oz.au Tue Jan 12 07:15:05 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA09672; Tue, 12 Jan 1993 07:15:16 +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 AA09664; Tue, 12 Jan 1993 07:15:05 +1100 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <11569>; Mon, 11 Jan 1993 12:14:42 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <10780>; Mon, 11 Jan 1993 12:14:31 -0800 To: sip@caldera.usc.edu Cc: ip-encaps@sunroof.eng.sun.com, ipae-dev@sunroof.eng.sun.com, casner@isi.edu, van@ee.lbl.gov, big-internet@munnari.oz.au Subject: SIP meeting this Thursday Date: Mon, 11 Jan 1993 12:14:19 PST Sender: Steve Deering From: Steve Deering Message-Id: <93Jan11.121431pst.10780@skylark.parc.xerox.com> There will be a SIP meeting this Thursday at Xerox PARC. People unable to attend in person may participate via vat and nv over the MBONE, or by telephone conference call (from USA locations only). Here are the details: date and time of meeting: Thursday, Jan 14, 8:45 am to 12:00 noon, PST (GMT-8) physical meeting site for anyone in the SF Bay Area: Xerox PARC, 3333 Coyote Hill Road, Palo Alto Please try to arrive BEFORE 8:45 am. vat and nv sessions (advertised in sd): vat multicast address 224.6.6.4 port 4664 id 0 ttl 191 nv multicast address 224.6.6.5 port 4444 ttl 127 telephone conference call: 800-857-9855, password "SIP", please do NOT call in before 8:45 am, California Time. Many thanks to Michael Conn of MCI for providing the phone conference bridge, and to Steve Casner of ISI for providing the facilities to patch the phone conference into the vat conference. By the way, if there is anyone who is on the ip-encaps or the ipae-dev mailing list who is not also on the sip list, please join the sip list ASAP (send to sip-request@caldera.usc.edu). I will not include those lists in future announcements of this kind. Steve From owner-Big-Internet@munnari.oz.au Fri Jan 15 20:06:51 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA04911; Fri, 15 Jan 1993 20:07:02 +1100 (from owner-Big-Internet) Return-Path: Message-Id: <9301150907.4911@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04907; Fri, 15 Jan 1993 20:06:51 +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 ; Fri, 15 Jan 1993 09:06:32 +0000 To: lixia@parc.xerox.com Cc: big-internet@munnari.oz.au Subject: Re: what is expected from whom. In-Reply-To: Your message of "Thu, 14 Jan 93 13:27:16 PST." Date: Fri, 15 Jan 93 09:06:31 +0000 From: Jon Crowcroft >> As you say, larger IP addresses implies a new packet format. This >> implies changes to every existing Internet host. ... > related, how would the cost of changing all the existing hosts >today compare to the cost of doing so a few years down the road? there are 3 responses to this 1. short term - we could ask everyone to reallocate asddresses to a) make better use of existing a/b/c/d classes and b) make better CIDR 2. medium term we want to change protocol/address format to a scheme that _admits_ of easier future change so that: c) long term, we admit that change is the only constant unfortunately, i dont see how sip/pip/clnp address change when we confront the inevitable fact that they too, will one day, have had their day, jon From owner-Big-Internet@munnari.oz.au Wed Jan 27 03:26:29 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA01121; Wed, 27 Jan 1993 03:26:48 +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 AA01115; Wed, 27 Jan 1993 03:26:29 +1100 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA13063; Tue, 26 Jan 93 11:26:17 -0500 Date: Tue, 26 Jan 93 11:26:17 -0500 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9301261626.AA13063@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au Subject: Metro Addressing Cc: jnc@ginger.lcs.mit.edu I've been thinking about metro addressing for a while, and I must confess there's something I just don't get. Let me explain what it is, and perhaps someone can straighten me out, since I simply can't see where I've gone wrong. 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' (i.e. the quantity which goes in the packet and is used by the routers to indentify the source and destination). The SIP routing architecture would deal with these 'addresses' as the naming system which is uses for the data it ships around as to where things are, etc. 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? The routing at the metro level is thus forced to track all the subscribers individually. I.e. the fact that you cannot aggregate information about subscribers means that the routing system within the metro will have to have an entry for each subscriber. 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 thn 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? Routing is an inherently more expensive construct than a name translation. Routing systems typically have costs on the order of NlogN for the number of destinations. Dumping the problem of service mobility into the lap of the routing is a far more expensive option than adding a name translation. Why not do it with a name translation? As an added benefit, all the metro scheme is doing is providing portability (as we have defined it), but within a limited area. If you did it with an extra name translation, you'd buy the same capability, but over the entire network. Doesn't a solution which gives your more functionality at less expense seem more attractive? I'm simply not tracking on this metro addressing thing; perhaps someone can explain where I went wrong? Noel From owner-big-internet@munnari.oz.au Wed Jan 27 19:05:11 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA02754; Wed, 27 Jan 1993 19:05:18 +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 AA10191; Wed, 27 Jan 1993 09:29:35 +1100 (from hitchcoc@oerv01.er.doe.gov) Received: by er.doe.gov (5.57/OER-V1.0) id AA04386; Tue, 26 Jan 93 17:26:24 -0500 Date: Tue, 26 Jan 93 17:26:24 -0500 From: hitchcoc@oerv01.er.doe.gov (Dan Hitchcock) Message-Id: <9301262226.AA04386@er.doe.gov> To: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu Subject: Re: Metro Addressing The costs depend on where you're sitting. From the point of view of a network service provider this scheme is attractive because they need only to look at a subset of the bits to see whether a packet is from one of their subscribers or not which simplifies accounting. It is true that the address space below them is flat and as large as the metro area, even if they are a small provider but the trade off is probably not bad for them. From the point of the end user this also has advantages because changing addresses on hosts is unpleasant to accomplish especially for a large site! If the major applications could all be referenced by DNS name alone and addresses could be easily reconfigured then this would not be a problem but today it requires touching and rebooting every host on your site. It is also not necessarily true that the address space in the metro needs to be flat. The US numbering plan for the phone net is a counterexample to this even though it is not a good model for the future. Dan Hitchcock From owner-big-internet@munnari.oz.au Wed Jan 27 23:21:21 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA10684; Wed, 27 Jan 1993 23:21:26 +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 AB03807; Wed, 27 Jan 1993 19:40:34 +1100 (from huitema@mitsou.inria.fr) Received: by mitsou.inria.fr (5.65c/IDA-1.2.8) id AA10737; Wed, 27 Jan 1993 09:42:56 +0100 Message-Id: <199301270842.AA10737@mitsou.inria.fr> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.oz.au Subject: Re: Metro Addressing In-Reply-To: Your message of "Tue, 26 Jan 93 11:26:17 EST." <9301261626.AA13063@ginger.lcs.mit.edu> Date: Wed, 27 Jan 93 09:42:55 +0100 From: Christian Huitema >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)....Am I on >track so far? Sort of. It depends a lot of what you call "topological significance". The highest part of metro addressing has "geographical" significance, and there is a hidden assumption (well, not so hidden) that there will be some relation between geography and network topology. Also, the concept of "low order" and "high order" is mostly introduced by the IPAE transition srtategy -- while moving to SIP, we have to start from IP and incorporate the current addresses. > 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? 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. We are indeed interested in providing "customer mobility". The solution, here, is to use something very near DCC's "route segments", or PIP's "routing directives". Let's suppose that the various providers are hierarchically organized in "syndicates", and assume that within a syndicate we can perform geographical routing; this is pretty much the current situation, e.g. an academical syndicate around NSFNET and RARE, a semi commercial syndicate derived from UUCP, a "PTT" syndicate, and other to come around ANS, MCI and friends. If source and destination happen to belong to the same syndicate, then we are back to the monopoly case, and geographical addressing works. In the other cases, we have to exercise "provider selection"; packets will have to be source routed to the "destination syndicate", using loose source routing. These source routes could be obtained from an "ICMP redirect" message, similar to what would be needed to support mobile hosts. 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. At worst, this information could be obtained from the DNS: we would be back to the solution proposed in RFC-1183, or use DCC's "route segments", using an efficient LSR mechanism. I believe this would be very near from PIP's "routing directives". Christian Huitema From owner-Big-Internet@munnari.oz.au Thu Jan 28 01:33:31 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA14881; Thu, 28 Jan 1993 01:33:57 +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 AA14843; Thu, 28 Jan 1993 01:33:31 +1100 (from dcrocker@Mordor.Stanford.EDU) Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA00383; Wed, 27 Jan 93 06:33:23 -0800 Message-Id: <9301271433.AA00383@Mordor.Stanford.EDU> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.oz.au Subject: Re: Metro Addressing Org: The Branch Office, Sunnyvale CA Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Tue, 26 Jan 93 11:26:17 -0500. <9301261626.AA13063@ginger.lcs.mit.edu> Date: Wed, 27 Jan 93 06:33:23 -0800 From: Dave Crocker X-Mts: smtp Noel, I think your summary of metro addressing is accurate. I also am not completely comfortable with the potential size of the 'flat' address space, at the metro level, with all subscribers aggregated, but it is an explicit decision that was made after significant discussions. (I.e., other folks _are_ comfortable with the choice.) Dave From owner-Big-Internet@munnari.oz.au Thu Jan 28 13:36:38 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA07682; Thu, 28 Jan 1993 13:36: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 AA07668; Thu, 28 Jan 1993 13:36:38 +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, 27 Jan 93 21:36:19 EST Received: by chiya.bellcore.com (4.1/4.7) id for jnc@ginger.lcs.mit.edu; Wed, 27 Jan 93 21:36:18 EST Date: Wed, 27 Jan 93 21:36:18 EST From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Message-Id: <9301280236.AA06194@chiya.bellcore.com> To: big-internet@munnari.oz.au, hitchcoc@oerv01.er.doe.gov, jnc@ginger.lcs.mit.edu Subject: Re: Metro Addressing > From Dan Hitchcock..... > > The costs depend on where you're sitting. From the point of view of a > network service provider this scheme is attractive because they need only > to look at a subset of the bits to see whether a packet is from one > of their subscribers or not which simplifies accounting. It is true that ????? This seems wrong.....With provider-oriented addresses, a subset of the bits gives this information (and can be determined with a simple mask/compare). But with geographical, there are no bits that tell this information. One has to index a flat (at the subscriber level) table to figure it out..... > > >From the point of the end user this also has advantages because changing > addresses on hosts is unpleasant to accomplish especially for a large site! I agree that life 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....... > > If the major applications could all be referenced by DNS name alone and addresses > could be easily reconfigured then this would not be a problem but today it > requires touching and rebooting every host on your site. Why rebooting? Pip hosts certainly won't require rebooting for this...... From Christian Huitema > > Sort of. It depends a lot of what you call "topological significance". The > highest part of metro addressing has "geographical" significance, and there is > a hidden assumption (well, not so hidden) that there will be some relation > between geography and network topology. Also, the concept of "low order" and If providers cover the same geographic territory, then there is not a relationship between geography and topology...... Right now many of the "regional" (or, formally regional) backbones in the USA are international. They all cover the same geography-- the world!!! > > 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. I assume that nobody is seriously considering geographical monopolies (or, at least, is limiting their design to only be efficient in the face of geographical monopolies). > the other cases, we have to exercise "provider selection"; packets will have to > be source routed to the "destination syndicate", using loose source routing. > That's right. You can't hide the fact of customers connected to providers. Sooner or later you have to deal with them, either in addresses or with source routes or directory service or something. Given that putting provider information in addresses is best from a routing perspective, gives you nice hooks for "provider selection", and is not a big deal to reconfigure if you provide protocol support for it, I conclude that provider-based addresses are the way to go. The "Pip Near-Term Architecture" is just a few pages from completion. It talks in specific terms about how the Pip implementation deals with all this stuff..... PX From owner-big-internet@munnari.oz.au Thu Jan 28 14:45:03 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA10180; Thu, 28 Jan 1993 14:45: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 AA01712; Thu, 28 Jan 1993 10:46:37 +1100 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA29579; Wed, 27 Jan 93 18:46:18 -0500 Date: Wed, 27 Jan 93 18:46:18 -0500 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9301272346.AA29579@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au, hitchcoc@oerv01.er.doe.gov, jnc@ginger.lcs.mit.edu Subject: Re: Metro Addressing Cc: jnc@ginger.lcs.mit.edu From the point of view of a network service provider this scheme is attractive because they need only to look at a subset of the bits to see whether a packet is from one of their subscribers or not which simplifies accounting. Hold on, if I can change providers without anything in my SIP address changing, how can *anything* in the address tell *anyone* which provider I am using? Wouldn't you need a table lookup to map subsribers to providers? 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? The US numbering plan for the phone net is a counterexample to this even though it is not a good model for the future. The phone net works because the only way to get *to* a subsciber from a long haul provider (as opposed to from a subscriber to a provider) is through the RBOC. Even there, if you change your location far enough within a LATA, you *still* get a new phone number since you're on a different exchange (unless you pay extra $$$ for the foreign exchange thing). Noel From owner-big-internet@munnari.oz.au Thu Jan 28 16:12:04 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12810; Thu, 28 Jan 1993 16:12: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 AA07544; Thu, 28 Jan 1993 13:32:49 +1100 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA00475; Wed, 27 Jan 93 21:32:07 -0500 Date: Wed, 27 Jan 93 21:32:07 -0500 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9301280232.AA00475@ginger.lcs.mit.edu> To: Christian.Huitema@sophia.inria.fr, jnc@ginger.lcs.mit.edu Subject: Re: Metro Addressing Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu Also, the concept of "low order" and "high order" is mostly introduced by the IPAE transition srtategy -- while moving to SIP, we have to start from IP and incorporate the current addresses. I call that part the high-order part because it is considered first by the routing; i.e. if some address is in a different metro, you need to route it to that metro first before you local at the metro-local part of it. Thus the metro part is the high part and the subsciver identity inside the metro is the low order part. 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. The multiple providers is obscuring the issue. The routing issue is still the same if you allow people to move around inside the metro while still keeping the exact same address. 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). Plus to which, why are providers going to want to provide this service for customers who aren't paying them any money any more? At worst, this information could be obtained from the DNS: we would be back to the solution proposed in RFC-1183, or use DCC's "route segments", using an efficient LSR mechanism. I believe this would be very near from PIP's "routing directives". In other words, you are going to get a second quantity from the DNS which tells you were the subsciber *really* is (how to get the actually, in this case). So the metro address is realy just a subsciber ID, then? (Also, I think you mean DDC, yes?) Noel From owner-Big-Internet@munnari.oz.au Thu Jan 28 20:15:02 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA20728; Thu, 28 Jan 1993 20:15:16 +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 AB20699; Thu, 28 Jan 1993 20:15:02 +1100 (from huitema@mitsou.inria.fr) Received: by mitsou.inria.fr (5.65c/IDA-1.2.8) id AA12817; Thu, 28 Jan 1993 10:17:25 +0100 Message-Id: <199301280917.AA12817@mitsou.inria.fr> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.oz.au Subject: Re: Metro Addressing In-Reply-To: Your message of "Wed, 27 Jan 93 21:32:07 EST." <9301280232.AA00475@ginger.lcs.mit.edu> Date: Thu, 28 Jan 93 10:17:25 +0100 From: Christian Huitema > 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. > >The multiple providers is obscuring the issue. The routing issue is still the >same if you allow people to move around inside the metro while still keeping >the exact same address. 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. >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). >Plus to which, why are providers going to want to provide this service for >customers who aren't paying them any money any more? First, one misconception. What you call the "low end" of the metro address does not have to encode the provider name. Basically, the old idea of "staying in one's network as long as possible" should be applied here. If your provider is ATT, then use ATT down to the ATT affiliate in the metro area. If your target happens to be connected to that provider, you have succeeded; otherwise, you get an ICMP back. 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 (yes, I meant DDC). Christian Huitema From owner-Big-Internet@munnari.oz.au Fri Jan 29 02:18:51 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA01522; Fri, 29 Jan 1993 02:19: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 AA01510; Fri, 29 Jan 1993 02:18: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; Thu, 28 Jan 93 10:18:43 EST Received: by chiya.bellcore.com (4.1/4.7) id for jnc@ginger.lcs.mit.edu; Thu, 28 Jan 93 10:18:39 EST Date: Thu, 28 Jan 93 10:18:39 EST From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Message-Id: <9301281518.AA07039@chiya.bellcore.com> To: Christian.Huitema@sophia.inria.fr, jnc@ginger.lcs.mit.edu Subject: Re: Metro Addressing Cc: big-internet@munnari.oz.au > > 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. I think this whole business of keeping addresses or changing addresses is next to nonsense. It is so utterly simple to design protocols that do automatic prefix administration...... and, addresses should be hidden from *everything*, by virtue of DNS name-to-address lookup. (Well, maybe not everything. After all, a host has to know how to reach DNS..... with Pip, external addressing is separated from internal, soa host can be configured with the address of the DNS box without regard to external addressing stuff. But, I guess one can arrange to do this with traditional type addresses as well.....) > > 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 (yes, I meant DDC). > 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 think the SIP advocates need to state what SIP will and will not do, and when it will do it. This way, those vendors, for instance, who are writing "SIP is cheaper to implement than foo" can have a long term look at SIP and judge the cost of implementation better. 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). By the way, I agree that Pip also needs to make this statement, but it is coming in the form of an almost finished "Pip Near-term Architecture" document...... PX From owner-Big-Internet@munnari.oz.au Fri Jan 29 03:27:52 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03584; Fri, 29 Jan 1993 03:28:03 +1100 (from owner-Big-Internet) Return-Path: Received: from uunet by munnari.oz.au with UUCP (5.83--+1.3.1+0.50) id AA03575; Fri, 29 Jan 1993 03:27:52 +1100 (from ebersman@uunet.uu.net) Received: from cfmartin.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA19683; Thu, 28 Jan 93 11:18:06 -0500 Received: by cfmartin.UU.NET (5.61/UUNET-mail-leaf) id AA23939; Thu, 28 Jan 93 11:18:03 -0500 Date: Thu, 28 Jan 93 11:18:03 -0500 From: ebersman@uunet.uu.net (Paul Ebersman) Message-Id: <9301281618.AA23939@cfmartin.UU.NET> To: Christian Huitema Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu (Noel Chiappa) Subject: Re: Metro Addressing References: <9301280232.AA00475@ginger.lcs.mit.edu> <199301280917.AA12817@mitsou.inria.fr> Organization: UUNET Technologies, Inc. jnc> The multiple providers is obscuring the issue. The routing issue jnc> is still the same if you allow people to move around inside the jnc> metro while still keeping the exact same address. Huitema> Experience will tell, but I believe that companies will more Huitema> often swap between MCI, ATT and Sprint than move their Huitema> buildings around the city. So I believe that the first order Huitema> problem is to facilitate provider swapping. Also, one could Huitema> observe that "keeping your address when moving to another Huitema> building" is also a problem for provider addresses, so is not Huitema> a real strong argument in the provider vs geographical Huitema> debate. Actually, the various bypass carriers, such as MFS (Metropolitan Fiber) are making swapping long-haul carriers much easier. If get I get the local loops at both ends of a leased line as MFS local loops, they can complete the paperwork to swap long-haul carriers in a few days and can do the actual cutover in a matter of moments, since it is just a change of crossconnects in their pop. Always nice to keep the long-haul carriers nervous B^) -- Paul A. Ebersman @ UUNET Technologies, Inc. uunet!ebersman or ebersman@uunet.uu.net The difference between theory and practice in practice is greater than the difference between theory and practice in theory. From owner-big-internet@munnari.oz.au Fri Jan 29 06:25:21 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA08028; Fri, 29 Jan 1993 06:25:25 +1100 (from owner-big-internet) Return-Path: Message-Id: <9301281925.8028@munnari.oz.au> Received: from nic.near.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01009; Fri, 29 Jan 1993 02:01:44 +1100 (from jcurran@nic.near.net) To: Christian Huitema Cc: Noel Chiappa , big-internet@munnari.oz.au Subject: Re: Metro Addressing In-Reply-To: Your message of Thu, 28 Jan 93 10:17:25 +0100. <199301280917.AA12817@mitsou.inria.fr> Date: Thu, 28 Jan 93 10:01:31 -0500 From: John Curran -------- ] From: Christian Huitema ] Subject: Re: Metro Addressing ] Date: Thu, 28 Jan 93 10:17:25 +0100 ] ... ] 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). ] First, one misconception. What you call the "low end" of the metro address ] does not have to encode the provider name. Basically, the old idea of "staying ] in one's network as long as possible" should be applied here. If your provider ] is ATT, then use ATT down to the ATT affiliate in the metro area. If your ] target happens to be connected to that provider, you have succeeded; ] otherwise, you get an ICMP back. ] ] 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 (yes, I meant DDC). I will note that a distributed database solution (in a manner similiar to DNS) can also be used to solve the same two problems. The ICMP solution does not have any inherent advantage in terms of problem space. /John From owner-big-internet@munnari.oz.au Fri Jan 29 07:51:41 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA10586; Fri, 29 Jan 1993 07:51:45 +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 AA04113; Fri, 29 Jan 1993 03:47:31 +1100 (from swb@nr-tech.cit.cornell.edu) Received: from FALCON.CIT.CORNELL.EDU by mitchell.cit.cornell.edu (4.1/1.34/Honig-1.3) id AA29946; Thu, 28 Jan 93 11:46:48 EST Message-Id: <9301281646.AA29946@mitchell.cit.cornell.edu> To: jnc@ginger.lcs.mit.edu, tsuchiya@thumper.bellcore.com Cc: big-internet@munnari.oz.au From: Scott_Brim@cornell.edu Subject: Re: Metro Addressing In-Reply-To: Noel Chiappa's message of Tue, 26 Jan 1993 11:26:17 -0500. <9301261626.AA13063@ginger.lcs.mit.edu> Date: Thu, 28 Jan 1993 11:46:42 -0500 Sender: swb@nr-tech.cit.cornell.edu One other thing that metro-based addressing gives is the ability for the sender to place packets on the long-haul carrier of the *its* choice, at the time each packet is sent (although ultimate delivery is still on the intra-metro carrier of the receiver's choice). The reason this feels like a win over any sort of provider-based addressing + dynamic prefix management scheme is (1) the sender gets to choose its main carrier regardless of which providers the recipient might have agreements (and thus addresses) with, and (2) in any provider-based addressing scheme, traffic is still forced onto the recipient's provider as early as possible, even though the sender usually has to pay. It's a control issue, but Cornell (and probably lots of other organizations) has agreements with multiple providers for both telephony and data, so it's a persuasive one around here. Noel, if you were to support this sort of capability using name lookups you would need to use segments, where the directory service would return a (small) set of possible final loose-source segments *within the destination metro* for the sender to choose from (the directory service can't possibly return all paths, and can't presume to know the source's preferred path to the destination metro). The advantage of doing this is that the source can label its packets with the correct (loose-source) path within the destination metro and the entry points into the metro will have a much smaller route lookup burden. I don't think there is any additional disadvantage, presuming (1) you are going to do a lookup of some sort anyway, and (2) any directory service is going to be distributed. I'm assuming each metro would keep its own database which would be queried, even if indirectly. This would work well with PIP. I dunno about the others. Scott From owner-big-internet@munnari.oz.au Fri Jan 29 08:18:22 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA11431; Fri, 29 Jan 1993 08:18:28 +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 AA06509; Fri, 29 Jan 1993 05:23:28 +1100 (from atkinson@itd.nrl.navy.mil) Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA14449; Thu, 28 Jan 93 13:23:15 EST Date: Thu, 28 Jan 93 13:23:15 EST From: atkinson@itd.nrl.navy.mil (Ran Atkinson) Message-Id: <9301281823.AA14449@itd.nrl.navy.mil> To: Big-Internet@munnari.oz.au Subject: next gen IP efforts I think I'm somewhat uncomfortable with the language that some folks have been using that implies these efforts are engaged in some form of "horse race". I'm sure I'm uncomfortable with folks "advocating" any particular approach over some other approach at this early state where all are still evolving with implementation experience. Maybe folks have just been writing quickly and hence being less than normally careful in their choice of words. I hope so. It would be unfortunate if the IETF were to start to divide into "competing" "camps" of folks rather than all trying to work on the problems -- possibly exploring the technical details of different approaches to the same problems, but hopefully in a cooperative rather than competitive manner. Ran atkinson@itd.nrl.navy.mil  From owner-big-internet@munnari.oz.au Fri Jan 29 08:36:23 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12064; Fri, 29 Jan 1993 08:36:28 +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 AA05902; Fri, 29 Jan 1993 04:50:59 +1100 (from dennis@ans.net) Received: by interlock.ans.net id AA25309 (InterLock SMTP Gateway 1.1 for big-internet@munnari.oz.au); Thu, 28 Jan 1993 12:49:56 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 28 Jan 1993 12:49:56 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 28 Jan 1993 12:49:56 -0500 Date: Thu, 28 Jan 1993 12:50:00 -0500 From: Dennis Ferguson Message-Id: <199301281750.AA22508@foo.ans.net> To: Christian.Huitema@sophia.inria.fr Subject: Re: Metro Addressing Cc: big-internet@munnari.oz.au > 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. But which provider? Note that you don't get your local telephone number (address) from any of MCI, ATT and/or Sprint, you get it from the local phone company. The local phone company is your provider, the selection of MCI, ATT or Sprint is just an entry in your provider's database to tell them how to route your outgoing long distance calls. Since this is essentially routing based on source address, something which isn't done on the current IP network and I don't think is being planned, there is no real analogy of long distance phone company selection to anything which is done on an IP network. Telephone numbers are provider-based, it is just that in any geographic area you usually don't have a choice of providers. You can indeed get service directly from MCI, ATT or Sprint, but to make use of this service for incoming calls you need to get another phone number (an 800 number, which is the address space the long-haul carriers own). With the current state of the art when you change your long distance provider you will change your 800 number to one which is taken from the new provider's address space. Hence, as far as I can tell, the US telephone network currently is a prime example of provider-based addressing, and currently does nothing to facilitate provider-swapping (in most cases you have no choice for your local provider at all). If you have multiple providers you get multiple addresses. If you change your provider you change your address (I know they're working on provider independence of 800 numbers, but this hasn't happened yet and won't apply to local numbers). If you relocate and attach to a different bit of your provider's topology you will get a different address. The MCI/ATT/Sprint/whoever selection, which people keep bringing up to prove that provider-independent addressing really does exist somewhere, is largely irrelevant to the issue at hand since it actually is a routing function offered to you by your real provider (which you don't change) which has no analogy on the current IP network. > First, one misconception. What you call the "low end" of the metro address > does not have to encode the provider name. Basically, the old idea of "staying > in one's network as long as possible" should be applied here. If your provider > is ATT, then use ATT down to the ATT affiliate in the metro area. If your > target happens to be connected to that provider, you have succeeded; > otherwise, you get an ICMP back. On the telephone network the "ATT affiliate" is also the "MCI affiliate" and the "Sprint affiliate" and every other long distance carrier's affiliate. It is your local provider. All the long distance carriers do is route the call to your provider. They can tell who your provider is by looking at the high-order bits of your telephone number, since telephone addressing is provider-based. What you want to do has no analogy here. I really think you'd be a lot better off supporting provider (and topology) independence by making it easy for people to change their addresses rather than trying to make the network track their addresses where ever they move to in terms of network topology. Dennis Ferguson From owner-big-internet@munnari.oz.au Fri Jan 29 09:09:00 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA13080; Fri, 29 Jan 1993 09:09: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 AA06871; Fri, 29 Jan 1993 05:38:58 +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, 28 Jan 93 13:38:19 EST Received: by chiya.bellcore.com (4.1/4.7) id for tsuchiya@thumper.bellcore.com; Thu, 28 Jan 93 13:38:19 EST Date: Thu, 28 Jan 93 13:38:19 EST From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Message-Id: <9301281838.AA07533@chiya.bellcore.com> To: Scott_Brim@cornell.edu, jnc@ginger.lcs.mit.edu, tsuchiya@thumper.bellcore.com Subject: Re: Metro Addressing Cc: big-internet@munnari.oz.au > > One other thing that metro-based addressing gives is the ability for the > sender to place packets on the long-haul carrier of the *its* choice, at > the time each packet is sent (although ultimate delivery is still on the You can do this with provider-based as well. Pip is provider-based, *and* Pip has exit carrier selection...... I think what you meant to say is that, with provider-based addressing, the source might pick a stupid choice of destination address, especially with respect to the source carrier it wants to use. That is, say my carriers are A, B, and C, and your carries are D, E, and F. Say the best path is B-F. But, if I pick B-E for source/dest, then I've made a non-optimal choice...... But, you can also make a bad choice with geographical. Say my carriers are A and B, and yours are B and C. With provider-based, I can look at the source and dest addresses, see that we share a carrier, and choose that one. With geographical, I don't know who your carriers are (unless you carry that info in DNS, which I think below you are proposing), so I can't make a good choice of source carrier..... > > Noel, if you were to support this sort of capability using name lookups > you would need to use segments, where the directory service would return > a (small) set of possible final loose-source segments *within the > destination metro* for the sender to choose from (the directory service > can't possibly return all paths, and can't presume to know the source's > preferred path to the destination metro). The advantage of doing this > is that the source can label its packets with the correct (loose-source) > path within the destination metro and the entry points into the metro > will have a much smaller route lookup burden. I don't think there is > any additional disadvantage, presuming (1) you are going to do a lookup > of some sort anyway, and (2) any directory service is going to be > distributed. I'm assuming each metro would keep its own database which > would be queried, even if indirectly. Are you basically saying put the carrier information in the packet (this is the loose-source thing) plus the geographical? So, the "address" basicly looks like: geographical.carrier.stuff. The entry carrier looks at the address, checks to see if it can reach the carrier at the geographical location named, and sends the packet to the geographical location if it can, and finds the nearest path to the carrier if it can't....... This makes a kind of sense, but why not just let the carriers hierarchically address themselves internally according to whatever scheme makes sense for them (it may or may not be geographical), and advertise that layer of hierarchy to each other. Thus, if my carrier is connected to yours in, say, 10 places, I can know, without a lot of routing infomation, which of your destinations are best reachable through each of the 10 contact points. This makes sense, and argues for carriers internally having a layer of hierarchy (which they may want anyway for scaling in their internal network). I just wouldn't do it using geographical........... > > This would work well with PIP. I dunno about the others. > Well, that goes without saying....... :-) PX From owner-Big-Internet@munnari.oz.au Fri Jan 29 15:13:57 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA25562; Fri, 29 Jan 1993 15:14:06 +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 AA25556; Fri, 29 Jan 1993 15:13: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, 28 Jan 93 23:13:50 EST Received: by chiya.bellcore.com (4.1/4.7) id for dennis@ans.net; Thu, 28 Jan 93 23:13:50 EST Date: Thu, 28 Jan 93 23:13:50 EST From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Message-Id: <9301290413.AA08473@chiya.bellcore.com> To: Christian.Huitema@sophia.inria.fr, dennis@ans.net Subject: Re: Metro Addressing Cc: big-internet@munnari.oz.au > > On the telephone network the "ATT affiliate" is also the "MCI affiliate" > and the "Sprint affiliate" and every other long distance carrier's > affiliate. It is your local provider. All the long distance carriers do > is route the call to your provider. They can tell who your provider is by > looking at the high-order bits of your telephone number, since telephone > addressing is provider-based. What you want to do has no analogy here. Well put! > > I really think you'd be a lot better off supporting provider (and topology) > independence by making it easy for people to change their addresses rather > than trying to make the network track their addresses where ever they move > to in terms of network topology. > Here here! (or, is it hear hear!?) Anyway, I agree completely..... PX From owner-big-internet@munnari.oz.au Fri Jan 29 15:52:52 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA26872; Fri, 29 Jan 1993 15:52:55 +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 AA25775; Fri, 29 Jan 1993 15:20:41 +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, 28 Jan 93 23:19:19 EST Received: by chiya.bellcore.com (4.1/4.7) id for atkinson@itd.nrl.navy.mil; Thu, 28 Jan 93 23:19:18 EST Date: Thu, 28 Jan 93 23:19:18 EST From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Message-Id: <9301290419.AA08501@chiya.bellcore.com> To: Big-Internet@munnari.oz.au, atkinson@itd.nrl.navy.mil Subject: Re: next gen IP efforts > Maybe folks have just been writing quickly and hence being less than > normally careful in their choice of words. I hope so. It would be > unfortunate if the IETF were to start to divide into "competing" "camps" > of folks rather than all trying to work on the problems -- possibly > exploring the technical details of different approaches to the same > problems, but hopefully in a cooperative rather than competitive manner. > I would consider the process to be cooperative *and* competitive. I would say that the milestones set down by iesg are a bit too agressive, but better too agressive than not aggressive enough. Also, I think everybody tacitly agrees that the process won't finished until it is finished. That is, a premature decision won't be allowed by the community..... PX From owner-big-internet@munnari.oz.au Fri Jan 29 21:23:28 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA07082; Fri, 29 Jan 1993 21:23:33 +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 AA12447; Fri, 29 Jan 1993 08:50:36 +1100 (from swb@nr-tech.cit.cornell.edu) Received: from FALCON.CIT.CORNELL.EDU by mitchell.cit.cornell.edu (4.1/1.34/Honig-1.3) id AA07979; Thu, 28 Jan 93 16:50:17 EST Message-Id: <9301282150.AA07979@mitchell.cit.cornell.edu> To: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Cc: big-internet@munnari.oz.au From: Scott_Brim@cornell.edu Subject: Re: Metro Addressing In-Reply-To: Paul Tsuchiya's message of Thu, 28 Jan 1993 13:38:19 -0500. <9301281838.AA07533@chiya.bellcore.com> Date: Thu, 28 Jan 1993 16:50:15 -0500 Sender: swb@nr-tech.cit.cornell.edu I can't tell if we understand each other or not... >I think what you meant to say is that, with provider-based addressing, >the source might pick a stupid choice of destination address, especially >with respect to the source carrier it wants to use. That is, say my >carriers are A, B, and C, and your carries are D, E, and F. Say the >best path is B-F. But, if I pick B-E for source/dest, then I've >made a non-optimal choice...... > >But, you can also make a bad choice with geographical. Say my carriers >are A and B, and yours are B and C. With provider-based, I can look >at the source and dest addresses, see that we share a carrier, and >choose that one. With geographical, I don't know who your carriers >are (unless you carry that info in DNS, which I think below you are >proposing), so I can't make a good choice of source carrier..... I'm saying that if a user (e.g. Cornell) pays, it should have its choice of which carrier handles the majority of the path. With provider-based addressing it only has that choice if the destination is connected to the provider the sender wants to use, otherwise packets are preferentially placed on the carrier associated with the destination's prefix, and the sender loses control of its costs. btw PIP doesn't *have* to be provider-based -- does it?? I don't *think* it does. >Are you basically saying put the carrier information in the packet >(this is the loose-source thing) plus the geographical? I suppose so. I'm suggesting that if we used a DNS-like system then what would be returned would not be an entire route, but the (domain-level) path within the metro, like the last segment of a loose source route. I imagine this data would be maintained in the metro's database(s) and cached elsewhere, like DNS. >So, the "address" basicly looks like: geographical.carrier.stuff. > >The entry carrier looks at the address, checks to see if it >can reach the carrier at the geographical location named, and >sends the packet to the geographical location if it can, and >finds the nearest path to the carrier if it can't....... I had assumed you would always route first to the metro, that the final segment would be ignored until you hit the metro addressed. The idea of routing directly to the recipient's provider if the metro-based approach was broken is interesting. You're basically talking about having a provider repairing partitions within a metro by avoiding *its* entry point into the metro and using the destination's provider's entry point. Hmmm. >This makes a kind of sense, but why not just let the carriers >hierarchically address themselves internally according to >whatever scheme makes sense for them (it may or may not be >geographical), and advertise that layer of hierarchy >to each other. Thus, if my carrier is connected to yours in, say, >10 places, I can know, without a lot of routing infomation, which >of your destinations are best reachable through each of the 10 >contact points. This makes sense, and argues for carriers >internally having a layer of hierarchy (which they may want anyway >for scaling in their internal network). I just wouldn't do it >using geographical........... A nice idea, but I think it would be awkward in practice. In the provider-based case: in order for them to know the right connection point to use, you would need each provider to maintain up-to-date information about the next-lower level of hierarchy -- even the address structure -- of the other providers. If you don't and just use some nearby connection point, then you're back to the basic provider-based approach. In the geo-based case: you would need each provider to know something about the internal topology and the paths to each metro inside the other providers? >> This would work well with PIP. I dunno about the others. >> > >Well, that goes without saying....... :-) I'll try not to say it again. Scott From owner-big-internet@munnari.oz.au Fri Jan 29 21:26:38 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA07167; Fri, 29 Jan 1993 21:26:42 +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 AA12521; Fri, 29 Jan 1993 08:53:19 +1100 (from bill.simpson@um.cc.umich.edu) Received: from via.ws07.merit.edu by vela.acs.oakland.edu with SMTP id AA08569 (5.65c+/IDA-1.4.4); Thu, 28 Jan 1993 16:52:27 -0500 Date: Thu, 28 Jan 93 12:43:40 EDT From: "William Allen Simpson" Message-Id: <9045.bill.simpson@um.cc.umich.edu> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.oz.au Reply-To: bsimpson@morningstar.com Subject: Re: Metro Addressing I believe that there are many reasons for using geographic address assignment over provider address assignment. Think B-I-G Internet! 1) Assume that entire world is connected. Never-the-less, there will be connectivity bottlenecks, most likely due to limited connections between continents and across international borders. There is no serious allocation plan which anticipates future international assignment based on the location of a corporate world headquarters, for example, although that has occurred in the past. How do we reflect this topological reality? By assigning addresses based on this gross geographical space. The "highest order" of the address therefore reflects some geographical information. 2) Assume that when we are on a global 10^9 scale of networks, on average thousands or 10s of thousands of sites will change providers EACH DAY! This is already true within the U.S. for long distance carriers. The address change avalanche is not supportable by rapid DNS changes, and therefore we do *NOT* want sites to have to change address when they change providers, unless they are changing gross physical location as well. Moreover, it is more likely that a site will be amenable to changing address during the longer process of physically moving than merely electronically "moving". Where do we want any changes to show up in the tables? As much of the "high order" address should remain as constant as possible, since this will cause the least distruption globally, both for the DNS and the routing tables. 3) Assume that the highly connected mesh model prevails over "the few, the proud, the strong" long distance carrier model. The U.S. carrier model only works because it is based on top of ubiquitous regional supplier monopolies (RBOCs). Currently, we have serious bottlenecks at the few inter-provider inter-connect sites. There are some times of the day when I (a low speed user) have documented substantial packet loss at Cornell (to PSI) and NEARnet (to AlterNet). I assume that it's even worse for high speed users. It is ludicrous that my packets must travel to the East coast on the way to the West coast or vice versa, just because the particular corporate headquarters is located there or a particular continental provider is rooted there, when there are already shorter paths available. Even more so when the packets are merely travelling across town! Does anyone seriously think that in an environment with 10^9 networks that all the traffic for a single provider on a continent will be feasably routed through a single point? Or even 2 or 3 points? A geographic assignment promotes the implementation of a highly connected mesh and ubiquitous regional inter-connection. When a provider finds that the tables are too large for a particular area, all that it has to do is add a link to its fellow providers in that locale. This puts the economic pressure for change and improvement where it belongs -- on the fewer providers, rather than the many sites. 4) Assume that inverse-address lookups will become more prevalent, rather than less. Currently, in many implementations, every SMTP session causes at least one DNS lookup on the server side, with little likelihood of caching. If such verification practices are extended to FTP and Telnet, the problem will multiply. If the various routing schemes for route-fragments and source-routing become prevalent, the problem will grow exponentially. When these lookups occur, currently the local DNS has to ask a root DNS, and work its way down the chain. This causes a concentration of DNS traffic in a few locations, gradually broadening the search. How can we eliminate the inverse-address lookup bottlenecks? By geographically disbursing the initial lookup as much as possible. 5) Assume that policy routing, source routing and resource reservation are important. What's the point of policy routing when all traffic is controlled on a provider by provider basis? What need source routing when all traffic is routed to a specific point based on a provider assigned address anyway? How does resource reservation work in practice when all the requestors are trying to use the same resources at the same inter-provider location? I believe that the provider model we currently use is already out-dated, and that in the long term we will need better policy routing and resource reservation. These are clearly better served by a highly inter-connected mesh, and geographically disbursed traffic patterns. These in turn are better served by a geographic address assignment than a provider address assignment. Bill.Simpson@um.cc.umich.edu I can't believe it took me 2.5 hours to write this. From owner-big-internet@munnari.oz.au Fri Jan 29 21:49:27 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA07708; Fri, 29 Jan 1993 21:49:35 +1100 (from owner-big-internet) Return-Path: Message-Id: <9301291049.7708@munnari.oz.au> Received: from sirius.process.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16636; Fri, 29 Jan 1993 10:49:31 +1100 (from ULLMANN@PROCESS.COM) Date: Thu, 28 Jan 1993 18:48 -0500 From: ULLMANN@PROCESS.COM (Robert L Ullmann) To: big-internet@munnari.oz.au Subject: Re: Metro Addressing Hi, My problem with Metro is that instead of allowing various different structure to follow actual topology (or administrative topology), in a general way, it makes two very definite assumptions: 1) that two levels is sufficient (roughly inter-metro and intra-metro) 2) that the break must be geographical, and must be at a particular size (*Yes this is a bit simplified, but metro does say: this break is *here*, and has *this* physical meaning.) I don't think we need either of these restrictions; a more general solution would _permit_ geographical breakdowns if that is actually the topology of the net, but not require it. ----- About "service providers" (which seems to have negative connotations, although one would expect "service" to be positive :-): Be careful with the term "provider-based-addressing". provider-assignment != provider-routing, just because you have an assignment from A, doesn't mean you can't route via B. ("A" won't like it, but "B" will eagerly provide it.) There are more assumptions I see flying around, unmarked as assumptions. For example: "most sites will have one provider" Well, assume that the future Internet handles all of the data. Including voice and video. (Aside: forget all this "videoconferencing" stuff; the real $$$ is in cable TV ;-) I already have TWO providers, with physical wire into my home, as do 50 million other people in my country. Despite the telcos attempt to get me to buy video from them, it is likely I will continue to buy services from multiple providers (both bandwidth and value-added), and have more than one connection. Counting providers of voice/video/data that I subscribe to via one of those physical channels, I have 5 (or 19, depending on how you count). I have had experience running a net for a large company, and it isn't a question of one or two providers, but rather of several hundred providers, and several thousand private interconnects. (Note that there were only 4 "IP" service providers, I extrapolate to having Internet service everywhere there was phone/telex service.) The ability to use one IP network number everywhere was _precious_, even with only a few IP providers. We don't want to give this up. ---------- Suppose: First: Separate the concept of assigning authority from physical route provider. (This shouldn't be difficult, this is how the present Internet works; but it seems to be overlooked. Perhaps too obvious? :-) Note that this still allows _administrative_ assignment of network numbers by providers, (even with default routing via them), without requiring routing though the provider. We define ADs (administration domains, in the CCITTish sense): an AD is responsible for administering assignments of 100K or more nets. I.e. the size of a country or a major telco in the USA. The current NSF Internet is _one_ AD. Each AD is expected to provide backstop routing to the others. Each AD has about 10K to 100K nets (initially, eventually 10M), it may have internal structure, or may be routed "flat". Each net (belonging to one organization, and therefore being some subset of that organization) does its own thing internally. Routes are only aggregated when necessary, not always aggregated at hierarchy layers. (I.e. routers preserve as much info as useful about the "internal" structure of other nets, and we having not created the problem of "partitioned level 1 areas", we need not try to "heal" it.) I get a net assignment from NYNEX or Boston Cablevision or ALTERnet or NIC directly as I please, and my router adverts it on all. If NYNEX doesn't want to propagate the route, insisting that I use "their" number, that is their loss. The further they can figure out how to propagate it, the more traffic they get. (Up to a point; the other host/network is going to have its own ideas about what service it wants to use.) At worst we end up using backstop routing, where each router only must deal with thousands of routes, but the traffic follows the hierarchy. At best, the routers are able to "flat" route the entire internet, and each datagram follows the optimum path. In practice, the real world will be somwhere in between, and continually changing. The structure must be flexible enough to encourage the most aggressive distribution of routing information. Best Regards, Robert (see draft-ullmann-ipv7-02.txt) p.s. to reply to Ran Atkinson's point about "horse races": as the author of one of the 4 proposals being worked on now I can say for myself (and probably for the others :-) that we are trying very hard not to get into a race; we may, however, be slightly less successful in keeping others from forcing us into one. From owner-big-internet@munnari.oz.au Fri Jan 29 22:15:32 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA08285; Fri, 29 Jan 1993 22:15:42 +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 AA25417; Fri, 29 Jan 1993 15:09: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, 28 Jan 93 23:09:47 EST Received: by chiya.bellcore.com (4.1/4.7) id for tsuchiya@thumper.bellcore.com; Thu, 28 Jan 93 23:09:46 EST Date: Thu, 28 Jan 93 23:09:46 EST From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Message-Id: <9301290409.AA08424@chiya.bellcore.com> To: Scott_Brim@cornell.edu, tsuchiya@thumper.bellcore.com Subject: Re: Metro Addressing Cc: big-internet@munnari.oz.au > > I'm saying that if a user (e.g. Cornell) pays, it should have its choice > of which carrier handles the majority of the path. With provider-based > addressing it only has that choice if the destination is connected to > the provider the sender wants to use, otherwise packets are > preferentially placed on the carrier associated with the destination's > prefix, and the sender loses control of its costs. Packets are only preferentially placed on the carrier associated with the destination prefix if this is what the source requests. If the user wishes, it can choose *both* the source and destination carrier. In fact, it has no choice but to choose the destination carrier, by virtue of picking the address. But, it can also choose the source carrier. In fact, normal operation will be for the source to pick the source carrier, and then choose the destination address that best matches the source carrier. With Pip, DNS will be able to return info about the destination's carrier's name, network type, access restrictions, and TOSs. Thus the choice of destination carrier can be fairly informed. In addition, if you have what people generally call the route server and what I call the Pip Header Server listen to inter-domain routing info, a truly informed decision can be made about which destination address to choose...... > > btw PIP doesn't *have* to be provider-based -- does it?? I don't > *think* it does. No. Pip Addresses are semantically equivalent to regular hierarchical, so they can be either..... > > >Are you basically saying put the carrier information in the packet > >(this is the loose-source thing) plus the geographical? > > I suppose so. I'm suggesting that if we used a DNS-like system then > what would be returned would not be an entire route, but the > (domain-level) path within the metro, like the last segment of a loose > source route. I imagine this data would be maintained in the metro's > database(s) and cached elsewhere, like DNS. > > >So, the "address" basicly looks like: geographical.carrier.stuff. > > > >The entry carrier looks at the address, checks to see if it > >can reach the carrier at the geographical location named, and > >sends the packet to the geographical location if it can, and > >finds the nearest path to the carrier if it can't....... > > I had assumed you would always route first to the metro, that the final > segment would be ignored until you hit the metro addressed. The idea of > routing directly to the recipient's provider if the metro-based approach > was broken is interesting. You're basically talking about having a > provider repairing partitions within a metro by avoiding *its* entry > point into the metro and using the destination's provider's entry point. > Hmmm. Well, not a partition in the sense of a link that should be there but is broken. I just imagine that all backbones might not wich to connect with all others at all geographical locations..... > > >This makes a kind of sense, but why not just let the carriers > >hierarchically address themselves internally according to > >whatever scheme makes sense for them (it may or may not be > >geographical), and advertise that layer of hierarchy > >to each other. Thus, if my carrier is connected to yours in, say, > >10 places, I can know, without a lot of routing infomation, which > >of your destinations are best reachable through each of the 10 > >contact points. This makes sense, and argues for carriers > >internally having a layer of hierarchy (which they may want anyway > >for scaling in their internal network). I just wouldn't do it > >using geographical........... > > A nice idea, but I think it would be awkward in practice. In the > provider-based case: in order for them to know the right connection > point to use, you would need each provider to maintain up-to-date > information about the next-lower level of hierarchy -- even the address > structure -- of the other providers. If you don't and just use some Well, you don't need to know the address sturcture except to the extent that routing provides you with a mask. I think the info needed in either case is about the same. In the geo case, one provider implicitly knows the address reachable over a shared link. In the non-geo case, one provider listens to routing updates from the other provider to know what is reachable over the link. I think that non-geo gives more flexibility, and allows each provider to structure its addresses as makes sense for it..... PX From owner-Big-Internet@munnari.oz.au Sat Jan 30 01:15:31 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA13318; Sat, 30 Jan 1993 01:15:41 +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 AA13298; Sat, 30 Jan 1993 01:15: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; Fri, 29 Jan 93 09:15:12 EST Received: by chiya.bellcore.com (4.1/4.7) id for big-internet@munnari.oz.au; Fri, 29 Jan 93 09:15:11 EST Date: Fri, 29 Jan 93 09:15:11 EST From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Message-Id: <9301291415.AA09231@chiya.bellcore.com> To: big-internet@munnari.oz.au Subject: A simple request..... Since SIP is metro-based, I would like to see the metro assignments. I don't care how many SIP implementations I can touch and feel, if I can't touch and feel the address assignments I'm going to be uncomfortable..... If we can see the metro assignments, then we can go through the excercise of estimating how many things are in a metro area when we hit 10^9 nets, and based on best and worst case predictions about number of service providers in a metro area, we can decide how much routing info each will have to keep about the others..... And, whoever makes the metro assignments, please keep in mind that, assuming that with SIP the mechanisms are not in place to allow subscribers to easily change their address prefix (since preventing prefix changes is the major reason for metro-based assignments, right), you won't have the option of "area-code splits"....... So, you have to make your metro assignments big enough to handle *worst case anticipated growth*...... PX From owner-Big-Internet@munnari.oz.au Sat Jan 30 02:52:08 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15693; Sat, 30 Jan 1993 02:52: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 AA15683; Sat, 30 Jan 1993 02:52:08 +1100 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA25660; Fri, 29 Jan 93 10:51:42 -0500 Date: Fri, 29 Jan 93 10:51:42 -0500 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9301291551.AA25660@ginger.lcs.mit.edu> To: Christian.Huitema@sophia.inria.fr, jnc@ginger.lcs.mit.edu Subject: Re: Metro Addressing Cc: big-internet@munnari.oz.au >> 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. > The multiple providers is obscuring the issue. The routing issue is > still the same if you allow people to move around inside the metro while > still keeping the exact same address. 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. You seem to be arguing in circles. I point out a problem with the scheme picked to facilitate provider swapping, you postulate a monopoly, I point out the variant of the issue there, and you then argue against having a monopoly. Which is it? If there is no provider monopoly in a metro w(which I agree is a reasonable goal), then I think my original point (about the poor cost/benefit ratio of putting the mobility support in the routing) stands. 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. Yes, which is why I say that in all cases, if you change where you are plugged into the network, you should get a new 'address' (JNC definition of this term). What you call the "low end" of the metro address does not have to encode the provider name. Perhaps I am confused again, but I thought that if you were going to have provider mobility it *couldn't* encode the provider name (anywhere in the address, not just the in-metro part). 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. True, but it *still* has the problem that the routing inside the metro has to trace where every subscriber is..... Which is why I prefer this to DNS based solutions I don't mean that it absolutely has to be the DNS, although the concept of getting both the EID and address (JNC style) in the same DNS transaction that looks up the DNS name would obviouls be pretty efficient. Once things are up and running, I just don't see that many places that would need to do the EID-> address mapping; if you get them from the DNS together, and pass them around together, then you're set. Noel From owner-Big-Internet@munnari.oz.au Sat Jan 30 05:33:49 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA20109; Sat, 30 Jan 1993 05:34:01 +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 AA20097; Sat, 30 Jan 1993 05:33:49 +1100 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <11747>; Fri, 29 Jan 1993 10:32:53 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Fri, 29 Jan 1993 10:32:49 -0800 To: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Cc: big-internet@munnari.oz.au Subject: Re: A simple request..... In-Reply-To: Your message of "Fri, 29 Jan 93 06:15:11 PST." <9301291415.AA09231@chiya.bellcore.com> Date: Fri, 29 Jan 1993 10:32:35 PST Sender: Steve Deering From: Steve Deering Message-Id: <93Jan29.103249pst.12171@skylark.parc.xerox.com> Sorry for not responding yet to the thread on metro-based addressing; like Bill Simpson, it takes me several hours to write a Noelgram-size message, and I haven't yet found time to do it. But I'd better respond right away to Paul's Pernicious and Pugnacious Posting. > Since SIP is metro-based, I would like to see the metro assignments. First, SIP is *not* metro-based. SIP is designed to support hierachical addressing and routing, of which metro-based is *one* example. In the SIP spec, in the IPAE/SIP Criteria Analysis document, and in my presentation at IETF, I talked about *both* a provider-based hierarchy and a metro-based hierarchy. (In the SIP spec, the discussion consists of only a single sentence, with details promised in the "SIP Addressing and Routing document", which I am sorry not to have finished yet.) It is clear to me that we have to support a provider-based hierarchy because the infrastructure for metro-based routing (i.e., interconnection of all providers within each metro) is not yet in place and may take several years to put in place, and because we want to support source routing via identified providers for policy reasons. Both kinds of hierarchy can co-exist within the same internet, and metro-based addresses can be phased in, metro-by-metro, as the infrastructure is established. Second, take a look in directory parcftp.xerox.com:pub/sip for some tentative metro assignments. (The files were placed there in mid-December and announced to the sip list.) The file sip-addr-plan is a proposed top-level partitioning of the SIP address space into metro-based, provider- based, multicast, and reserved addresses. sip-countries contains assignments of country prefixes. sip-metros-us and sip-metros-canada contain possible assignments of metro codes for the US and Canada, based on each country's metropolitan census areas; those latter two files are incomplete, in that more codes need to be added to cover large, less-densely-populated geographic areas (like Alaska). > If we can see the metro assignments, then we can > go through the excercise of estimating how many > things are in a metro area when we hit 10^9 nets, > and based on best and worst case predictions about > number of service providers in a metro area, we > can decide how much routing info each will have > to keep about the others..... See section 2.4 of the IPAE/SIP Criteria Analysis document (can be found in the same directory) for an initial attempt at such an exercise. The SIP metro-based plan anticipates up to hundreds of millions of subscriber sites within a metro. Site IDs are flat within a metro area, but that does *not* mean that every router in the metro area needs to maintain routes to all the sites in the metro, or that each of the site IDs appears in conventional routing updates exchanged among all of the routers. An explanation of the alternatives will have to wait for a longer message (or the long-awaited SIP Addressing and Routing doc). > And, whoever makes the metro assignments, please > keep in mind that, assuming that with SIP the > mechanisms are not in place to allow subscribers > to easily change their address prefix (since > preventing prefix changes is the major reason for > metro-based assignments, right), you won't have > the option of "area-code splits"....... So, you > have to make your metro assignments big enough > to handle *worst case anticipated growth*...... First, we *are* working on mechanisms for automatic prefix reconfiguration for SIP hosts, because, as I said, we don't expect to be able to do metro- based addressing from day one, and even with metro-based addressing, there are times when hosts' addresses have to change, such as moving to a new metro area. However, the auto-reconfiguration mechanism may be less "seamless" than would be desired for the common case of non-moving site switching from one provider to another (e.g., the mechanism may not preserve on-going connections or sessions, or may not intantaneously update all the cached copies of relevant DNS records), in which case metro-based addresses may still be desirable. (Also, see Bill Simpson's and Scott Brim's messages for other reasons metro-addresses might be preferred, even if auto-renumbering is available.) Second, I believe it was you, Paul, who first pointed out to me that metro- based internet addresses would *not* have to undergo "area-code splits". If a metro address space fills up, you just assigning a second metro code to the same metro, and start allocating from the second space. Unlike telephone users, computers don't care if the addresses of neighboring sites have the same prefix as themselves. (Anyway, SIP assigns 4 billion site IDs to each metro area, so exhaustion of a metro's address space seems rather unlikely.) Bottom line: SIP does not depend on metro-based addressing. (Nor does metro-based addressing depend on SIP -- it was originally proposed for NSAP addresses.) SIP will support provider-based addresses. With either form of hierarchy, SIP should scale to support at least 10^12 sites and 10^16 hosts. SIP is expected to support some form of automatic adaptation to address changes, using similar mechanisms as those used to support mobile hosts, but not all of the details have been decided yet. Steve From owner-Big-Internet@munnari.oz.au Sat Jan 30 08:25:51 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA24839; Sat, 30 Jan 1993 08:26: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 AA24836; Sat, 30 Jan 1993 08:25:51 +1100 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <11762>; Fri, 29 Jan 1993 13:25:25 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Fri, 29 Jan 1993 13:25:13 -0800 To: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Cc: big-internet@munnari.oz.au, deering@parc.xerox.com Subject: Re: A simple request..... In-Reply-To: Your message of "Fri, 29 Jan 93 12:33:40 PST." <9301292033.AA09951@chiya.bellcore.com> Date: Fri, 29 Jan 1993 13:25:03 PST Sender: Steve Deering From: Steve Deering Message-Id: <93Jan29.132513pst.12171@skylark.parc.xerox.com> > > (Anyway, SIP assigns 4 billion site IDs to each metro area, so > > exhaustion of a metro's address space seems rather unlikely.) > > Famous last words perhaps...... I wish I had a collection of printed > statements of the sort "this address will always be big enough for blah"... That's why I wrote "seems rather unlikely", instead of "will always be big enough". > > Bottom line: SIP does not depend on metro-based addressing. (Nor does > > metro-based addressing depend on SIP -- it was originally proposed for > > NSAP addresses.) .... > > The "metro" in NSAP was always just another way of getting an NSAP, and > wasn't meant (at least not in print) to be a geographical-based address. No, I was referring to my proposal for geographical NSAP addresses, presented at the final ROAD meeting and at one of the NOOP meetings at the San Diego IETF. (I called them City Codes, at that time.) Steve From owner-big-internet@munnari.oz.au Sat Jan 30 08:30:44 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA25024; Sat, 30 Jan 1993 08:30: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 AA23417; Sat, 30 Jan 1993 07:33:55 +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, 29 Jan 93 15:33:41 EST Received: by chiya.bellcore.com (4.1/4.7) id for tsuchiya@thumper.bellcore.com; Fri, 29 Jan 93 15:33:40 EST Date: Fri, 29 Jan 93 15:33:40 EST From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Message-Id: <9301292033.AA09951@chiya.bellcore.com> To: deering@parc.xerox.com, tsuchiya@thumper.bellcore.com Subject: Re: A simple request..... Cc: big-internet@munnari.oz.au > > Sorry for not responding yet to the thread on metro-based addressing; like > Bill Simpson, it takes me several hours to write a Noelgram-size message, > and I haven't yet found time to do it. But I'd better respond right away > to Paul's Pernicious and Pugnacious Posting. Please. I prefer to ponder prevalent and pertinant problems..... > > > Since SIP is metro-based, I would like to see the metro assignments. > > First, SIP is *not* metro-based. SIP is designed to support hierachical > addressing and routing, of which metro-based is *one* example...... > > Second, take a look in directory parcftp.xerox.com:pub/sip for some > tentative metro assignments. (The files were placed there in mid-December > and announced to the sip list.) The file sip-addr-plan is a proposed....... > > See section 2.4 of the IPAE/SIP Criteria Analysis document (can be found in > the same directory) for an initial attempt at such an exercise. The SIP > metro-based plan anticipates up to hundreds of millions of subscriber sites > within a metro. Site IDs are flat within a metro area, but that does *not*..... > > First, we *are* working on mechanisms for automatic prefix reconfiguration > for SIP hosts, because, as I said, we don't expect to be able to do metro- > based addressing from day one, and even with metro-based addressing, there > are times when hosts' addresses have to change, such as moving to a new metro...... > Alright. Sorry I'm not up on all the latest SIP stuff...... It's hard to keep up. I'm glad to see that some of this is being thought about......I'm looking forward to the routing and addressing doc...... Steve, perhaps a gentleman's bet on which of us can get our respective routing and addressing docs out first??? > Second, I believe it was you, Paul, who first pointed out to me that metro- > based internet addresses would *not* have to undergo "area-code splits". > If a metro address space fills up, you just assigning a second metro code > to the same metro, and start allocating from the second space. Unlike Yes, you got me there. It was me, and I completely forgot about that feature........Seems I've read too many Noel-grams, and some useful information was pushed out of my short term brain cache..... > telephone users, computers don't care if the addresses of neighboring > sites have the same prefix as themselves. (Anyway, SIP assigns 4 billion > site IDs to each metro area, so exhaustion of a metro's address space seems > rather unlikely.) Famous last words perhaps...... I wish I had a collection of printed statements of the sort "this address will always be big enough for blah"...... > > Bottom line: SIP does not depend on metro-based addressing. (Nor does > metro-based addressing depend on SIP -- it was originally proposed for > NSAP addresses.) SIP will support provider-based addresses. With either The "metro" in NSAP was always just another way of getting an NSAP, and wasn't meant (at least not in print) to be a geographical-based address. (Ie, there was nothing that said if you have a USA E.164 number in your NSAP, then the host with the NSAP must be in the USA....) In fact, this is one of the reason why the use of such NSAPs to route to a PDN and discover the PDN address of the exit point is broken.... PX From owner-Big-Internet@munnari.oz.au Sun Jan 31 02:56:59 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA23283; Sun, 31 Jan 1993 02:57:07 +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 AA23277; Sun, 31 Jan 1993 02:56:59 +1100 (from bill.simpson@um.cc.umich.edu) Received: from via.ws07.merit.edu by vela.acs.oakland.edu with SMTP id AA16279 (5.65c+/IDA-1.4.4); Sat, 30 Jan 1993 10:56:45 -0500 Date: Sat, 30 Jan 93 10:43:59 EDT From: "William Allen Simpson" Message-Id: <9062.bill.simpson@um.cc.umich.edu> To: Steve Deering Cc: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Cc: big-internet@munnari.oz.au Reply-To: bsimpson@morningstar.com Subject: Re: A simple request..... To follow up on Steve's message, the geographical address distribution is being planned around the Census Bureau's "Standard Metropolitan Statistical Areas". One of the nice things about using official census designations for a base is that we also get accurate numbers about the things that are within the area: businesses, population, expected growth rates. 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. Also, the SMSAs are changed every decade. We won't want to change. So this is just a method to get the planning off the ground, not a permanent criterion. Bill.Simpson@um.cc.umich.edu From owner-Big-Internet@munnari.oz.au Sun Jan 31 05:39:19 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA26735; Sun, 31 Jan 1993 05:39:27 +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 AA26730; Sun, 31 Jan 1993 05:39:19 +1100 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA06301; Sat, 30 Jan 93 13:39:10 -0500 Date: Sat, 30 Jan 93 13:39:10 -0500 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9301301839.AA06301@ginger.lcs.mit.edu> To: deering@parc.xerox.com, tsuchiya@thumper.bellcore.com Subject: Re: A simple request..... Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu it takes me several hours to write a Noelgram-size message, and I haven't yet found time to do it Hey, it takes *Noel* several hours to create your average Noelgram! Noel From owner-Big-Internet@munnari.oz.au Sun Jan 31 07:13:52 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA29019; Sun, 31 Jan 1993 07:14:02 +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 AA29014; Sun, 31 Jan 1993 07:13:52 +1100 (from bill.simpson@um.cc.umich.edu) Received: from via.ws07.merit.edu by vela.acs.oakland.edu with SMTP id AA07796 (5.65c+/IDA-1.4.4); Sat, 30 Jan 1993 15:12:24 -0500 Date: Sat, 30 Jan 93 14:56:08 EDT From: "William Allen Simpson" Message-Id: <9068.bill.simpson@um.cc.umich.edu> To: big-internet@munnari.oz.au Reply-To: bsimpson@morningstar.com Subject: MSA list Here's the metro data, as extracted by my political and demographic expert, Lawrence Kestenbaum, together with extracts of his notes. He actually sent me 1.2 Meg of data in 5 tables, so I'm just passing along the highlights to the list. ---- Notes on metro areas. There are, as I mentioned, three types of census metro areas. a. The normal type (MSA) is just a metro area, like, say, Grand Rapids MI. There are 265 of those. b. The second type (PMSA) is just like the first type, except that it happens to belong to a consolidated area. Ann Arbor is one of these, and so is Detroit. There are 55 of these. c. The third type is the consolidated area, which consists of a grouping of PMSA's. There are 17 of these; one example is the "Detroit-Ann Arbor" consolidated area. Obviously in most cases the first-mentioned city in a consolidated area dominates the region, and its own PMSA has by far the largest population of the PMSA's in its consolidated area. However there is an exception to this! Note that within the S.F. Bay Area consolidated area, the Oakland PMSA is larger than the San Francisco PMSA. Bear in mind that even if a metro area is listed very simply, like "Atlanta, GA", that it's the metro area we're talking about, not merely the named city. A new development is for "county" metro areas, like Lake County IL, Orange County NY, Beaver County PA. In most cases these are suburban type areas with no strong center, and yet far enough away from other urban centers not to be part of their MSA's. Every metro area has a four-digit code, assigned alphabetically, I think under FIPS (Federal Information Processing Standard). Consolidated area codes always end in 2. The codes appear in all the tables. ---- 0040 119655 Abilene, TX 0120 112561 Albany, GA 0160 874304 Albany-Schenectady-Troy, NY 0200 480577 Albuquerque, NM 0220 131556 Alexandria, LA 0240 686688 Allentown-Bethlehem, PA-NJ 0280 130542 Altoona, PA 0320 187547 Amarillo, TX 0380 226338 Anchorage, AK 0400 130669 Anderson, IN 0405 145196 Anderson, SC 0450 116034 Anniston, AL 0460 315121 Appleton-Oshkosh-Neenah, WI 0480 174821 Asheville, NC 0500 156267 Athens, GA 0520 2833511 Atlanta, GA 0560 319416 Atlantic City, NJ 0600 396809 Augusta, GA-SC 0640 781572 Austin, TX 0680 543477 Bakersfield, CA 0720 2382172 Baltimore, MD 0733 146601 Bangor, ME 0760 528264 Baton Rouge, LA 0780 135982 Battle Creek, MI 0840 361226 Beaumont-Port Arthur, TX 0860 127780 Bellingham, WA 0870 161378 Benton Harbor, MI 0880 113419 Billings, MT 0920 197125 Biloxi-Gulfport, MS 0960 264497 Binghamton, NY 1000 907810 Birmingham, AL 1010 83831 Bismarck, ND 1020 108978 Bloomington, IN 1040 129180 Bloomington-Normal, IL 1080 205775 Boise City, ID 1123 3783817 Boston-Lawrence-Salem, MA-NH 1140 211707 Bradenton, FL 1150 189731 Bremerton, WA 1240 260120 Brownsville-Harlingen, TX 1260 121862 Bryan-College Station, TX 1282 1189288 Buffalo-Niagara Falls, NY (CONSOLIDATED AREA) 1280 968532 Buffalo, NY (COMPONENT OF CONSOLIDATED AREA) 5700 220756 Niagara Falls, NY (COMPONENT OF CONSOLIDATED AREA) 1300 108213 Burlington, NC 1303 137079 Burlington, VT 1320 394106 Canton, OH 1350 61226 Casper, WY 1360 168767 Cedar Rapids, IA 1400 173025 Champaign-Urbana-Rantoul, IL 1440 506875 Charleston, SC 1480 250454 Charleston, WV 1520 1162093 Charlotte-Gastonia-Rock Hill, NC-SC 1540 131107 Charlottesville, VA 1560 433210 Chattanooga, TN-GA 1580 73142 Cheyenne, WY 1602 8065633 Chicago-Gary-Lake County, IL-IN-WI (CONSOLIDATED AREA) 0620 356884 Aurora-Elgin, IL (COMPONENT OF CONSOLIDATED AREA) 1600 6069974 Chicago, IL (COMPONENT OF CONSOLIDATED AREA) 2960 604526 Gary-Hammond, IN (COMPONENT OF CONSOLIDATED AREA) 3690 389650 Joliet, IL (COMPONENT OF CONSOLIDATED AREA) 3800 128181 Kenosha, WI (COMPONENT OF CONSOLIDATED AREA) 3965 516418 Lake County, IL (COMPONENT OF CONSOLIDATED AREA) 1620 182120 Chico, CA 1642 1744124 Cincinnati-Hamilton, OH-KY-IN (CONSOLIDATED AREA) 1640 1452645 Cincinnati, OH-KY-IN (COMPONENT OF CONSOLIDATED AREA) 3200 291479 Hamilton-Middletown, OH (COMPONENT OF CONSOLIDATED AREA) 1660 169439 Clarksville-Hopkinsville, TN-KY 1692 2759823 Cleveland-Akron-Lorain, OH (CONSOLIDATED AREA) 0080 657575 Akron, OH (COMPONENT OF CONSOLIDATED AREA) 1680 1831122 Cleveland, OH (COMPONENT OF CONSOLIDATED AREA) 4440 271126 Lorain-Elyria, OH (COMPONENT OF CONSOLIDATED AREA) 1720 397014 Colorado Springs, CO 1740 112379 Columbia, MO 1760 453331 Columbia, SC 1800 243072 Columbus, GA-AL 1840 1377419 Columbus, OH 1880 349894 Corpus Christi, TX 1900 101643 Cumberland, MD-WV 1922 3885415 Dallas-Fort Worth, TX (CONSOLIDATED AREA) 1920 2553362 Dallas, TX (COMPONENT OF CONSOLIDATED AREA) 2800 1332053 Fort Worth-Arlington, TX (COMPONENT OF CONSOLIDATED AREA) 1950 108711 Danville, VA 1960 350861 Davenport-Rock Island-Moline, IA-IL 2000 921270 Dayton-Springfield, OH 2020 370712 Daytona Beach, FL 2030 131556 Decatur, AL 2040 117206 Decatur, IL 2082 1848319 Denver-Boulder, CO (CONSOLIDATED AREA) 1125 225339 Boulder-Longmont, CO (COMPONENT OF CONSOLIDATED AREA) 2080 1622980 Denver, CO (COMPONENT OF CONSOLIDATED AREA) 2120 392928 Des Moines, IA 2162 4665236 Detroit-Ann Arbor, MI (CONSOLIDATED AREA) 0440 282937 Ann Arbor, MI (COMPONENT OF CONSOLIDATED AREA) 2160 4382299 Detroit, MI (COMPONENT OF CONSOLIDATED AREA) 2180 130964 Dothan, AL 2200 86403 Dubuque, IA 2240 239971 Duluth, MN-WI 2290 137543 Eau Claire, WI 2320 591610 El Paso, CA 2330 156198 Elkhart-Goshen, IN 2335 95195 Elmira, NY 2340 56735 Enid, OK 2360 275572 Erie, PA 2400 282912 Eugene-Springfield, OR 2440 278990 Evansville, IN-KY 2520 153296 Fargo-Moorhead, ND-MN 2560 274566 Fayetteville, NC 2580 113409 Fayetteville-Springdale, AR 2640 430459 Flint, MI 2650 131327 Florence, AL 2655 114344 Florence, SC 2670 186136 Fort Collins-Loveland, CO 2700 335113 Fort Myers-Cape Coral, FL 2710 251071 Fort Pierce, FL 2720 175911 Fort Smith, AR-OK 2750 143776 Fort Walton Beach, FL 2760 363811 Fort Wayne, IN 2840 667490 Fresno, CA 2880 99840 Gadsden, AL 2900 204111 Gainesville, FL 2975 110539 Glens Falls, NY 2985 70683 Grand Forks, ND 3000 688399 Grand Rapids, MI 3040 77691 Great Falls, MT 3060 131821 Greeley, CO 3080 194594 Green Bay, WI 3120 942091 Greensboro-Winston-Salem-High Point, NC 3160 640861 Greenville-Spartanburg, SC 3180 121393 Hagerstown, MD 3240 587986 Harrisburg-Lebanon-Carlisle, PA 3283 1123678 Hartford-New Britain-Middletown, CT 3290 221700 Hickory, NC 3320 836231 Honolulu, HI 3350 182842 Houma-Thibodaux, LA 3362 3711043 Houston-Galveston-Brazoria, TX (CONSOLIDATED AREA) 1145 191707 Brazoria, TX (COMPONENT OF CONSOLIDATED AREA) 2920 217399 Galveston-Texas City, TX (COMPONENT OF CONSOLIDATED AREA) 3360 3301937 Houston, TX (COMPONENT OF CONSOLIDATED AREA) 3400 312529 Huntington-Ashland, WV-KY-OH 3440 238912 Huntsville, AL 3480 1249822 Indianapolis, IN 3500 96119 Iowa City, IA 3520 149756 Jackson, MI 3560 395396 Jackson, MS 3580 77982 Jackson, TN 3600 906727 Jacksonville, FL 3605 149838 Jacksonville, NC 3610 141895 Jamestown, NY 3620 139510 Janesville-Beloit, WI 3660 436047 Johnson City-Kingsport-Bristol, TN-VA 3680 241247 Johnstown, PA 3710 134910 Joplin, MO 3720 223411 Kalamazoo, MI 3740 96255 Kankakee, IL 3760 1566280 Kansas City, MO-KS 3810 255301 Killeen-Temple, TX 3840 604816 Knoxville, TN 3850 96946 Kokomo, IN 3870 97904 LaCrosse, WI 3880 208740 Lafayette, LA 3920 130598 Lafeyette-West Lafayette, IN 3960 168134 Lake Charles, LA 3980 405382 Lakeland-Winter Haven, FL 4000 422822 Lancaster, PA 4040 432672 Lansing-East Lansing, MI 4080 133239 Laredo, TX 4100 135510 Las Cruces, NM 4120 741459 Las Vegas, NV 4150 81798 Lawrence, KS 4200 111486 Lawton, OK 4243 102259 Lewiston-Auburn, ME 4280 348428 Lexington-Fayette, KY 4320 154340 Lima, OH 4360 213641 Lincoln, NE 4400 513117 Little Rock-North Little Rock, AR 4420 162431 Longview-Marshall, TX 4472 14531529 Los Angeles-Anaheim-Riverside, CA (CONSOLIDATED AREA) 0360 2410556 Anaheim-Santa Ana, CA (COMPONENT OF CONSOLIDATED AREA) 4480 8863164 Los Angeles-Long Beach, CA (COMPONENT OF CONSOLIDATED AREA) 6000 669016 Oxnard-Ventura, CA (COMPONENT OF CONSOLIDATED AREA) 6780 2588793 Riverside-San Bernardino, CA (COMPONENT OF CONSOLIDATED AREA) 4520 952662 Louisville, KY-IN 4600 222636 Lubbock, TX 4640 142199 Lynchburg, VA 4680 281103 Macon-Warner Robins, GA 4720 367085 Madison, WI 4763 336073 Manchester, NH 4800 126137 Mansfield, OH 4880 383545 McAllen-Edinburg-Mission, TX 4890 146389 Medford, OR 4900 398978 Melbourne-Titusville-Palm Bay, FL 4920 981747 Memphis, TN-AR-MS 4940 178403 Merced, CA 4992 3192582 Miami-Fort Lauderdale, FL (CONSOLIDATED AREA) 2680 1255488 Fort Lauderdale-Hollywood-Pompano Beach, FL (COMPONENT OF CONSOLIDATED AREA) 5000 1937094 Miami-Hialeah, FL (COMPONENT OF CONSOLIDATED AREA) 5040 106611 Midland, TX 5082 1607183 Milwaukee-Racine, WI (CONSOLIDATED AREA) 5080 1432149 Milwaukee, WI (COMPONENT OF CONSOLIDATED AREA) 6600 175034 Racine, WI (COMPONENT OF CONSOLIDATED AREA) 5120 2464124 Minneapolis-St. Paul, MN-WI 5160 476923 Mobile, AL 5170 370522 Modesto, CA 5200 142191 Monroe, LA 5240 292517 Montgomery, AL 5280 119659 Muncie, IN 5320 158983 Muskegon, MI 5345 152099 Naples, FL 5360 985026 Nashville, TN 5403 506325 New Beford, MA 5483 804219 New Haven-Waterbury-Meriden, CT 5523 254957 New London-Norwich, CT-RI 5560 1238816 New Orleans, LA 5602 17953372 New York-Northern New Jersey-Long Island, NY-NJ-CT (CONSOLIDATED AREA) 0875 1278440 Bergen-Passaic, NJ (COMPONENT OF CONSOLIDATED AREA) 1163 827645 Bridgeport-Stamford-Norwalk-Danbury, CT (COMPONENT OF CONSOLIDATED AREA) 3640 553099 Jersey City, NJ (COMPONENT OF CONSOLIDATED AREA) 5015 1019835 Middlesex-Somerset-Hunterdon, NJ (COMPONENT OF CONSOLIDATED AREA) 5190 986327 Monmouth-Ocean, NJ (COMPONENT OF CONSOLIDATED AREA) 5380 2609212 Nassau-Suffolk, NY (COMPONENT OF CONSOLIDATED AREA) 5600 8546846 New York, NY (COMPONENT OF CONSOLIDATED AREA) 5640 1824321 Newark, NJ (COMPONENT OF CONSOLIDATED AREA) 5950 307647 Orange County, NY (COMPONENT OF CONSOLIDATED AREA) 5720 1396107 Norfolk-Virginia Beach-Newport News, VA 5790 194833 Ocala, FL 5800 118934 Odessa, TX 5880 958839 Oklahoma City, OK 5910 161238 Olympia, WA 5920 618262 Omaha, NE 5960 1072748 Orlando, FL 5990 87189 Owensboro, KY 6015 126994 Panama City, FL 6020 149169 Parkersburg-Marietta, WV-OH 6025 115243 Pascagoula, MS 6080 344406 Pensacola, FL 6120 339172 Peoria, IL 6162 5899345 Philadelphia-Wilmington-Trenton, PA-NJ-DE-MD (CONSOLIDATED AREA) 6160 4856881 Philadelphia, PA-NJ (COMPONENT OF CONSOLIDATED AREA) 8480 325824 Trenton, NJ (COMPONENT OF CONSOLIDATED AREA) 8760 138053 Vineland-Millville-Bridgeton, NJ (COMPONENT OF CONSOLIDATED AREA) 9160 578587 Wilmington, DE-NJ-MD (COMPONENT OF CONSOLIDATED AREA) 6200 2122101 Phoenix, AZ 6240 85487 Pine Bluff, AR 6282 2242798 Pittsburg-Beaver Valley, PA (CONSOLIDATED AREA) 0845 186093 Beaver County, PA (COMPONENT OF CONSOLIDATED AREA) 6280 2056705 Pittsburgh, PA (COMPONENT OF CONSOLIDATED AREA) 6323 139352 Pittsfield, MA 6403 243135 Portland, ME 6442 1477895 Portland-Vancouver, OR-WA (CONSOLIDATED AREA) 6440 1239842 Portland, OR (COMPONENT OF CONSOLIDATED AREA) 8725 238053 Vancouver, WA (COMPONENT OF CONSOLIDATED AREA) 6453 350078 Portsmouth-Dover-Rochester, NH-ME 6460 259462 Poughkeepsie, NY 6483 916270 Providence-Pawtucket-Fall River, RI-MA 6520 263590 Provo-Orem, UT 6560 123051 Pueblo, CO 6640 735480 Raleigh-Durham, NC 6660 81343 Rapid City, SD 6680 336523 Reading, PA 6690 147036 Redding, CA 6720 254667 Reno, NV 6740 150033 Richland-Kennewick-Pasco, WA 6760 865640 Richmond-Petersburg, VA 6800 224477 Roanoke, VA 6820 106470 Rochester, MN 6840 1002410 Rochester, NY 6880 283719 Rockford, IL 6920 1481102 Sacramento, CA 6960 399320 Saginaw-Bay City-Midland, MI 6980 190921 St. Cloud, MN 7000 83083 St. Joseph, MO 7040 2444099 St. Louis, MO-IL 7080 278024 Salem, OR 7120 355660 Salinas-Seaside-Monterey, CA 7160 1072227 Salt Lake City-Ogden, UT 7200 98458 San Angelo, TX 7240 1302099 San Antonio, TX 7320 2498016 San Diego, CA 7362 6253311 San Francisco-Oakland-San Jose, CA (CONSOLIDATED AREA) 5775 2082914 Oakland, CA (COMPONENT OF CONSOLIDATED AREA) 7360 1603678 San Francisco, CA (COMPONENT OF CONSOLIDATED AREA) 7400 1497577 San Jose, CA (COMPONENT OF CONSOLIDATED AREA) 7485 229734 Santa Cruz, CA (COMPONENT OF CONSOLIDATED AREA) 7500 388222 Santa Rosa-Petaluma, CA (COMPONENT OF CONSOLIDATED AREA) 8720 451186 Vallejo-Fairfield-Napa, CA (COMPONENT OF CONSOLIDATED AREA) 7480 369608 Santa Barbara-Santa Maria-Lompoc, CA 7490 117043 Santa Fe, NM 7510 277776 Sarasota, FL 7520 242622 Savannah, GA 7560 734175 Scanton-Wilkes Barre, PA 7602 2559164 Seattle-Tacoma, WA (CONSOLIDATED AREA) 7600 1972961 Seattle, WA (COMPONENT OF CONSOLIDATED AREA) 8200 586203 Tacoma, WA (COMPONENT OF CONSOLIDATED AREA) 7610 1210036 Sharon, PA 7620 103877 Sheboygan, WI 7640 95021 Sherman-Denison, TX 7680 334341 Shreveport, LA 7720 115018 Sioux City, IA-NE 7760 123809 Sioux Falls, SD 7800 247052 South Bend-Mishawaka, IN 7840 361364 Spokane, WA 7880 189550 Springfield, IL 7920 240593 Springfield, MO 8003 602878 Springfield, MA 8050 123786 State College, PA 8080 142523 Steubenville-Weirton, OH-WV 8120 480628 Stockton, CA 8160 659864 Syracuse, NY 8240 233598 Tallahassee, FL 8280 2067959 Tampa-St. Petersburg-Clearwater, FL 8320 130812 Terre Haute, IN 8360 120132 Texarkana, TX-AR 8400 614128 Toledo, OH 8440 160976 Topeka, KS 8520 666880 Tucson, AZ 8560 708654 Tulsa, OK 8600 150522 Tuscaloosa, AL 8640 151309 Tyler, TX 8680 316633 Utica-Rome, NY 8750 74361 Victoria, TX 8780 311921 Visalia-Tulare-Porterville, CA 8800 189123 Waco, TX 8840 3923574 Washington, DC-MD-VA 8920 146611 Waterloo-Cedar Falls, IA 8940 115400 Wausau, WI 8960 863518 West Palm Beach-Boca Raton-Delray, FL 9000 159301 Wheeling, WV 9040 485270 Wichita, KS 9080 123378 Wichita Falls, TX 9140 118710 Williamsport, PA 9200 120284 Wilmington, NC 9243 709705 Worcester-Fitchburg-Leominster, MA 9260 188823 Yakima, WA 9280 417848 York, PA 9320 492619 Youngstown-Warren, OH 9340 122643 Yuba City, CA 9360 106895 Yuma, AZ Bill.Simpson@um.cc.umich.edu