brant@manta.pha.pa.us (Brant Cheikes) (10/02/88)
I am persuaded by the many arguments eschewing dynamic routing (to adopt Mr. Vixie's distinction of dynamic vs. passive routing). Despite Mr. Lear's promises, I just cannot imagine there is any way to ensure that all rerouting sites have data accurate enough on which to base address rewriting decisions. (an aside: I hear that the new smail under development will not support dynamic routing which, if true, renders this discussion moot. Can anyone speak knowledgeably to this point?) Yet if we are to eliminate dynamic routing, the following problems (at least) need solutions: 1. Sites must be able to maintain private links. Just omitting the links from the published maps will not prevent manual routing thru private links. This problem should be addressed by smail, I believe. When I raised this point about private links, Mr. Vixie pointed out that shell scripts could be used to ensure that private links were kept private. That approach seems wrongheaded to me; why not an extension to smail that would, for example, prevent mail from going out over a link unless that mail originated from a site/user listed in an authorization file? Mail over unauthorized links should be bounced back to the originator. 2. We have acknowledged that network topology is in constant flux. Local changes are sometimes usefully supported by dynamic routing. For example: the published map for manta lists a DIRECT link to drexel. Say I'm told that drexel will be down for a week, so I locally update my map listing drexel as DEAD. What do I do now with incoming mail that is routed thru drexel (NB: not DESTINED for drexel, merely routed thru it)? It seems improper for me to hold such mail for a week, when a different, functional path to the destination might exist. If I can't reroute, I must bounce. Therefore, smail (again the appropriate mechanism) needs to be extended to bounce mail routed over dead links. 3. Absurdly long paths, usually created by replies to news articles. I don't have anything to offer here; the newsreaders cannot simply be fixed to no longer use return-path, and sometimes long paths may be useful (for testing, perhaps?). Yet return-paths often don't, causing mail to bounce unnecessarily thus increasing net traffic. What to do? There are others I am sure, but that's enough for now. I think that we all could spend our time more productively on this newsgroup trying to identify and solve the problems created by either the elimination of dynamic routing or the application of same, rather than continuing the unproductive debate of one versus the other. Mr. Lear, I gather, is working on the latter, for which he is to be commended and wished lots of luck (he'll need all he can get, I suspect :-). To start such discussion, we should have working definitions of the principles that allow/disallow dynamic routing. How about: Principle of PASSIVE-ROUTING: "I only know reliably about my neighbors, but if someone asks me to next-hop to non-neighbor site baz, I have the right to assume that the baz in question is the baz in the maps and route accordingly." Principle of DYNAMIC-ROUTING: "I always know the correct path to the destination, and if I don't, someone along the new path I generate does and will reroute accordingly." Now, how do we make them work? -- Brant Cheikes University of Pennsylvania Department of Computer and Information Science Internet: brant@manta.pha.pa.us, UUCP: bpa!manta!brant
sewilco@datapg.MN.ORG (Scot E Wilcoxon) (10/03/88)
In article <433@manta.pha.pa.us> brant@manta.pha.pa.us (Brant Cheikes) writes:
...
<Yet if we are to eliminate dynamic routing, the following problems (at
<least) need solutions:
<
<1. Sites must be able to maintain private links. Just omitting the
...
<an authorization file? Mail over unauthorized links should be bounced
<back to the originator.
<
<2. We have acknowledged that network topology is in constant flux.
...
Brant brings up several issues.
Smail should allow local exceptions to mapped links.
Type of exceptions:
Mail through an exceptional link.
Mail to an exceptional link.
Possible actions for an exceptional link:
1. Bounce mail.
1a. Bounce all mail except that from certain sites.
1b. Bounce only mail from certain sites.
2. Reroute mail through an alternate path.
2a. Reroute all mail except that from certain sites.
2b. Reroute only mail from certain sites.
If "exceptional link" declarations allow date ranges, problems of known
duration can be entered once and automatically begin/expire.
(I could use "private link" support in smail as well, but don't need to
list it here as a "private link" is just an exceptional link with
actions 1a or 2a.)
--
Scot E. Wilcoxon sewilco@DataPg.MN.ORG {amdahl|hpda}!bungia!datapg!sewilco
Data Progress UNIX masts & rigging +1 612-825-2607 uunet!datapg!sewilco
"When Hurricane Gilbert comes through, I'll stay here to experience it."
CBS:"What if you experience death?" "Well, I'll worry about that later."brant@linc.cis.upenn.edu (Brant Cheikes) (10/04/88)
In article <1915@datapg.MN.ORG> sewilco@datapg.MN.ORG contributes a nice generalization of two concerns I raised: > Smail should allow local exceptions to mapped links. He goes on to give a list of possible actions to take when mail comes in that is routed out over an "exceptional" link. A subtle case is, I think, overlooked, suggesting yet further extensions to smail (and perhaps pathalias). Consider this scenario: on manta, I want to maintain a exceptional link to site baz. Only local mail or mail mail originating from sites foo and bletch should be able to use the manta!baz link. Sites foo and bletch need not be neighbors of manta. IF we allow sewilco's actions 2(a) or (b), to wit: > 2a. Reroute all mail except that from certain sites. > 2b. Reroute only mail from certain sites. Here's the problem: Since I'm allowing local mail to use the manta!baz link, I presumably incorporate a local connectivity entry in manta's pathalias run of the form: manta baz(DIRECT) This link is not published generally, though foo and bletch have been authorized to make similar extensions to their pathalias data. Now manta's paths database contains paths to various machines over the manta!baz link. Suppose that to get to uunet from manta, the path would be manta!baz!uunet. So far, so good: users on manta can address mail to user@uunet and it'll go out as manta!baz!uunet!user. And, presumably, paths originating at foo or bletch, destined for uunet!user, could use the manta!baz link as well. But say mail arrives on manta from site mumble, destined for baz!uunet!user. Could happen, right? Some bozo using Reply-Path to a news article maybe? Say I want to reroute that mail. Oops, what's this? The only path I know to uunet is through baz... One solution that comes immediately to mind is to maintain TWO paths databases, one using "exceptional" links and the other not. Is that a solution? Is it the best solution? Are there other problems? Another idea would be to somehow redesign pathalias so that paths can be generated "on the fly" under different constraints, but I'm not sure that's necessary, and it's certainly more expensive than the periodic database update scheme currently in place. Brant Cheikes University of Pennsylvania Department of Computer and Information Science brant@linc.cis.upenn.edu, brant@manta.pha.pa.us, bpa!manta!brant
page@swan.ulowell.edu (Bob Page) (10/04/88)
brant@manta.pha.pa.us (Brant Cheikes) wrote: >I hear that the new smail under development will not support dynamic >routing which, if true, renders this discussion moot. Not moot at all, as no site is forced to use any MTA with such restrictions. We don't run smail here, thank you. If we did active rerouting (we don't), we'd keep doing it regardless of what smail did. >Yet if we are to eliminate dynamic routing, We're pissing into the wind here folks. Mel has heard all the arguments, he isn't convinced. If you don't like it, do your best not to send mail through rutgers. If a site isn't being network-social (like sun), tell them about it. If their attitude is similar to "we have better things to do", do your best not to send mail through them. If you find a good site, praise them. >Principle of PASSIVE-ROUTING: "I only know reliably about my >neighbors, but if someone asks me to next-hop to non-neighbor site >baz, I have the right to assume that the baz in question is the baz in >the maps and route accordingly." > >Principle of DYNAMIC-ROUTING: "I always know the correct path to the ^^^^^^^ >destination, and if I don't, someone along the new path I generate >does and will reroute accordingly." 'correct' should be either 'shortest' or 'least cost'. Any site that reroutes does so because it is shorter or costs less, not because it is correct. (and there's the rub!) I think that rerouting to a rerouting host (last clause of the DYNAMIC definition) is the worst sin possible. If you don't know the host, at least leave the path alone. I have a third possibilty - call it DOMAIN-ROUTING - I currently don't do it, but have given it some thought. Given a path like: host1!host2!another!even!smore!host.foo.edu!host7!host8!user I claim I can *legally* change that to host.foo.edu!host7!host8!user if I can determine that I know how to get to host.foo.edu. All Internet hosts capable of MX should be able to. UUCP-only sites will only be able to do this a small percent of the time, I suspect. The theory is that there should never be more than one site named host.foo.edu - so cutting out the intermediate middle hosts is OK. Comments? I know the purist arguments about path testing. ..Bob -- Bob Page, U of Lowell CS Dept. page@swan.ulowell.edu ulowell!page
lmb@vsi1.UUCP (Larry Blair) (10/05/88)
In article <9447@swan.ulowell.edu> page@swan.ulowell.edu (Bob Page) writes:
=I have a third possibilty - call it DOMAIN-ROUTING - I currently don't
=do it, but have given it some thought. Given a path like:
=
= host1!host2!another!even!smore!host.foo.edu!host7!host8!user
=
=I claim I can *legally* change that to
=
= host.foo.edu!host7!host8!user
This type of rerouting is reasonable because you are talking about a fully
qualified domain. There can only be one host.foo.edu, so sending mail there
directly is OK.
There has been discussion that if, say, "even" lists "smore" in its map entry,
then you can assume that their "smore" is the same as the "smore" you list
in yours. Of course smail doesn't do this kind of routing, but this, too,
would seem reasonable.
--
Larry Blair ames!vsi1!lmb lmb%vsi1@ames.arc.nasa.govdavid@ms.uky.edu (David Herron -- One of the vertebrae) (10/06/88)
Bob,
I think that you are right in thinking you could truncate a UUCP
path with a domain in it down to the domain.
The only problem I see with this is that people are sometimes wanting
to check connectivity on some path, and your truncation will
just about kill that check.
--
<-- David Herron; The official MMDF guy of the 1988 Olympics <david@ms.uky.edu>
<-- ska: David le casse\*' {rutgers,uunet}!ukma!david, david@UKMA.BITNET
<-- What does the phrase "Don't work too hard"
<-- have to do with the decline of the american 'work ethic'?wisner@zug.AI.MIT.EDU (Bill Wisner) (10/06/88)
In article <9447@swan.ulowell.edu> page@swan.ulowell.edu (Bob Page) writes: >We don't run smail here, thank you. Sendmail snobbery is not necessary. Building and maintaining sendmail on a UUCP-only site is generally more trouble than it is worth, particularly if you happen to be a System V box. Smail 2.5 is capable enough for a machine that isn't on the Internet and Smail 3.0 is sophisticated enough -- it even speaks SMTP -- to allow many people to ditch sendmail entirely. Don't get me wrong. Sendmail has its uses. I'm running it here for all the stUdlY MX support. And a few minutes of sendmail.cf hacking knocks me out quicker than sleeping pills.
page@swan.ulowell.edu (Bob Page) (10/07/88)
I wrote: >We don't run smail here, thank you. wisner@zug.AI.MIT.EDU (Bill Wisner) replied: >Sendmail snobbery is not necessary. None intended. We use something very *similar* to smail; the original point being that not everybody runs smail. I agree with Bill - hacking up sendmail.cf files for UUCP only sites is overkill and unnecessary. >sendmail.cf hacking knocks me out quicker than sleeping pills. Hmm, I always thought of it like playing Zork... ..Bob -- Bob Page, U of Lowell CS Dept. page@swan.ulowell.edu ulowell!page