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