home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1997 December
/
Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso
/
ietf
/
rdisc
/
rdisc-minutes-90feb.txt
< prev
next >
Wrap
Text File
|
1993-02-17
|
4KB
|
105 lines
CURRENT_MEETING_REPORT_
Reported by Steve Deering/Xerox Parc, from notes by Jeff Mogul and James
VanBokkelen
MINUTES
This was the second meeting of the Router Discovery (nee Gateway
Discovery) working group. Jeff Mogul served as acting chair, in
Deering's absence.
The proposed protocol from the December meeting was reviewed. The
significant features are:
o It is an ICMP extension.
o Routers periodically multicast router reports; hosts multicast
router queries at boot time only.
o Use of broadcast instead of multicast is permitted but discouraged.
o A router report does not include a subnet field.
o A router report includes a holding-time field and a
preference-level field.
o In cases where more than one subnet is assigned to the same
physical network, a router may include multiple addresses (i.e.,
one for each subnet) in a single router report.
Jeff identified the following open issues:
1. Meaning of preference levels:
Nobody seemed to know what to do with more than three levels
(primary, backup and last chance?).
Decision: use 8 or 16 bits, whatever fits in the packet format.
2. Choice of multicast period:
Noted that ES-IS uses 10 seconds; we may want slower?
3. How should router respond to query, unicast or multicast?
Mike Karels proposed that routers be allowed to attempt to avoid
unnecessary replies, substituting a single broadcast or multicast
for several unicast replies.
Decision: "keep it simple", i.e., always send unicast replies.
4. Who writes the RFC?
No volunteers, so it's still Deering's responsibility.
5. Do clients dally before sending queries?
Yes, so that if a LANful of X terminals reboot from ROM at the same
instant, they don't all hit the broadcast at the same instant.
Other issues raised:
o Use on non-broadcast media.
Dismissed as too complicated.
o Do routers dally before replying?
Someone suggested that the router dally randomly (mean time based
on pref level) to avoid overwhelming client. We argued over
1
whether the clients needed all the possible router responses right
off. However, since we don't want to invent a protocol to stop the
other N routers from responding, we realized that if we were
already going to expend the resources for N+1 packets on the wire,
we might as well try to make use of them at the client. So,
dallying seems to be wanted.
o When to query?
Drew Perkins proposed a minor shift of definitions to allow initial
query to be sent when a gateway is first needed (i.e., when first
sending to an off-subnet destination), rather than at boot time.
ATTENDEES
Ballard Bare bare%hprnd@hplabs.hp.com
Art Berggreen art@sage.acc.com
Richard Bosch probe@mit.edu
Ron Broersma ron@nosc.mil
John Cavanaugh John.Cavanaugh@StPaul.ncr.com
James R. Davin jrd@ptt.lcs.mit.edu
Farokh Deboo fjd@interlink.com
Rich Fox sytek!rfox@sun.com
Mike Karels karels@berkeley.edu
Tony Mason mason@transarc.com
Keith McCloghrie sytek!kzm@hplabs.hp.com
Bill Melohn melohn@sun.com
Jeff Mogul mogul@decwrl.dec.com
John Moy jmoy@proteon.com
Drew Perkins ddp@andrew.cmu.edu
Michael Petry petry@trantor.umd.edu
Mark Rosenstein mar@mit.edu
Tim Seaver tas@mcnc.org
Tony Staw staw@marvin.enet.dec.com
James VanBokkelen jbvb@ftp.com
John Veizades veizades@apple.com
Steve Willis swillis@wellfleet.com
John M. Wobus jmwobus@suvm.acs.syr.edu
David Paul Zimmerman dpz@convex.com
2