Return-Path:
Received: from pescadero.stanford.edu by NRI.NRI.Reston.VA.US id aa09367;
         6 Jan 90 18:43 EST
Received:  by Pescadero.Stanford.EDU (5.59/25-eef) id AA08497; Sat, 6 Jan 90 15:45:16 PDT
Date: 6 Jan 1990 15:30-PST
From: Steve Deering <[email protected]>
Subject: Router Discovery WG meeting report
To: [email protected], [email protected]
Message-Id: <90/01/06 [email protected]>

Greg and Phill,

Here are the minutes of the first meeting of the Router Discovery WG,
for you to file away.  Note that the minutes refer to "gateway" discovery,
rather than "router" discovery, which was our terminology at that time.

Steve

--------------------------------------------------------------------
Gateway Discovery Working Group
Chairperson: Steve Deering/Stanford

REPORT ON MEETING OF DECEMBER 12, 1989
at DEC Western Research Lab, Palo Alto, CA.
Reported by Steve Deering

ATTENDEES

1. Art Berggreen        [email protected]
2. Noel Chiappa *       [email protected]
3. Farokh Deboo         sun!iruucp!ntrlink!fjd
4. Steve Deering        [email protected]
5. Richard Fox          [email protected]
6. Keith McCloghrie     [email protected]
7. Jeff Mogul           [email protected]
8. Stephanie Price      [email protected]
9. Greg Satz            [email protected]

* Noel Chiappa attended by speaker phone.

MINUTES

This was the first meeting of the Gateway Discovery Working Group,
although it has been very active by email since it was formed on
October 27, 1989.  The meeting was held back-to-back with the first
MTU Discovery Working Group meeting.  Our thanks to Jeff Mogul and
DECWRL for hosting the meeting.

As the first item of business, Deering suggested that the group might
wish to elect a new chairperson, because of potential conflict-of-
interest on his part.  (As the designer of one of the candidate
gateway discovery protocols, he might not be sufficiently impartial.)
The attendees chose not to take him up on his suggestion.

We then reviewed the various candidate gateway discovery protocols that
had been identified and discussed on the mailing list:

 stub RIP      - using default-route-only RIP broadcasts to inform
                 hosts of gateway presence; usable by any gateway,
                 not just those using RIP as their IGP.

 cisco GDP     - a UDP-based protocol very similar in functionality
                 to the IS-discovery part of the ISO ES-IS protocol.

 ICMP-D        - Deering's proposed ICMP extensions, based on low-
                 frequency periodic multicasts by gateways (i.e.,
                 not frequent enough for timely detection of gateway
                 failure).

 ES-IS subset  - the gateway-discovery/gateway-failure-detection
                 subset of ISO 9542, with the minimum of changes
                 required to carry IP addresses in IS Hellos.

 Proxy ARP     - eliminating the need for "gateway discovery" by
                 making the gateways invisible.

 PP1           - Prindeville's proposal #1, in which an IP unicast
                 datagram is sent as a LAN multicast packet when
                 no gateway address is known, triggering a Redirect.

 PP2           - Prindeville's proposal #2, in which hosts send ICMP
                 multicast queries to locate gateways.  The proposal
                 was unclear on whether or not queries are for a
                 specific destination/TOS, or for default gateway only.
                 [It has since been clarified: the queries are for
                 specific destination&TOS.]

 X.Y.Z.1       - using a well-known address (such as address number 1
                 on every subnet) to identify the "current default
                 router".  The routers run an election algorithm to
                 decide which one answers to that address at any time.

 BOOTP         - three popular protocols used to supply hosts with
 Sun BootParam   one or more gateway addresses (along with other info)
 MIT NIP         at boot time.  Might be extended to supply gateway
                 addresses at other times.

The list was then trimmed to three candidates -- RIP, GDP, ICMP-D --
for further discussion.  The others were eliminated for the following
reasons:

 ES-IS - use of ISO packet formats unnecessarily complicates
         implementation on simple IP-only hosts; no "preference
         level" field; political hot-potato.

 Proxy ARP - if hosts don't know they are talking to a gateway, they
         won't obey Redirects; difficult for gateways to decide
         which is "best" choice; "slowest gateway wins" phenomenon.

 PP1   - difficult for gateways to decide which is "best" choice;
         Redirect implosion; duplicate delivery.

 PP2   - incomplete specification; scales poorly with large numbers
         of hosts.

 X.Y.Z.1 - won't work with existing hosts that don't time out ARP
         entries; too late to reserve a special address on all
         subnets.

 BOOTP, BootParam, NIP - not designed for dynamic, on-going discovery
         of gateway addresses; hosts might get confused on receiving
         an unsolicited, partial BOOTP broadcast; beyond charter of
         this group.

We then proceeded to identify the following pros and cons of stub RIP:

 Pro:  - already supported by many hosts and gateways.

 Con:  - uses broadcast rather than multicast.

       - is named "RIP" -- it has become politically incorrect
         to advocate the continued use of RIP.  (Possibly solved
         by giving the stub RIP subset a new name?)

       - no "holding time" field, which is important if doing
         ES-IS-style gateway failure detection.  It means that
         hosts have to have wired-in knowledge of the gateway
         broadcast rate, which would have to be 30 seconds for
         the scheme to work with existing RIP implementations.
         Unfortunately, 30 seconds is too long for reasonable
         dead gateway detection, and much shorter than needed
         for discovery only.

       - [not mentioned at the meeting, but in an earlier mail
         message: danger of stub-RIP broadcasts from non-RIP gateways
         confusing full-RIP gateways on the same wire.]

