CURRENT_MEETING_REPORT_



Reported by Richard Smith/Datability, Walt Wimer/CMU
Tony Staw/DEC and Philip Almquist/Consultant

RREQ Minutes

The Router Requirements Working Group held a grueling but very
productive series of meetings in Boulder.  Although the Link Layer
Requirements document is unfortunately on hold, we are on target to
complete the Router Requirements document on schedule, after the March
IETF Meeting.  The Chair would particularly like to thank the note
takers (Richard Smith, Walt Wimer, and Tony Staw) and those hardy souls
who attended all of the sessions.

On Monday afternoon, the Chair conducted a brief orientation session,
intended primarily for those who would be attending a Router
Requirements meeting for the first time.  Also in attendance were
several long-standing Working Group participants (who helped answer the
hard questions) and a number of people who were just generally
interested in learning more about the Router Requirements effort.

Tuesday morning was devoted to careful review of the first part of the
(then current) Router Requirements draft (rreq/rreq.doc.v6, available
via anonymous FTP from Jessica.Stanford.EDU). The most notable issues
raised were:


   oConformance:  There is substantial concern in at least a few
    quarters that MUST and SHOULD don't mean the same thing in Router
    Requirements as they do in Host Requirements, since Router
    Requirements explicitly allows conformant systems to have
    configuration options which allow them to be configured to act in a
    non-conformant manner (Host Requirements is silent on this topic).
    Purists thought that this is a terrible idea, while most vendors
    insisted that this is necessary if vendors are expected to produce
    conformant products.  Consensus was not reached on any changes.

   oFragmentation:  There was prolonged debate on the details of how
    fragmentation should be done.  The underlying issue was a tradeoff
    between maximizing router performance and maximizing the likelihood
    that an end system whose network interface has inadequate buffering
    will be able to successfully reassemble.  It was finally resolved
    to allow implementors to make that tradeoff however they saw fit.


Wednesday morning session was divided among several activities.  Most of

                                1






the session was devoted to:


   oCoordination with the Security Area:  Steve Crocker (IETF Security
    Area Director) gave a brief presentation describing the IETF
    Security Area and his views on the overlap between routers and
    security.  This provoked some lively discussion of the issues.
    Steve also announced that he has asked Mike StJohns to undertake
    ongoing liason between the Security Area and the Router
    Requirements Working Group.

   oDiscussion of Route Lookup Algorithms:  We discussed the (then
    current) draft of a paper called ``Ruminations on the Next Hop'' by
    Philip Almquist (rreq/rparadigm.psf.v1, available via anonymous FTP
    from Jessica.Stanford.EDU). This paper is concerned primarily with
    how a router which is simultaneously running more than one routing
    protocol (or multiple instances of a single routing protocol) might
    decide how to route packets.  The results of this discussion will
    be reflected in a revised version of the paper, planned for early
    1991.


Noel Chiappa, Our IETF Area Director, asked us to spend the rest of the
Wednesday session discussing a couple of issues of interest to the IESG:


   oIGP Standards:  Most of the group felt that the IESG's stated
    prerequisite for making a choice (significant operational
    experience with at least one of the candidate protocols) had been
    met.  Although neither has been tested in a truly large and complex
    network, it is unreasonable to expect that a remedy will be found
    that any time soon, given that today's networks have been designed
    to be topologically simple enough to work (at least marginally
    well) using the older protocols.  A clear majority of those
    present, including all who had operational OSPF networks, felt that
    it should be recommended to the IESG that OSPF be chosen as the
    Internet standard IGP. However, Dual IS-IS also had some vocal
    support, as did the view that routers should implement both OSPF
    and Dual IS-IS. Despite the disagreements over the protocols, there
    seemed to be general agreement that resolution of this issue by the
    IAB is an important prerequisite for completion of Router
    Requirements.  The issue is far too critical to interoperability to
    be ignored by any useful router standard.

   oSize and Semantics of the IP TOS Header Field:  We decided to
    recommend to the IESG that TOS ought to be a four bit field,
    comprising the three bits defined in RFC-791 and the adjacent bit
    which is defined as reserved in RFC-791 but as part of the TOS in
    RFC-1122.  This bit would be defined as ``minimize (monetary)
    cost''.  The remaining bit added to TOS by RFC-1122 would revert to
    being reserved.  The meaning of a TOS field in which more than a

                                2






    single bit was set was left ``for further study''.


