home *** CD-ROM | disk | FTP | other *** search
-
-
- 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
-