We also discussed using full RIP packets (i.e., containing per-
destination routes, rather than just default routes) for the sake
of multi-homed hosts, which have to do more than just discover
a default gateway.  By comparing routing metrics reported on
each connected subnet, a multi-homed host can decide which subnet
to use as the first hop towards a given destination.  However,
RIP is less than ideal for this application, because:

       - RIP packets do not carry Autonomous System numbers,
         which would allow hosts to know whether or not RIP
         metrics from different subnets can sensibly be compared.

       - RIP routes are per-destination only, rather than
         per-destination&TOS.

       - The RIP packet encoding for IP routes is very inefficient,
         which means that large routing tables must be split across
         more packets than necessary.

Unlike RIP, the remaining two candidates -- GDP and ICMP-D -- are
amenable to change (no need for backward compatibility).  Therefore,
rather than going through the pros and cons of each protocol, we
identified the differences between the two and agreed on a resolution
of those differences, thus coming up with the "best" of the two.
Those differences are:

 - GDP is a UDP application; ICMP-D is an ICMP extension.
   Resolution: use ICMP.  This is the logical place for this
   functionality in the IP suite.  It was recognized that it is
   generally easier to add UDP applications to an existing
   implementation than to extend ICMP, but that the need for the
   protocol to manipulate the IP default gateway list might be
   more easily met by an ICMP-level implementation in some cases.
   It was noted that, for 4.3bsd Unix and derivatives (e.g., current
   versions of SunOS and Ultrix), the required ICMP extensions can be
   implemented either inside the kernel or in a user-level process.

 - GDP uses broadcast; ICMP-D uses multicast.
   Resolution: specify the use of multicast, but recognize that some
   vendors and network administrators will use broadcast anyway, at
   least until hosts and gateways are upgraded to support multicast.
   Therefore, discourage the use of broadcast but do not forbid it
   ("SHOULD multicast").

 - GDP includes a "holding time" field; ICMP-D does not.
   Resolution: include a holding time field.  This field allows a
   gateway to control how long a host continues to believe that
   the gateway is alive, in the absence of new information; it is
   important if the protocol is to be used for gateway failure
   detection as well as gateway discovery, and is useful in any
   case.  (There is some controversy over how gateway failure
   detection ought to be done and, in order to progress the
   gateway discovery protocol, we are putting off resolution
   of that issue for now.  It is expected that this working group
   will evolve into the "black-hole detection" working group
   after it's initial charter has been satisfied.  Including the
   holding time field in the packet format will leave the options
   open for that future work.)

 - GDP allows more than one gateway address to be reported in a
   single packet; ICMP-D only allows one (the IP source address
   of the packet.
   Resolution: allow more than one gateway address.  This is NOT
   intended to allow one gateway to report other gateways' addresses
   (although it does permit such usage); it is for gateways connected
   to LANs that carry more than one IP subnet, where a gateway may
   have a different address for each subnet.  Hosts receiving the
   gateway reports must pick out only those addresses that belong
   to the same subnet as the host, and ignore the rest.

 - GDP does not carry subnet masks in its gateway reports; ICMP-D does.
   Resolution: do NOT include subnet masks.  This means that,
   before engaging in the gateway discovery protocol, a host must
   know its own mask (as well as its own address).  There are already
   several existing mechanisms for acquiring that information, e.g.,
   static configuration, BOOTP, and ICMP Mask Reply; it is expected
   that the Host Configuration Working Group will standardize on a
   mechanism for obtaining various subnet parameters, of which the
   mask is only one.

 - GDP allows for 2^16 preference levels (priorities); ICMP-D allows
   for only 8 preference levels.
   Resolution: no big deal, but 8 levels should be sufficient.
   However, there is some doubt as to the value of including
   preference levels at all.  The working group does not want to
   specify at this time how hosts shall deal with preference levels,
   but agrees to include the field for private use or possible
   consideration at a later time.

 - GDP does not specify randomization of periodic gateway reports
   (to avoid synchronized transmissions) or any mechanism to
   reduce the traffic during simultaneous boot-up by many hosts;
   ICMP-D specifies both.
   Resolution: specify randomized reporting intervals; the ICMP-D
   mechanism for replying to multiple multicast queries with a single
   multicast reply is to be suggested but not required.

Deering volunteered to revise his draft RFC to reflect these decisions,
to be ready by the February IETF meeting.

Greg Satz generously agreed to let us use his (cisco's) BSD Unix
implementation of GDP as the basis of a freely-distributable
implementation of the revised protocol.  We hope to have that ready
by the February meeting as well.

The next meeting of the Gateway Discovery Working Group will be at the
February IETF meeting in Tallahassee, Florida.  We intend to split
a single afternoon session between us and the MTU Discovery Working
Group, which has many of the same members.

You are viewing proxied material from ftp.icm.edu.pl. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.