ihnp4 cutoff

Affichage de 16 messages sur 6
ihnp4 cutoff Price 02/08/88 12:32
The removal of ihnp4 from the net is fast approaching (i.e., just
days now).  

All system administrators:  Please remove ihnp4 from your map entries.
You may do so by mailing an updated entry to rutgers!uucpmap.  Also,
remove ihnp4 from your Systems (L.sys) files.

Users:  Traffic intended for AT&T users may be mailed through the
'att' machines.  They may be considered a complete replacement for
ihnp4, in terms of traffic to and from AT&T users.  Multi-hop uucp
file transfer traffic (as opposed to email) is not currently supported
on 'att'; but hopefully it will be available in the future.  The 'att'
machines are now connected to more than 100 external hosts, including
such well-known machines as ucbvax and rutgers, so finding a path to
'att' should not be difficult.

Pass-through mail:  Sorry, but the current policy is not to pass mail
for third parties (traffic from a non-AT&T entity destined for a non-
AT&T entity.)  In the near future, the 'att' machines will refuse
third-party traffic.

Questions may be addressed to 'att!postmaster'.

                                                Douglas H. Price
                                                Postmaster, att
                                                att!dhp

ihnp4 cutoff Jacob Gore 03/08/88 09:10
Removing ihnp4 from the maps is not enough.

All neighbors of the att triad must declare it as att(DEAD).  ALL neighbors
must do that.  That's the only way to have pathalias generate paths through
att only when there is no way around it (in most cases, such paths will be to
AT&T machines).

Jacob Gore                                Go...@EECS.NWU.Edu
Northwestern Univ., EECS Dept.                {oddjob,gargoyle,att}!nucsrl!gore

ihnp4 cutoff Ron Heiby 04/08/88 07:46
Jacob Gore (go...@eecs.nwu.edu) writes:
> All neighbors of the att triad must declare it as att(DEAD).

I don't understand why this is the case.  If the links from att to the
outside world (like mcdchg) aren't published anywhere, pathalias should
not be generating any paths that contain the string "att!mcdchg".  Of
course, the link from att to mcdchg should be published *within* AT&T,
so pathalias runs for AT&T systems *can* show that link.

My understanding of pathalias is that a link decalared from A -> B
*does not* imply a link from B -> A at better than DEAD cost, anyway.
So, it's true that if the ONLY CONCEIVABLE WAY to get to a site is
from B -> A at some point, pathalias will generate such a path, but
it knows that the "cost" is astronomical.
--
Ron Heiby, heiby@mcdchg.UUCP        Moderator: comp.newprod & comp.unix
"Failure is one of the basic Freedoms!" The Doctor (in Robots of Death)

ihnp4 cutoff Douglas H. Price 04/08/88 09:05
>All neighbors of the att triad must declare it as att(DEAD).
>Jacob Gore                                Go...@EECS.NWU.Edu

Not really.  The pathalias software assumes a DEAD cost on an undeclared
return path.  The future map entries for 'att' will not include an explicit
listing of external sites.  This will cause the return path (i.e., the
path from 'att' to an external site) to appear DEAD, which will prevent
through-routing.  The forward path INTO AT&T, on the other hand, should
be declared as normal cost, since we want traffic destined for an AT&T
machine to reach via the most efficient route.


--
                                                Douglas H. Price
                                                Postmaster, att at IH
                                                @ AT&T Bell Laboratories
                                                ..!att!ihlpa!dhp

ihnp4 cutoff Michael T Sullivan 04/08/88 13:08
In article <1...@att.ATT.COM>, d...@att.ATT.COM (Price) writes:
>
> Pass-through mail:  Sorry, but the current policy is not to pass mail
> for third parties (traffic from a non-AT&T entity destined for a non-
> AT&T entity.)  In the near future, the 'att' machines will refuse
> third-party traffic.

I thought the whole idea of att was to allow third party traffic through
_it_ instead of through inhp4, etc., with the idea that it (third party
mail) could be routed to other att machines.  Maybe I should have mailed this
to att!postmaster, but if anybody has a copy of the original announcement
to correct me, I'd be happy to read it.

--
Michael Sullivan                {uunet|attmail}!vsi!sullivan
                                sull...@vsi.com
V-Systems, Inc. Santa Ana, CA        I'm too young to have been married 1 year!

ihnp4 cutoff Roger B.A. Klorese 05/08/88 06:32
In article <775@vsi.UUCP> sullivan@vsi.UUCP (Michael T Sullivan) writes:
>I thought the whole idea of att was to allow third party traffic through
>_it_ instead of through inhp4, etc., with the idea that it (third party
>mail) could be routed to other att machines.  Maybe I should have mailed this
>to att!postmaster, but if anybody has a copy of the original announcement
>to correct me, I'd be happy to read it.

"att" will carry mail from AT&T to the outside world, and from the outside
world into AT&T.  What it will *not* carry is mail *through* AT&T.
--
Roger B.A. Klorese                           MIPS Computer Systems, Inc.
{ames,decwrl,prls,pyramid}!mips!rogerk  25 Burlington Mall Rd, Suite 300
rogerk@mips.COM                                     Burlington, MA 01803
I don't think we're in toto any more, Kansas...          +1 617 270-0613