Thursday morning and Thursday evening were consumed by a careful review
of the remainder of the Router Requirements draft.  Major topics
included:


   oThe Operations And Maintenance Chapter:  There was some debate
    about how appropriate it was for the standard to make requirements
    about ``non-protocol'' issues as diagnostics, provisions for out of
    band access, and loading and dumping of software.  For the most
    part it was mostly concluded that it was quite appropriate, though
    in some cases it was decided to water down the requirements
    proposed in the draft.

   oThe Routing Protocols Chapter:  Although this chapter generated
    little heated debate, considerable time was spent examining it
    carefully and noting places where it needs additional fleshing out.
    It was particularly noted (but also noted that the group was were
    too tired to resolve just then) that it was difficult to understand
    the ``right'' way to leak routing information between routing
    protocols.

   oRedirects and Destination Unreachables:  There were long
    discussions about when it was appropriate to generate several of
    the classes of ICMP Unreachable messages.  There was also a related
    debate about whether it is ever appropriate to generate the various
    network (as opposed to host) forms of Unreachables and Redirects.
    The answer to the latter question turned out to be no, since only
    nonconformant hosts treat the two forms differently.


Attendees

Philip Almquist         almquist@jessica.stanford.edu
William Barns           barns@gateway.mitre.org
Ronald Broersma         ron@nosc.mil
Stewart Bryant          bryant@enet.dec.com
Duane Butler            dmb@network.com
Ross Callon             callon@bigfut.enet.dec.com
Robert Collet  /pn=robert.d.collet/o=us.sprint/admd=telemail/c=us/@sprint. com
Steve Crocker           crocker@tis.com
Steve Deering           deering@xerox.com
Kurt Dobbins            dobbins@ctron.com
Avri Doria              avri@clearpoint.com
James Dray              dray@st1.ncsl.nist.gov
Dino Farinacci          dino@esd.3com.com
Jeffrey Fitzgerald      jjf@fibercom.com
Jeff Forys              forys@cs.utah.edu

                                3






Vince Fuller            vaf@Standford.EDU
James Galvin            galvin@tis.com
Martin Gross            gross@polaris.dca.mil
Chris Gunner            gunner@osicwg.enet.dec.com
Jack Hahn              hahn@umd5.umd.edu
Ken Hibbard             hibbard@xylogics.com
Jeffrey Honig           jch@devvax.tn.cornell.edu
Kathleen Huber          khuber@bbn.com
Joel Jacobs             jdj@mitre.org
Ole Jacobsen            ole@csli.stanford.edu
Harold Jones            hjones@nac.dec.com
Frank Kastenholz        kasten@interlan.com
Tom Kessler             kessler@sun.com
Stev Knowles            stev@ftp.com
Alex Koifman            akoifman@bbn.com
William Kutz            Kutz@dockmaster.ncsc.mil
John Lekashman          lekash@nas.nasa.gov
Mark Leon              leon@nsipo.arc.nasa.gov
Joshua Littlefield      josh@cayman.com
Gary Malkin             gmalkin@ftp.com
Donald Merritt          don@brl.mil
James Mostek            mostek@cray.com
Brad Parker             brad@cayman.com
Michael Reilly          reilly@nsl.dec.com
Yakov Rekhter           yakov@ibm.com
Ken Schroder            schroder@bbn.com
John Seligson           farcomp!johnsel@apple.com
Keith Sklower           sklower@okeeffe.berkeley.edu
Richard Smith           smiddy@pluto.dss.com
Michael St.  Johns      stjohns@umd5.umd.edu
Tony Staw              staw@marvin.enet.dec.com
Roxanne Streeter        streeter@nsipo.nasa.gov
Osamu Takada            takada@sdl.hitachi.co.jp
Glenn Trewitt           trewitt@nsl.pa.dec.com
Jonathan Wenocur        jhw@shiva.com
Walter Wimer            walter.wimer@andrew.cmu.edu
Cathy Wittbrodt         cjw@nersc.gov
Richard Woundy          rwoundy@ibm.com
Fei Xu                 fei@tdd.sj.nec.com



                                4