Re: 20402 routing entries (renumbering)
Renumbering workstations in principle *is* a no-brainer. But there are always wrinkles. And if those workstations are running a particle accelerator (as when a year or so ago I coordinated some renumbering at SLAC), you better have a damn good reason for doing it. A $20M facility running 7*24 expects good reasons for you to possibly screw it up, and their operational philosophy is to assume you will. I was able to renumber two largish groups of machines (200 or so in each), with quite a bit of coordination needed, and because of the various overlapping schedules it took a while before I could even start. Then, for each group I had to assemble numerous experts (Macs, Amigas, PCs, Next, RS/6000, Sun, Ultrix, VAX, Cisco). Luckily we had a good database of workstations so that I could tell the platform experts which machines were going to be involved. In some cases changes had to be backed out a couple of times because of something the platform experts forgot (or didn't know about). Now, can you imagine the conversation I might have had if still working there and SLAC agrees to exchange its class B (with about 1k out of 64k addresses assigned) for some number of class C: Me: SLAC has to renumber! Users: Again? OK Tim - but why? And what's in it for us? Me: (explanation of routing overload deleted) Users: So you are saying that of the 20k or so addresses in routers, SLAC renumbering saves just one entry? Me: Err, yes. Users: Don't ring us, we'll ring you! As Marty says, there is (unfortunately) no carrot - and users resent the stick. You apply the stick too often and you are out the door, either as an external provider or internal expert. Users barely (in some instances) know what an IP address is. They expect the network to be like the phone or power outlets; you just plug in where you happen to be. If we expect renumbering and provider-based addressing to be feasible, it seems to me that w/s vendors need to provide powerful tools to enable *transparent* *on-the-fly* renumbering - else it won't happen. And even if they do (and where's the carrot for *them*?), it will be quite a while before such tools are ubiquitous enough to make the process always easy. Should we be working with vendors in this area? Now will you all *go* *home* - it's the weekend, damnit! Tim Streater, DANTE. t.c.streater@dante.org.uk +44 223 302992
They expect the network to be like the phone or power outlets; you just plug in where you happen to be. If we expect renumbering and provider-based addressing to be feasible, it seems to me that w/s vendors need to provide powerful tools to enable *transparent* *on-the-fly* renumbering - else it won't happen. And even if they do (and where's the carrot for *them*?), it will be quite a while before such tools are ubiquitous enough to make the process always easy. Should we be working with vendors in this area? I'm told that numerous host vendors are working on developing DHCP. Of course, this does not fix legacy systems, but it does mean that renumbering may get easier than it is today. The carrot for them is that it makes it easier to renumber. ;-) This makes life easier for the network manager, who has to deal with Sally and George moving their department to the third floor problems. Tony
Sounds like the same kind of mentality that lets people in LA drive cars with a 20 miles/gallon mileage. Me: You have to use cars with better mileage! Users: Again? OK - but why? And what's in it for me? Me: (explanation of air overload of pullutants deleted) Users: So you are saying that of the 200 tons (or whatever) of the total pollution in LA's air due to the usage of gas in cars, that my buying a 60 miles/gallon car saves just a few pounds? Me: Err, yes. Users: Don't ring us, we'll ring you! .... later ... Users: Uuuuhhhh, this cancer is KILLing me ... .... much later (Users: are dead by now) ... Quiz: Should Users: have saved 2 gallons/day or moved to Alaska?
Renumbering workstations in principle *is* a no-brainer. But there are always wrinkles. And if those workstations are running a particle accelerator (as when a year or so ago I coordinated some renumbering at SLAC), you better have a damn good reason for doing it. A $20M facility running 7*24 expects good reasons for you to possibly screw it up, and their operational philosophy is to assume you will.
I was able to renumber two largish groups of machines (200 or so in each), with quite a bit of coordination needed, and because of the various overlapping schedules it took a while before I could even start. Then, for each group I had to assemble numerous experts (Macs, Amigas, PCs, Next, RS/6000, Sun, Ultrix, VAX, Cisco). Luckily we had a good database of workstations so that I could tell the platform experts which machines were going to be involved. In some cases changes had to be backed out a couple of times because of something the platform experts forgot (or didn't know about).
Now, can you imagine the conversation I might have had if still working there and SLAC agrees to exchange its class B (with about 1k out of 64k addresses assigned) for some number of class C:
Me: SLAC has to renumber! Users: Again? OK Tim - but why? And what's in it for us? Me: (explanation of routing overload deleted) Users: So you are saying that of the 20k or so addresses in routers, SLAC renumbering saves just one entry? Me: Err, yes. Users: Don't ring us, we'll ring you!
As Marty says, there is (unfortunately) no carrot - and users resent the stick. You apply the stick too often and you are out the door, either as an external provider or internal expert. Users barely (in some instances) know what an IP address is. They expect the network to be like the phone or power outlets; you just plug in where you happen to be. If we expect renumbering and provider-based addressing to be feasible, it seems to me that w/s vendors need to provide powerful tools to enable *transparent* *on-the-fly* renumbering - else it won't happen. And even if they do (and where's the carrot for *them*?), it will be quite a while before such tools are ubiquitous enough to make the process always easy. Should we be working with vendors in this area?
Now will you all *go* *home* - it's the weekend, damnit!
Tim Streater, DANTE. t.c.streater@dante.org.uk +44 223 302992
From what I have seen so far, despite them I**3 claims, there seems to be a neverending target with really no end in sight. Like it or not, as several have pointed out already, router still, as already for the last ten years or so, get blown away by the routing table sizes. If you have a well defined funding stream you may be able to upgrade, otherwise you may be screwed. There is no routing plan on a global level that also goes down to the capillaries and their interconnectivity, and
Look, guys, get real. CIDR is a big kluge and it was predictable as such. But as a second or third best "solution" it is necessary to use it, as the powers of anarchy screwed the Internet royally two years ago when the Internet community should have elected NSAPs. Remember the IESG solicitation for IPv7, to then be all done and settled by November 1992 (or was it 1991?). CIDR is just a bandaid because the community does not have its act together, and varieties of things are not driven by operational requirements. I don't particularly like CIDR, as compared to cleaner choices, but believe we have no choice but to use it as much and as best we can. Until the IETF/IESG/IAB/whoever get their stuff in gear and define and follow through on a process that pragmatically looks at requirements, defines a reasonable subset as strategic direction and people go off implementing and deploying it. people naively believe that arbitrary interconnections have to work for generations to come. And if I create a 2400 bps dial up link to London, it has to be possible for the whole US to use it as a fallback, as a solid requirement, right? You have no choice, gang, reality says there are too many routes, routers break, and arbitrariness doesn't scale. Amplifying this will be the dismantling of the NSFNET, resulting in much more of an interconnection weave than a backbone or core. As much as I dislike CIDR by itself, I see no choice at this point of time to move ahead with it as much as we can, even if it causes some pain, or problems will continue, until we find a long term sulution and quit this bickering about the IPng protocol details. Hans-Werner PS: May be Microsoft *should* make the choice for us. Then even Marty gets his clean slate.
-------- ] From: Tim Streater <t.c.streater@dante.org.uk> ] Subject: Re: 20402 routing entries (renumbering) ] Date: Sat, 16 Apr 1994 01:01:38 +0000 ] ... ] Now, can you imagine the conversation I might have had if still working ] there and SLAC agrees to exchange its class B (with about 1k out of 64k ] addresses assigned) for some number of class C: ] ] Me: SLAC has to renumber! ] Users: Again? OK Tim - but why? And what's in it for us? ] Me: (explanation of routing overload deleted) ] Users: So you are saying that of the 20k or so addresses in routers, ] SLAC renumbering saves just one entry? ] Me: Err, yes. ] Users: Don't ring us, we'll ring you! ] ] As Marty says, there is (unfortunately) no carrot - and users resent the ] stick. ] ... Tim, I agree that there is no motivation for renumbering. I also agreement that convenient renumbering technology would be very valuable in pursuit of CIDR renumbering. I don't believe that renumbering technology will be sufficient, because (as Marty notes): there's still no carrot. The fact of the matter is that there is going to be a carrot soon... it may not be a very big carrot, but there will be one. At some point or another, the cost of route entry propagation will be identified and some enterprising soul will turn a "problem" into a business opportunity by actually recovering these costs seperately. Yes, it will be messy, and providers will begin handling routing (not traffic) settlements, but if the cost component of routing gets high enough, then it's quite likely to emerge as a separate item. Of course, most folks will be forgiven for entering a single route into the Internet (and it will be absorbed in service costs as it is today), but folks with random collections of network numbers will feel some impact. Will a fortune 500 company be concerned about the extra [wild estimate] $250/month to keep their dozen distinct CIDR entries? Perhaps not, they may even consider it a good investment compared to renumbering when they change providers. Would the local bookstore renumber both their hosts (when changing providers) in order to avoid $20/month? Maybe. Look, if the real cost of a routing entry in the global Internet is low, then people will pay it and not worry about CIDR. If it turns out that it's quite costly to enter a global route, then some people will invest the effort to avoid the cost. No, it's not going to have an impact on most businesses, because the financials will almost work out to paying for the routing service. I also expect that SLAC would pay to have their entry maintained in the situation above. /John
John Curran <jcurran@nic.near.net> writes: ... At some point or another, the cost of route entry propagation will be identified and some enterprising soul will turn a "problem" into a business opportunity by actually recovering these costs seperately. Yes, it will be messy, and providers will begin handling routing (not traffic) settlements, but if the cost component of routing gets high enough, then it's quite likely to emerge as a separate item.
... Will a fortune 500 company be concerned about the extra [wild estimate] $250/month to keep their dozen distinct CIDR entries? Perhaps not, they may even consider it a good investment compared to renumbering when they change providers. Would the local bookstore renumber both their hosts (when changing providers) in order to avoid $20/month? Maybe. ...
RIGHT ON !
Tim, Many vendors have recently implemented DHCP and I know a few vendors who are very interested in going beyond simple DHCP. The goal is to get to the point that you get your system, and it can simply plug into the Internet and most things you want, DNS and addresses (host, router, other servers, etc.) are all auto-configured over the wire. In the case of dialup or ISDN this could be done up to the point of providing the "phone number" and one could imagine a system where the initial phone number would not be necessary. With set top box being the current rage in the telecom industry it is very important to have a viable strategy for autoconfiguring/registering into the Internet for simple devices (PCs on modems/ISDN, set top box, etc.). cheers, peter
participants (6)
-
Daniel Karrenberg -
hwb＠upeksa.sdsc.edu -
John Curran -
Peter S. Ford -
t.c.streater＠dante.org.uk -
Tony Li