Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!inria!chorus!sylvain From: sylvain@burden.chorus.fr (Sylvain Langlois) Newsgroups: comp.sys.isis Subject: Re: ISIS YP SERVER REDESIGN Message-ID: Date: 25 Nov 89 13:12:40 GMT References: <34463@cornell.UUCP> Sender: sylvain@chorus.fr Distribution: comp Organization: Chorus Systemes, Saint-Quentin-En-Yvelines, France Lines: 62 In-reply-to: ken@gvax.cs.cornell.edu's message of 20 Nov 89 17:07:06 GMT In article <34463@cornell.UUCP> ken@gvax.cs.cornell.edu (Ken Birman) writes: KB> Based on the comments I've seen and the two posting from readers on this KB> subject, there seems to be a consensus on a few issues: KB> 1) The YP architecture as SUN designed it doesn't scale well, and people KB> are seeing this as a problem. KB> [... stuff deleted] KB> The "YP service" should be hierarchical at several levels: KB> 1) Multi-enterprise. At this level the YP services for places like KB> Cornell, MIT, IBM, DEC talk to each other. It isn't clear what they KB> would "export", but obviously this will be a small subset of what YP KB> manages internally to each site. KB> 2) Multi-LAN. At this level, one envisions multiple smaller YP service KB> groups concerned with providing services local to a small number of KB> machines. Let me throw a stupid idea here. I've been looking at improving a Yellow Pages service using ISIS reliable and fast protocols a while ago (job has currently returned to its ashes now :-(, sorry Ken). I personnaly think that a faster service than Sun YP could be implemented using ISIS. But I'm not sure about you mean with "scalability" It seems to me that YP-like service is not suited at all for wide area networks. Work has been done with X500, or X500-like, service. I admit that X500 it far too complicated for handling "small" databases, but it may be more accurate for huge volume of entries. I am not promoting the use of X500 for solving all problems, but one may want someday to use an ISIS-YP-based service for implementing kind of directory services, collecting zillions (well, let say hundreds...) of entries to implement a "domain name server". My deep question is: do you think a YP-like service covering a campus wide domain HAS to be the same as one covering a US wide area (this is what I understand from your "Multi-Enterprise" environment -- unless the Enterprise covers a galactic-wide domain, in which case you may require some help from Spock:-)? I doubt. X500-like techniques seem to be a better move in this latter direction (cf. NYSERnet experiments with White Pages). KB> Does this sound like a promising architecture? What KB> limitations do people see if we pursue this? Note that the KB> idea is to extend the current YP name interface to "hide" the KB> locality of a reference in the name, so that the current name KB> structure won't need much redesign. I clearly a performance problem if the area covered by the service goes to wide. The nature of the information which may be used by wide areas services may also be of very different types (not only /etc/passwd or /etc/services, but more sophisticated records): I don't the YP is able to handle that correctly. Sylvain -- ---------------- Sylvain Langlois "Dogmatic attachement to the supposed merits (sylvain@chorus.fr) of a particular structure hinders the search (sylvain%chorus.fr@mcsun.EU.net) of an appropriate structure" (Robert Fripp)