Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucsd!hub.ucsb.edu!spectrum.CMC.COM!spectrum.cmc.com!lars From: lars@spectrum.cmc.com (Lars Poulsen) Newsgroups: comp.protocols.tcp-ip Subject: Re: Can subnets be separated by another net? Message-ID: <1990Jul10.191836.17770@spectrum.CMC.COM> Date: 10 Jul 90 19:18:36 GMT References: <9007101422.AA01680@chiya.bellcore.com> Sender: lars@spectrum.CMC.COM (Lars Poulsen) Organization: Rockwell CMC Lines: 71 I wrote: > The most common case where clients ask about disjoint subnets, is where > an enterprise is geographically disjoint (say offices in Los Angeles, > Denver and Boston) and wants to attach each office separately to the > Internet, while assigning all host addresses out of the same class B > network number. This of course is utterly undesirable (would OSPF allow > it to be set up at all ?) and contravenes all the intentions for which > subnets were invented. Paul Tsuchiya replied: PT>Hmmm. Why is it utterly undesirable that one organization PT>in locations separated by the Internet not split up a Class B address? PT>The only reason I can think of is that Internet routers are incapable of PT>looking at subnet parts of the address--in other words, our Internet PT>routers (or routing protocols) are inadequate. The thing just simply PT>wouldn't work. Indeed. The intent of IP is to route based on the network number, and for most low-level routers not to have to know very many routes. Subnets were invented to allow an organization to have multiple routes internally while presenting only one logical point of entry to the outside world. PT>However, I don't necessarily see something inherently bad about this. PT>I mean, given today's address structure (net.subnet.host), what are the PT>alternatives? PT>First, the organization could have multiple class C addresses? However, PT>this puts a load equal to subnetted class B addresses on the Internet. PT>Each router must maintain one routing table entry for each location. The organization could be made to connect the disjoint subnets internally; in the worst case, this could be done by tunnelling in the routers. This is not too unlike the old ARPA/MIL/NSF geographical overlay. Each backbone router will route packets to the multi-site organization to the closest point of entry, and that router will get it to where it needs to get to, either directly, or wrapped in an envelope with the backbone address of the entrypoint router on the other end. PT>... However, a more general, multi-level hierarchical address scheme PT>coupled with an efficient address assignment scheme is what's needed. The ultimate in general, multilevel hierachical address schemes is ISO-IP, with its address format codes etc. IMHO, that way leads to utter madness. PT>Hear my ideas on this at the UCB IETF, or if you can't be there, PT>ask me and I'll send you a paper on the topic. Yes, I would like to see the paper. ------- Similarly, Milo S. Medin (NASA ARC NSI Project Office) says: MM>I don't think that the issue of older protocols not supporting such a MM>configuration is an issue. Time moves on, and progress gets made. but at the same time: MM>Your case about the business with the disjoint offices ... won't MM>work, ... because that organization's connections MM>to the various regional or brand X networks and those net`s connections to MM>each other typically use EGP, which does not allow the passing of MM>subnet data. If everyone was glued together by one supernetwork, all MM>running an IGP like OSPF, then yes, it could work. But that's not MM>likely to be the way people's connections would work in any case. - which was exactly my point. The "real" commercial networks are always years behind the state of the "art". Don't get me wrong: I think OSPF is great, and we should move to deploy it instead of EGP as quickly as we can, from the core out. But so long as not even the regionals are up to that level of sophistication, EGP is the commercial reality, and those of us whose job is to "get me connected NOW" have to find ways to live within those constraints. -- / Lars Poulsen, SMTS Software Engineer CMC Rockwell lars@CMC.COM