home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / rreq / rreq-minutes-90dec.txt < prev    next >
Text File  |  1993-02-17  |  9KB  |  220 lines

  1.  
  2.  
  3. CURRENT_MEETING_REPORT_
  4.  
  5.  
  6.  
  7. Reported by Richard Smith/Datability, Walt Wimer/CMU
  8. Tony Staw/DEC and Philip Almquist/Consultant
  9.  
  10. RREQ Minutes
  11.  
  12. The Router Requirements Working Group held a grueling but very
  13. productive series of meetings in Boulder.  Although the Link Layer
  14. Requirements document is unfortunately on hold, we are on target to
  15. complete the Router Requirements document on schedule, after the March
  16. IETF Meeting.  The Chair would particularly like to thank the note
  17. takers (Richard Smith, Walt Wimer, and Tony Staw) and those hardy souls
  18. who attended all of the sessions.
  19.  
  20. On Monday afternoon, the Chair conducted a brief orientation session,
  21. intended primarily for those who would be attending a Router
  22. Requirements meeting for the first time.  Also in attendance were
  23. several long-standing Working Group participants (who helped answer the
  24. hard questions) and a number of people who were just generally
  25. interested in learning more about the Router Requirements effort.
  26.  
  27. Tuesday morning was devoted to careful review of the first part of the
  28. (then current) Router Requirements draft (rreq/rreq.doc.v6, available
  29. via anonymous FTP from Jessica.Stanford.EDU). The most notable issues
  30. raised were:
  31.  
  32.  
  33.    oConformance:  There is substantial concern in at least a few
  34.     quarters that MUST and SHOULD don't mean the same thing in Router
  35.     Requirements as they do in Host Requirements, since Router
  36.     Requirements explicitly allows conformant systems to have
  37.     configuration options which allow them to be configured to act in a
  38.     non-conformant manner (Host Requirements is silent on this topic).
  39.     Purists thought that this is a terrible idea, while most vendors
  40.     insisted that this is necessary if vendors are expected to produce
  41.     conformant products.  Consensus was not reached on any changes.
  42.  
  43.    oFragmentation:  There was prolonged debate on the details of how
  44.     fragmentation should be done.  The underlying issue was a tradeoff
  45.     between maximizing router performance and maximizing the likelihood
  46.     that an end system whose network interface has inadequate buffering
  47.     will be able to successfully reassemble.  It was finally resolved
  48.     to allow implementors to make that tradeoff however they saw fit.
  49.  
  50.  
  51. Wednesday morning session was divided among several activities.  Most of
  52.  
  53.                                 1
  54.  
  55.  
  56.  
  57.  
  58.  
  59.  
  60. the session was devoted to:
  61.  
  62.  
  63.    oCoordination with the Security Area:  Steve Crocker (IETF Security
  64.     Area Director) gave a brief presentation describing the IETF
  65.     Security Area and his views on the overlap between routers and
  66.     security.  This provoked some lively discussion of the issues.
  67.     Steve also announced that he has asked Mike StJohns to undertake
  68.     ongoing liason between the Security Area and the Router
  69.     Requirements Working Group.
  70.  
  71.    oDiscussion of Route Lookup Algorithms:  We discussed the (then
  72.     current) draft of a paper called ``Ruminations on the Next Hop'' by
  73.     Philip Almquist (rreq/rparadigm.psf.v1, available via anonymous FTP
  74.     from Jessica.Stanford.EDU). This paper is concerned primarily with
  75.     how a router which is simultaneously running more than one routing
  76.     protocol (or multiple instances of a single routing protocol) might
  77.     decide how to route packets.  The results of this discussion will
  78.     be reflected in a revised version of the paper, planned for early
  79.     1991.
  80.  
  81.  
  82. Noel Chiappa, Our IETF Area Director, asked us to spend the rest of the
  83. Wednesday session discussing a couple of issues of interest to the IESG:
  84.  
  85.  
  86.    oIGP Standards:  Most of the group felt that the IESG's stated
  87.     prerequisite for making a choice (significant operational
  88.     experience with at least one of the candidate protocols) had been
  89.     met.  Although neither has been tested in a truly large and complex
  90.     network, it is unreasonable to expect that a remedy will be found
  91.     that any time soon, given that today's networks have been designed
  92.     to be topologically simple enough to work (at least marginally
  93.     well) using the older protocols.  A clear majority of those
  94.     present, including all who had operational OSPF networks, felt that
  95.     it should be recommended to the IESG that OSPF be chosen as the
  96.     Internet standard IGP. However, Dual IS-IS also had some vocal
  97.     support, as did the view that routers should implement both OSPF
  98.     and Dual IS-IS. Despite the disagreements over the protocols, there
  99.     seemed to be general agreement that resolution of this issue by the
  100.     IAB is an important prerequisite for completion of Router
  101.     Requirements.  The issue is far too critical to interoperability to
  102.     be ignored by any useful router standard.
  103.  
  104.    oSize and Semantics of the IP TOS Header Field:  We decided to
  105.     recommend to the IESG that TOS ought to be a four bit field,
  106.     comprising the three bits defined in RFC-791 and the adjacent bit
  107.     which is defined as reserved in RFC-791 but as part of the TOS in
  108.     RFC-1122.  This bit would be defined as ``minimize (monetary)
  109.     cost''.  The remaining bit added to TOS by RFC-1122 would revert to
  110.     being reserved.  The meaning of a TOS field in which more than a
  111.  
  112.                                 2
  113.  
  114.  
  115.  
  116.  
  117.  
  118.  
  119.     single bit was set was left ``for further study''.
  120.  
  121.  
  122. Thursday morning and Thursday evening were consumed by a careful review
  123. of the remainder of the Router Requirements draft.  Major topics
  124. included:
  125.  
  126.  
  127.    oThe Operations And Maintenance Chapter:  There was some debate
  128.     about how appropriate it was for the standard to make requirements
  129.     about ``non-protocol'' issues as diagnostics, provisions for out of
  130.     band access, and loading and dumping of software.  For the most
  131.     part it was mostly concluded that it was quite appropriate, though
  132.     in some cases it was decided to water down the requirements
  133.     proposed in the draft.
  134.  
  135.    oThe Routing Protocols Chapter:  Although this chapter generated
  136.     little heated debate, considerable time was spent examining it
  137.     carefully and noting places where it needs additional fleshing out.
  138.     It was particularly noted (but also noted that the group was were
  139.     too tired to resolve just then) that it was difficult to understand
  140.     the ``right'' way to leak routing information between routing
  141.     protocols.
  142.  
  143.    oRedirects and Destination Unreachables:  There were long
  144.     discussions about when it was appropriate to generate several of
  145.     the classes of ICMP Unreachable messages.  There was also a related
  146.     debate about whether it is ever appropriate to generate the various
  147.     network (as opposed to host) forms of Unreachables and Redirects.
  148.     The answer to the latter question turned out to be no, since only
  149.     nonconformant hosts treat the two forms differently.
  150.  
  151.  
  152. Attendees
  153.  
  154. Philip Almquist         almquist@jessica.stanford.edu
  155. William Barns           barns@gateway.mitre.org
  156. Ronald Broersma         ron@nosc.mil
  157. Stewart Bryant          bryant@enet.dec.com
  158. Duane Butler            dmb@network.com
  159. Ross Callon             callon@bigfut.enet.dec.com
  160. Robert Collet  /pn=robert.d.collet/o=us.sprint/admd=telemail/c=us/@sprint. com
  161. Steve Crocker           crocker@tis.com
  162. Steve Deering           deering@xerox.com
  163. Kurt Dobbins            dobbins@ctron.com
  164. Avri Doria              avri@clearpoint.com
  165. James Dray              dray@st1.ncsl.nist.gov
  166. Dino Farinacci          dino@esd.3com.com
  167. Jeffrey Fitzgerald      jjf@fibercom.com
  168. Jeff Forys              forys@cs.utah.edu
  169.  
  170.                                 3
  171.  
  172.  
  173.  
  174.  
  175.  
  176.  
  177. Vince Fuller            vaf@Standford.EDU
  178. James Galvin            galvin@tis.com
  179. Martin Gross            gross@polaris.dca.mil
  180. Chris Gunner            gunner@osicwg.enet.dec.com
  181. Jack Hahn              hahn@umd5.umd.edu
  182. Ken Hibbard             hibbard@xylogics.com
  183. Jeffrey Honig           jch@devvax.tn.cornell.edu
  184. Kathleen Huber          khuber@bbn.com
  185. Joel Jacobs             jdj@mitre.org
  186. Ole Jacobsen            ole@csli.stanford.edu
  187. Harold Jones            hjones@nac.dec.com
  188. Frank Kastenholz        kasten@interlan.com
  189. Tom Kessler             kessler@sun.com
  190. Stev Knowles            stev@ftp.com
  191. Alex Koifman            akoifman@bbn.com
  192. William Kutz            Kutz@dockmaster.ncsc.mil
  193. John Lekashman          lekash@nas.nasa.gov
  194. Mark Leon              leon@nsipo.arc.nasa.gov
  195. Joshua Littlefield      josh@cayman.com
  196. Gary Malkin             gmalkin@ftp.com
  197. Donald Merritt          don@brl.mil
  198. James Mostek            mostek@cray.com
  199. Brad Parker             brad@cayman.com
  200. Michael Reilly          reilly@nsl.dec.com
  201. Yakov Rekhter           yakov@ibm.com
  202. Ken Schroder            schroder@bbn.com
  203. John Seligson           farcomp!johnsel@apple.com
  204. Keith Sklower           sklower@okeeffe.berkeley.edu
  205. Richard Smith           smiddy@pluto.dss.com
  206. Michael St.  Johns      stjohns@umd5.umd.edu
  207. Tony Staw              staw@marvin.enet.dec.com
  208. Roxanne Streeter        streeter@nsipo.nasa.gov
  209. Osamu Takada            takada@sdl.hitachi.co.jp
  210. Glenn Trewitt           trewitt@nsl.pa.dec.com
  211. Jonathan Wenocur        jhw@shiva.com
  212. Walter Wimer            walter.wimer@andrew.cmu.edu
  213. Cathy Wittbrodt         cjw@nersc.gov
  214. Richard Woundy          rwoundy@ibm.com
  215. Fei Xu                 fei@tdd.sj.nec.com
  216.  
  217.  
  218.  
  219.                                 4
  220.