Path: utzoo!attcan!uunet!husc6!bloom-beacon!bu-cs!purdue!decwrl!ucbvax!MITVMA.MIT.EDU!KASTEN
From: KASTEN@MITVMA.MIT.EDU (Frank Kastenholz)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: hosts and gateways and protocols
Message-ID: <8805210016.AA08227@ucbvax.Berkeley.EDU>
Date: 18 May 88 14:20:02 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 47


>What my tendancy has been is to allow for the specification of a default
>router (yes, just one).  If the router isn't specified, then we listen
>for RIP broadcasts.  Now, I never know what is INSIDE a RIP packet.  However,
>I choose a default router based on the largest RIP packet seen, and I stay
>with that router for five minutes or so.  So, if I continue getting RIP
>packets, then I keep following routers.

This assumes that your host can understand that the packet is a RIP
packet. If my routers use another IGP then the hosts will not know that
it is an IGP packet so they can not "backtrack" to the source of the
packet and get a router.


>I also feel for those souls whose routers occasionally crash, and who would
>like routes to switch automatically.  I don't believe that just because
>you need this capability once per day that should exclude it from being
>automated.

Unfortunately I must strongly disagree with the last sentence. TCP/IP is
entering the non-technical world very rapidly. The company that I work
for makes large editorial systems for newspapers - lets reporters and
ad takers enter their material, editors edit it, layout people design and
build the pages and then output the whole thing to a photo typesetter.
Newspaper people (reporters/editors/etc) know next to nothing about
networking and we can't really teach them. This model is valid in more
and more networks. the failure recovery mechanism MUST BE AUTOMATIC. The
recovery mechanism is required for a very simple reason - money. If a
newspaper doesn't go to press because the network broke then the paper
does not realize its advertising revenues - and that is the name of the
game for all of the "commercial" TCP/IP sites.

I think that the idea of using multicasts/broadcasts is better than the
query/response model. It lets the hosts detect a gateway failure
before they go through a few retransmissions wasting resources (assuming that
the hosts are reasonably intelligent). The only possible problem is that
there may be networks with many gateways and the "I am a gateway" traffic
could get to be burdensome (especially for small hosts that can't handle
many packets per second - e.g. PC's). Perhaps using an Ethernet multicast
address (for Ethernet networks) would be the way to go - it could let
small hosts filter out the unwanted traffic. If this is done, though,
a query/response mechanism may also be needed.

Cheers
Frank Kastenholz
EPPS Inc - a Kodak Company
All opinions are mine........