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