okuno@Shasta.STANFORD.EDU (Hiroshi Okuno) (06/09/87)
Address: 701 Welch Road, Building C, Palo Alto, CA 94304-1703 Phone: +1 (415)725-4854 Internet: okuno@sumex-aim.stanford.edu UUCP: hplabs!Shasta!nttca!okuno I'm the postmaster of nttca and one of the postmasters of the NTT domain. (NTT stands for Nippon Telephone and Telegraph, not for Not aT&T.) Nttca is an international gateway of the NTT domain installed in Los Altos, California. Recently, we have a very strange experience. That is, messages sent in West Germany to nttca were delivered via unido (West Germany), mcvax (the Netherlands), kddlabs (Japan), xx.ll.mit.edu (U.S.A.), rutgers.edu and shasta.stanford.edu. Note that the recipients of these messages are at nttca, not at any other sites in the NTT domain. The possible causes of this strange routing are (1) The SMAIL program is so wise that any message sent to any site beginning with "ntt" is delivered to kddlab (Japanese USENET backbone site). (2) nttca is registered as a Japanese site by mistake at mcvax. If so, who posted a wrong UUMAP information on nttca? The UUMAP information on nttca is correct at least at shasta.stanford.edu. Any comment or suggestions? Thanks, - Gitchang -
kre@munnari.UUCP (06/10/87)
In article <1747@Shasta.STANFORD.EDU>, okuno@Shasta.STANFORD.EDU (Hiroshi Okuno) writes: > Recently, we have a very strange experience. That is, messages > sent in West Germany to nttca were delivered via unido (West Germany), > mcvax (the Netherlands), kddlabs (Japan), xx.ll.mit.edu (U.S.A.), > rutgers.edu and shasta.stanford.edu. Our maps show a link from nttlab to nttca, and we would route to nttca as munnari!nttlab!nttca!user. I guess mcvax thinks the same, that to get to nttca, the best way is via nttlab, and the best way to there is through kddlabs. But then, given the route you suggested, I assume that kddlabs knows that it can't route its mail to the US via ntt's link, and sends the mail to seismo instead, from there it goes over the rutgers-shasta-nttca path. I suspect that this is all a result of the Japanese network's partitioning into the 3 more or less separate parts for the purposes of foreign links -- none of the routing software understands this. The only way to cope is probably going to be to make it appear (outside Japan) that the 3 groups simply don't communicate with each other at all. Internally, the links would need to exist, so mail from one site to another isn't routed via the US or Europe (or both!) kre
okuno@Shasta.UUCP (06/11/87)
Thanks for giving me many comments on my previous message.
I could figure out why such a strange route was selected.
("Strange" for those who know the geology.)
(1) The cost information of kddlab is wrong.
The link from kddlab to nttlab should be DEAD. We asked
amami@kddlab.UUCP to modify their entry several times, but in vain.
Since kddlab is the Japanese backbone node, we have no means to
correct their entry.
kddlab ...
flats(DAILY/6), nttlab(DAILY/6), icot(DAILY/6),
...
Note that the cost from nttlab to kddlab is DEAD.
nttlab nttca(HOURLY), ...
kddlab(DEAD), ccut(DEAD), titcca(DEAD), icot(DEAD),
...
(2) The hostname of Shasta in the UUMAP is wrong.
nttca is connected to shasta.stanford.edu (Internet and USENET site)
and polls it once an hour. However, the hostname of Shasta in UUMAP
is registered as "shasta", not "Shasta". I asked the postmaster of
Shasta to post a correct site information about two months ago, and he
posted one, but I'm afraid that it is not delivered to the UUCP world
yet.
Please correct your UUCP map.
[For your curiosity]
Why are we making every effort to avoid any kddlab route?
Because of a financial problem. JUNET will be divided into several
categories by the way of paying the cost of international communications.
- Gitchang -
Arpanet: okuno@sumex-aim.stanford.edu
UUCP: {hplabs, decwrl, ll-xn, caip}!Shasta!nttca!okuno
Postal-Address: 701 Welch Road, Building C, Palo Alto, CA 94304-1703
Phone: +1 (415)725-4854