CURRENT_MEETING_REPORT_


Reported by Steve Deering/Stanford

RDISC Minutes

Agenda

  o Draft Specification
     -  comments?
     -  disposition?
  o Implementations
  o Black-Hole Detection

This was the fourth meeting of the Router Discovery Working Group.

The first and dominant item on the agenda was a discussion of the (late)
July draft of the ICMP router discovery specification.  The following
improvements and changes were agreed upon:


  o Add a few sentences emphasizing that this is NOT a routing protocol
    -- hosts are expected to rely on Redirects for finding the ``best''
    first-hop router for any given destination.
  o Make it even clearer than it already is that hosts must NOT
    continuously send solicitations.
  o Add a note explaining that, even though the timing values are
    defined or configured in units of seconds, randomized intervals
    should be computed at the best available resolution of the system's
    interval timer.
  o Fill in the missing ICMP Type values with officially-allocated
    numbers.
  o Change MAX_RESPONSE_DELAY from 5 seconds to 2 seconds.
  o Change the upper bound on MaxAdvertisementInterval from (2^16 - 1)
    to 1800 seconds (30 minutes).
  o Even when a router is configured to use multicast instead of
    broadcast, it may respond to a broadcast solicitation with a
    broadcast advertisement (if not a unicast advertisement).
  o When a router performs a graceful shutdown, it should send out
    advertisements with a lifetime of 0, to flush its addresses from
    the hosts' router lists.


There was also discussion of adding an authentication field to the
Router Advertisement message.  Deering argued that such a field could be
appended to the existing message format if and when a non-null
authentication type is defined for router discovery (i.e., the absence
of an authentication field indicates ``null'' authentication.)  Noel
Chiappa was not very happy with this proposal, but said he would check
it out with the security gurus [which he subsequently did; apparently,
Deering's proposed scheme will be acceptable].

                                  1






The group then agreed that, with the above modifications, the draft
specification was ready to enter into the Internet standardization
track.  Chiappa explained the necessary steps, as follows:


  o Update the specification to incorporate the agreed changes and make
    it available as an Internet Draft as soon as possible.
  o After a one month comment period as an Internet Draft, if no
    significant problems are uncovered, submit it to the IESG with the
    group's recommendation that it be published as a Proposed Standard.
  o Operational experience with multiple, independently-developed
    implementations is generally required for advancement beyond
    Proposed Standard status.  The decision to advance to the next
    stage (Draft Standard) is up to the IAB, with advice from the IESG.


That led to the next topic on the agenda:  implementations.  Andy
Cherenson and Deering confirmed their previous commitment to generate an
implementation of the protocol to run in user space on 4.3BSD and
derived systems, perhaps starting from the source code for cisco's GDP
demon; the implementation will include both the host and the router
parts of the protocol.  John Veizades volunteered to do a Macintosh
implementation of the host part of the protocol, and said he had an
environment for testing the protocol's behavior under the simultaneous
startup scenario (a rack of Macs on a single power circuit).
Implementations for other platforms, and at the kernel level in BSD,
were solicited, but no promises were made.  The importance of getting
the major router vendors to implement the router part of the protocol
and make it available for user testing was recognized; group members
were encouraged to make that desire known to their favorite router
vendors.

We then concluded that no further meetings of the Router Discovery
Working Group would be necessary, if all goes according to plan.
(Yah!!)  We discussed the possibility of transforming into a ``Black
Hole Detection'' Working Group, and decided not to do so.  A document
addressing the wider issue of host routing, of which black hole
detection is a part, would be very valuable, but there was little
enthusiasm for forming a new Working Group for that purpose; it might be
taken up by the next incarnation of the Host Requirements Working Group,
or perhaps some individual(s) will generate a document recommending (but
not standardizing) good host routing strategies.

ACTION ITEMS


  o Deering:  Ask the Internet Assigned Numbers Authority for two new
    ICMP Types.
  o Deering:  Revise the specification as agreed at this meeting and
    submit it as an Internet Draft.  If no substantive, negative
    comments are received during a one month comment period, recommend
    the specification to the IESG as a Proposed Standard.
  o Deering and Cherenson:  Implement both the host and router parts of

                                  2






    the protocol as a user-level demon for 4.3BSD-derived systems, and
    make it available to the Working Group and the wider internet
    community for testing and validation of the protocol.
  o Veizades:  Implement the host part of the protocol for Macintosh
    and test it in an environment with many hosts on the same subnet
    (especially under the simultaneous startup scenario).
  o Everyone:  Encourage your favorite router vendor to do a prototype
    implementation of the protocol, for in-house and customer- site
    testing.


Attendees


Zorica Avramovic         [email protected]
Art Berggreen            [email protected]
Larry Brandt             [email protected]
Eric Brunner             [email protected]
Andrew Cherenson         [email protected]
Steve Deering            [email protected]
Robert Elz               [email protected]
Karen Frisa              [email protected]
Robert Gilligan          [email protected]
Tony Hain                [email protected]
Steven Hubert            [email protected]
Ole Jacobsen             [email protected]
Ken Jones                uunet!konkord!ksj
Michael Karels           [email protected]
Stev Knowles             [email protected]
Alex Koifman             [email protected]
Sam Lam
Gregory Lauer            [email protected]
John Lekashman           [email protected]
Solomon Liou             solomon%[email protected]
Yoni Malachi             [email protected]
Tony Mason               [email protected]
Paul McKenney            [email protected]
John Moy                 [email protected]
John Mullen
Stephanie Price          [email protected]
Tim Seaver               [email protected]
Deepinder Sidhu          [email protected]
Craig Smelser
Frank Solensky           [email protected]
Martha Steenstrup        [email protected]
Zaw-Sing Su              [email protected]
Paul Tsuchiya            [email protected]
John Veizades            [email protected]
Carol Ward               [email protected]
Jonathan Wenocur         [email protected]
Walter Wimer             [email protected]



                                  3

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.