jdi@psuvax.UUCP (01/25/84)
I think we're missing a crucial point of domains here. Domains are (in my
opinion, baised at best) primarily intended to reduce the neccessity for
each site on Usenet to maintain a database routing system (to know how to
get to other sites).
The idea is that if you send something to 'foo@bar.PA' all YOUR mailer must
know how to do is to get the message to a site in the PA domain. After that
the site you've passed it to in domain PA routes it to site bar.
This would mean that any particular site would only need 2 small routing files:
-- one to tell how to get messages to domains
-- one to tell how to get messages around INSIDE our own domain
On a related issue, here at Psu we're writing a mail-routing system. In our
opinion any site should be able to optimize a route.
Example: Mr. Naive sends a message to 'akgua!cbosgd!allegra!psuvax!joe'
Site 'akgua' gets this message and says "hmm, we're connected to site
psuvax directly, let's bypass this garbage and send it to them directly"
Is this the correct thing to do? I think there are a couple of issues
involved.
1: Absolute routes. In my view these are used mostly for testing
purposes and other such special circumstances. Should the whole
net try to support these?
2: Return addresses. The problem in the above example might be that
akgua talks to psuvax, BUT psuvax doesn't talk to akgua. This could
be avoided by a couple means, but I'm not really sure it's even
neccessary. Consider that a messages sent back OUT from psuvax
would NOT simply reply back through akgua, it would be routed
through a more appropriate link automatically
3: Mailer smartness. Here the question is "Who wants to update a site's
routing tables to be able to TELL who we should send mail to?" Well,
I think all of us doing a little work is something better than
cbosgd!ksh doing a LOT of work.
Anyway, we'd like to solicit comments/hints/suggestions about just what
philosophies/disciplines a router should follow. In addition we're just
about at the Beta-test stage for our mail router, and we'd like to ask for
one or two sites to test it for us. This would entail having a temporary
(or permanent) uucp or other network connection to 'psuvax', and having
some time and patience.
Sorry about the length of what was to be a 15 line message, but I've been
wondering just what others think of Internet format vs. bangs.
--
Spoken: John Irwin
AT&T: 814-237-5068
Net: jdi@psuvax1.BITNET jdi@penn-state.CSNET
UUCP: {akgua, allegra, cornell, ihnp4, burdvax}!psuvax!jdismb@ulysses.UUCP (Steven Bellovin) (01/29/84)
I wrestled with the same routing decisions when I wrote pathalias. I finally ended up implementing 3 modes: dumb (just pass the message on to the next host), simple (route to the left-most host), and smart (route to the right-most known host). Rmail used simple routing; locally-generated mail used smart routing (to handle netnews replies). Note that if you do any sort of routing on locally-generated routing, you're obligated to have rmail do at least simple routing, so that replies work right. That is, if I'm at site A and send a note to B!foo and C!bar, and B!foo replies to both of us, that reply will go to A!me and A!C!bar. But if C were routed by my mailer over several hops, the reply won't make it. I didn't use smart routing in rmail because I didn't want to break loop tests or deliberately-routed mail passing through.
ccc@cwruecmp.UUCP (Case Computer Club) (02/02/84)
There is something strangely artificial about using area codes as domain specifiers. Yes, artificial, because that's not the way the network is connected. For example, this machine (cwruecmp) is in Cleveland, OH, and receives its news from decvax. However, vortex also talks to decvax, and vortex is in California! What nicer way to play havoc with software? I propose the following solution: Why not use the usenet backbones which already exist as the uucp domains? This way, if machines start moving within a domain, let the backbone remember this fact and adjust accordingly. If a machine changes domains, it's fairly easy to notify the uucp world of that fact. Granted, this does make for slightly larger domains than would result from area codes. However, which would you rather remember, "@cwruecmp.decvax" or "@(216)cwruecmp"?
laura@utzoo.UUCP (Laura Creighton) (02/03/84)
3 years ago, it was easy. If you wanted to send to a site on the east coast and north, you mailed decvax!site!person. If you wanted to send to a site on the east coast and south you mailed duke!site. If you wanted to mail to somebody on the west coast you mailed ucbvax!site and if you wanted to mail somebody in the labs you mailed harpo!site. Over at utzoo we talked to both decvax and duke and decvax talked to ucbvax and harpo an everything was simple, except that there were 3 exceptions -- people who had gone to school at UC Berkeley and had set up a connection to ucbvax even though they were in New England and should have been talking to decvax by the scheme. Otherwise it worked very well, and my mail never bounced. Alas, there were fewer than 100 sites in those days. This solution will not work. Ihnp4 is doing an awe-inspiring and marvellous job at getting to people in the labs, but outside: gee -- I don't even *know* where "propter" is, let alone who its biggest neighbours are. What I see domains as is an attempt to make one machine responsible for a magic area so that all mail sent to any machine in that area can be sent through that site who can guarantee that the mail will be delivered. If there is something more to domains, then would somebody please explain it to me, because I have really looked and that is all that I have found. The basic assumptions here are as follows: the site routing information on the major site that is the omniscient one *must* be up to date. It must know how to get to all the other omniscient machines in all the other domains. This is rather easy -- the only difficulty arises when a new domain is created and for a short while all the omniscient machines may not know about it. The harder trick is to make sure that no new machine can be added to your domain whithout you hearing about it. if everybody new understood that they would send the site administrator mail at the major site saying "I just got frozzbozz my 68000 box up today and I now am polling gimpex in your domain so you have to know about me", but people don't seem to be doing this. I figure that awk script looking for people in your domain that you haven't heard about, quietly grinding away the spare cycles reading stuff in /usr/spool is the answer, but then an awk script is my answer to a lot of problems. domains are unique. domains (as one can see) are intimately connected with at least one machine in the domain (the one with the terrific and always up to date routing mechanism). Okay? If I am wrong, let me know. How about we stop trying to map domains into any sort of geographic model and just call them "decvax" "ucbvax" and "ihnp4"? If ihnp4 wants to be the omniscient machine at the domain that it wants to call "bell/at&t/weco/who-knows-what-next-week" then this is up to them, though I think that ihnp4, for all its inelegance, can be easily learned as "the name of the place you send stuff that is going to the labs". I think that domains as machine names will emphasize that the successful working of the domains depends on certain system administrators in having (and keeping) their act in gear. There is also a certain amount of pride involved in being able to say "I'm the ihnp4 in the domain ihnp4" which is a rather good thing given all th work involved. Comments? -- Laura Creighton (NOTE NEW ADDRESS) utzoo!laura
henry@utzoo.UUCP (Henry Spencer) (02/03/84)
The problem with using major site names as domain names is -- as was
pointed out in Washington -- that if a major site leaves the net, we're
screwed. It is not at all inconceivable, for example, that DEC might
someday undergo a major policy change and decvax would cease to be a
network hub. You know and I know that if domain names equal major-site
names, this assumption will end up imbedded in 2**22 programs. For this
reason, domain names *must* *not* be coupled to specific site names.
Apart from the issue of naming, the approach decided on in Washington
(setting up domains on an ad-hoc basis, which will probably be vaguely
geographical except for organizational cases like AT&T) actually will
probably give about the same results.
--
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,linus,decvax}!utzoo!henryhenry@utzoo.UUCP (Henry Spencer) (02/04/84)
Laura has made the same mistake as a lot of other people when they see
domains for the first time: they confuse names with routing. Our
full domain-based name might be, say, utzoo.ec.uucp (ec being Eastern
Canada). But if watmath.ec.uucp sends mail to utcsrgv.ec.uucp, this
doesn't mean that the mail has to pass through the "top" site of the
ec domain. In fact, in this case the mail goes direct. Only if the
sending site has no idea of a route to the destination does it consult
the "top" site. Even this does not necessarily imply sending the mail
via the top site -- the sending site may simply ask the top site for
enough information about the destination to construct a path (note
careful wording: the top site doesn't necessarily have to supply a
path, just help the sender to figure one out).
With the old uucp stuff, naming and routing are inextricably coupled.
In fact, names have only a local significance, since it's the route
you specify: "...!foobar!vortex!lauren" is unambiguous even though
there are two "vortex" sites, because the individual names matter only
to the sites that immediately precede and follow them in the route.
The domain-based system decouples naming and routing almost completely,
and it is important to make the distinction.
--
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,linus,decvax}!utzoo!henryphil@amd70.UUCP (Phil Ngai) (02/05/84)
> What I see domains as is an attempt to make one machine responsible > for a magic area so that all mail sent to any machine in that area > can be sent through that site who can guarantee that the mail will > be delivered. If there is something more to domains, then would > somebody please explain it to me, because I have really looked and > that is all that I have found. I don't think a domain is supposed to be an area in the geographic sense. If you mean an entity, that would seem correct. But the DEC domain will overlap the ATT domain geographically. > omniscient machines may not know about it. The harder trick > is to make sure that no new machine can be added to your > domain whithout you hearing about it. if everybody new > understood that they would send the site administrator mail > at the major site saying "I just got frozzbozz my 68000 box > up today and I now am polling gimpex in your domain so > you have to know about me", but people don't seem to be > doing this. The domain administrator presumably educates the administrators of the machines in his/her domain that they have to keep him up to date regarding their status. That is, gimpex knows not to add the frozzbozz connection without telling the domain administrator. Gimpex knows this because that was part of joining the domain they are in. Of course frozzbozz doesn't know the protocols, but gimpex should. This is just a layman's interpretation.-- Phil Ngai (408) 988-7777 {ucbvax,decwrl,ihnp4,allegra,intelca}!amd70!phil
fair@dual.UUCP (Erik E. Fair) (02/06/84)
This discussion rightly belongs in net.mail, as you should know Mel, because you have been making noises like you were among those present at `the meeting' on that Tuesday night. I will attempt to move this discussion to net.mail, and I will direct my subsequent responses there. There are two discussions going on here, and we should separate them quickly, or forever be confused. Those two discussions are: 1) Splitting up our `name space' (or address space?) in such a way as to avoid overflowing the extant naming scheme and bury routing information into software, rather than people's heads. 2) Qualify for a top level domain so that we can legitimately speak to the ARPANET on better than furtive grounds. The idea, as I understand it, is to do number 2 first, and then subdivide the domain as necessary. To do #2, there are certain requirements, as stated by thomas@utah-gr.UUCP (Spencer W. Thomas). He said: > Date: Mon, 23-Jan-84 20:34:33 PST > > A domain must have two attributes: > 1) a person who is "responsible" for all the sites in the domain - a > domain administrator, and > 2) a name-server which knows the actual address of all sites or > subdomains. In short, ARPA wants someone they can talk to when things go wrong, and they want things such that they can mail to person@site.UUCP, and not worry about the routing. We could conceivably accomplish this with address translation at every ARPANET gateway. The problem then reduces to keeping an up to date map, and making sure that it is distributed to the gateways in a timely fashion. That, however, does not solve the problem I listed as #1 up there. Depending upon who you believe, the network will grow vigorously or explosively in the next few years, and the result will be more chaos than we're used to. We will have sites with duplicate names turning up in different parts of the country, and routing a letter from system A to system B will be a nightmare. Domains have been suggested as a solution to that problem, and I have yet to hear anyone make a better suggestion. So instead of arguing the merits of domains, let's formulate a plan of action. I submit the following: 1. Map the network (already underway) (Thanks to parsec!kolstad, cbosgd!ksh, and wjh12!sob) 2. Write routing software to handle domain addresses (underway?) 3. Write a name server for ARPA. 4. Distribute the software EVERYWHERE. 5. Qualify for the `.UUCP' top level domain. 6. NOW begin discussion for domain sub-division. Number 4 is one of the most important, because if the whole network doesn't participate, we're dead. We can provide a certain amount of backward compatibility, but we can't have two network routing schemes working side by side, particularly in light of the addressing problems. I'm trying to put off the sub-division discussion until we have the software ready to handle the problem. It does no good to discuss grandiose plans for sub-division, when the current routing systems don't handle domains at all. Erik E. Fair dual!fair@BERKELEY.ARPA {ucbvax,ihnp4,cbosgd,amd70,zehntel,fortune,unisoft,onyx,its}!dual!fair Dual Systems Corporation, Berkeley, California P.S. Can we avoid use of loaded phrases & rhetoric? It only serves to heat the discussion beyond rationality. (This means you, mel@houxe.UUCP)
bbanerje@sjuvax.UUCP (B. Banerjee) (02/07/84)
Is this a private discussion, or can anyone join in? If its public, I'd like to contribute my admittedly inconsequential two-bits. dual!fair writes - >> I submit the following: >> >> 1. Map the network (already underway) >> (Thanks to parsec!kolstad, cbosgd!ksh, and wjh12!sob) >> 2. Write routing software to handle domain addresses (underway?) >> 3. Write a name server for ARPA. >> 4. Distribute the software EVERYWHERE. >> 5. Qualify for the `.UUCP' top level domain. >> 6. NOW begin discussion for domain sub-division. >> >> Number 4 is one of the most important, because if the whole network >> doesn't participate, we're dead. We can provide a certain amount of >> backward compatibility, but we can't have two network routing schemes >> working side by side, particularly in light of the addressing >> problems. I'm trying to put off the sub-division discussion until we >> have the software ready to handle the problem. It does no good to >> discuss grandiose plans for sub-division, when the current routing >> systems don't handle domains at all. I substantially agree with this. However, the "anarchy" of the current situation may make this rather difficult to enforce. With news alone, you have many sites still running A news (out of inertia?). This is for a system of relatively recent vintage. When you are speaking of UUCP software, and mailers, you open up a whole can of worms. I somehow doubt that the inertia of the UUCP network can be easily overcome. The solution is easy, though rather draconic. * Don't * make the new software backwards compatible with the old. Then make sure that enough sites, including the backbone ones, change over that us little guys will have to convert out of necessity. A pot-pourri of other considerations regarding this. 1. The routing tables/name-server on the gateway machines has to be up-to-date. Preferably, the process of verifying links could be automated. Also, the process of updating routing tables (Shades of net.adm.sites!!). 2. It would be great if some order were imposed on the UUCP network, doing away with leaf nodes. Preferably there should be at least two paths to each node (I'll let the wizards figure out the topological considerations). 3. Once, 1. and 2. have been addressed together with domains; why not have the software provide adaptive routing? Each forwarding site would require to know the routes to a relatively small number of systems/sub-domains. 4. The new software should be free, or close to it. One of the reasons our site didn't get on the CSNET was that the 5K annually probably wouldn't have been justified in terms of the number of users requiring internet mailing facilities. 5. A semi-grumble! If there is a concerted effort to map the net, its still a mystery at this site. At least 2 months ago I read on the net that we could be expecting a "Cybernet plea for information" soon. I'm still waiting! Enough for now. Just voicing my opinions. -- Binayak Banerjee {allegra | astrovax | bpa | burdvax}!sjuvax!bbanerje
teus@haring.UUCP (02/21/84)
"The domain-based system decouples naming and routing almost completely, and it is important to make the distinction." (Henry Spencer). That is already discovered by the PTT. People are already using domain addressing schemes for some time now. As well they use routing. To deliver an envelope with data domain addressing is used in the address and routing is used for delivering or better to carry the packet from mr Mark to mrs Karin. Insite the building the address of the packet sent by Mark is just "Karin". The postman has some intelligence insite the building so he knows to route the packet to Karin. The default domain in this case is just the building. Even the postman needs not to know the name of the building now. However if Karin is living in another building on the campus, Mark needs to include more to the address on his packet to Karin. He can use the sub-domain "Building 1C" in his address. So in this case Mark is living in "Building 2C" and Karin's address is "Karin in subdomain Building 1C". Both are on the campus say domain "Bell". The packet with the address Karin@Building1C is given to the postman in Marks building (2C), he does not know the route now, but knows that the postman in Building 1C knows all the details there and will route the packet to the subdomain Building 1C on the campus "Bell". That is not an easy job for him. Now he needs to think. Well he knows some of the friendly speedy postmen at that subdomain. So he routes the packet to a postman out there, which he trust most. And the packet will arrive at Karin's desk via that postman some time later. Well I'm living somewhere else in the world. So if I need to send a mail to Karin, I have to include more data about the domains (boundaries) the packet is crossing. All the postmen on each domain level will have a hint (or handle) to use their intelligence for finding a postman in each domain, who can do the rest. The postman in Building 2C from Mark does not need to know the route/path to Karin. Even he does not need to know the existance of Karin at all. Or the postman at my site (where I'm living) does not need to know that there is a subdomain Building 1C insite the campus Bell or perhaps that there is a Bell in the USA. The postmen in my top domain are the one who really should know a route to one of the postmen in the domain USA! Or if he knows a postmen at "Bell", well he can route the mail to him. Or there is of course the possibility that my postman does not have that intelligence. Well I can help him. If I know better I can provide him with a path/route to a postman which knows there. I.e. I give him the route to f.i. the postman in Building 2C (Marks postman) or f.i. to Mark himself. Conclusion: Only the postman on level n needs to know (is up to date) about one of the postmen on level n-1. If he is more intelligent (knows more details of levels < n-1) well that is nice. What he does is routing it to some postman on a level < n. So if someone new or some new postman is added only the postman (or better postmen) in that domain need to know that. If a new subdomain is added only the postmen one level higher need to know that. The only appointments to be taken is the format. (see <3508@utzoo.UUCP>, Lauren). I agree with Lauren that there is no need to map domains or subdomains on anything particular (f.i. geographic), but it can help. So "decvax" is ok (it has nothing to do any more with some machine at DEC!) and "NJ" is ok. The PTT is using some number scheme. Well that is for people, machines can handle names very easy. And it is easier for me to remember. The scheme as above will leave everybody free. A full path is still possible (but who will use that?), intelligence is used where possible, combinations of routing and domaining can be used. Even John Gilmore can hide his 50 machines inside the SUN domain (but should announce his postman machine to the California domain postman ucbvax). F.i. erix!enea!mcvax!philabs!cbosgd!mark (a full path), erix!enea!mcvax!mark@Bell.OH.USA.UUCP (a mixure), mark@cbosgd.Bell.OH.USA.UUCP (on domains) are the same. Forgiveness for the format, I just picked one which is suppost to be clear for everyone. -- Teus Hagen teus@mcvax.UUCP (CWI, Amsterdam)
per@erix.UUCP (Per Hedeland) (02/22/84)
<>
With respect, area codes are not for people, they are for telephones, which
lack a character-set keyboard...
Seriously, there is currently a problem with the "mixed" address you mention:
Things like 'erix!enea!mcvax!mark@cbosgd.UUCP' (removing a few "domains") are
ambiguos. In the old days (pre 4.2 sendmail), this would have been interpreted
as "erix!enea!mcvax!" "mark@cbosgd.UUCP", while now, at least most 4.2 sites
interpret it as "erix!enea!mcvax!mark" "@cbosgd.UUCP", which clearly won't
do the trick.
I won't say that 4.2 sendmail is in error for doing this (rather to the
contrary), it just goes to show the problems we'll be facing if "domain" and
"path" syntaxes are to coexist.
As far as I can understand, the only way to handle such a situation is total
separation of the two syntaxes (allowing conversion between them, of course,
but not mixing). In this respect, I think that sendmail (or rather, the
"standard" .cf files supplied, but that amounts to much the same thing) *is*
in error.
Per Hedeland
..{decvax, philabs}!mcvax!enea!erix!per or per@erix.UUCPgds@mit-eddie.UUCP (Greg Skinner) (02/24/84)
<wombat food>
You must make sure, when mail is sent from allegra direct to psuvax, the
return path for the reply is guaranteed to work. If psuvax->allegra
doesn't work, the original From: line mustbe used. Perhaps an extra
field, Path: to show the actual route the message took.
Instead of using ara codes, things that could be useful domains are MH,
PY, HO, Berkeley, etc.
--
By the power of Grayskull!
Greg-bo, Prince of Eternia, Defender of the Secrets of Castle Grayskull
{decvax!genrad, eagle!mit-vax, ihnp4}!mit-eddie!gds (UUCP)
Gds@XX (ARPA)