Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uunet!aplcen!uakari.primate.wisc.edu!brutus.cs.uiuc.edu!wuarchive!psuvax1!psuvm!UTDALLAS!LIPPKE From: LIPPKE@UTDALLAS.BITNET (David Lippke) Newsgroups: bit.listserv.nodmgt-l Subject: (no subject given) Message-ID: Date: 13 Feb 90 06:19:12 GMT Sender: Node Management Discussion Reply-To: Node Management Discussion Lines: 50 Approved: NETNEWS@PSUVM.BITNET Gateway In-Reply-To: Message of Mon, 12 Feb 90 19:07:29 EST from While I appreciate the complexities of dealing with multipath routing, I also feel that limiting the number of "backbone" nodes is a recipe for a quick return to today's loading problems (where 90% of the traffic really is carried by 5% of the nodes). I'm all for, say, the complete matrix interconnection of the 14 sites. We've done the same thing in Texas with a "core" set of nodes and it's worked out really well. I'm sure it'd help things out in this scenario as well. Besides, all of this is up to them in the final analysis --- they're the one who have to do all the work. There's no need for a fancy proposal; they can just get together and do it. I do have problems with the proposal in regard to the implication that there'd be no interconnection allowed between regions other than that provided by this "backbone". That's a technical cop out which isn't necessary and isn't acceptable. Switching to Roger's approximate question of "Why not hundreds of nodes?", I started asking myself how this could be achieved a year ago when the Texas Mesh settled down and we saw how well things worked with it. After some brainstorming with friends, I introduced a project at the last preSHARE technical meeting, which we call FRED, that addresses itself to the need for matrix-interconnect topologies between hundreds (or thousands) of nodes. About the shortest description I can give for FRED is that with it, the logical topologies are stars within "pools" of internet connectivity; the physical transmissions are directly between star members; routing information is quickly propagated; routing authority is distributed; and there is authenticated and secure remote update of routing information. Plus, FRED's implementation is purposely aimed at avoiding VM centricity. For more details, you might dig up a July 7th posting I made to BITNET-2 in regard to FRED (or you can just contact me about it). Although we've not progressed to the point where we'd hoped to be now, I'd like to report the gremlins working on the project ARE making headway and that our committment to FRED is even stronger than it was six months ago. The FRED project is very much alive and one day not so far away, FRED will roam the earth, stomping out BITNET problems wherever he finds them... na na na.. stop that music! (I get carried away ;-). Anyway, we're working on it and I think it stands a fair chance of providing the Domain/WKS type of connectivity that Roger seeks. Summing up, I support coordination and well managed-interconnection between the proposed sites. It's up to them and it should help. However, I reject any plan which would disallow interconnection between regions outside the connections between these sites. And to do something ourselves towards reducing routing and loading problems, some friends and I are working on a project called FRED. Kind Regards, David Lippke