CURRENT_MEETING_REPORT_


Reported by Vince Fuller/Stanford and Philip Almquist/ Consultant

Minutes:  Tuesday, 1-May (AM)


   o TOS routing

      -  Two aspects - internal queue handling vs.  next hop choice
          * RREQ document deals primarily with later (external behavior)
      -  Number of bits:  3 currently defined for TOS, 2 other ``spare''
         bits
          * does router need to know what bits mean or can it just match
            against information available via routing protocols?
          * is TOS a hint or a requirement (more discussion later) -
            hint implies it is safe to ignore extra bits for now
          * issue:  other groups may want to use those two bits for
            other things
          * requirement:  all routers must make the same routing choices
            regarding TOS and all must implement TOS (but not all
            protocols will use) to prevent routing loops (Chair's
            statement)
          * issue:  may have to change routing protocols if the number
            of bits changes (tough)
          * quote:  ``keep your paws off those two bits'' - JNC, Area
            Director
          * DECISION: use 3 bits (problem made moot by above quote)

   o TOS semantics:

      -  hint philosophy:  deliver packets to default TOS if no match
         exists
      -  requirement philosophy:  drop packets if no TOS match exists
         (editors note:  a very long and heated discussion of these
         differing philosophies consumed most of the first part of this
         session)
      -  TOS unreachable ICMP message for "requirement" case
      -  Proteon OSPF implementation allows per-TOS metric setting on
         lines; setting to infinity and dropping on no TOS match allows
         some small amount of policy control over line usage
      -  problem:  handling of TOS unreachable message is undefined
      -  problem:  won't work if host ignores TOS unreachables (or
         falls-back automatically to default TOS)
      -  problem:  TOS bits are not defined absolutely (i.e.  in bps,
         etc.)
      -  suggestion (Satz):  two sides write up their cases; include
         both in draft document for further review (any takers?)
      -  idea:  use one of the "unused" bits to specify hint/required
         TOS
      -  Milo believes looping can occur if TOS is treated as a hint -
         need specific scenarios

                                   1






o Fragmentation

   -  Review of each option outlined in draft text:
       * option 1:  no longer needed by MTU discovery
       * option 3:  invalid, since 576 is NOT the minimum required
         MTU size
   -  if anyone has empirical evidence of a good way to do it, them
      document should discuss it; otherwise, defer to IP RFC
       * action:  talk to Jeff Mogul and Van Jacobson about their
         experiments

o Reassembly

   -  Router MUST reassemble packets destined to itself (i.e.  ICMP
      messages)
       * router is acting as host in this case, must follow HR
       * HR says must reassemble max of 576 bytes or connected
         interface MTUs
   -  Router MUST NOT reassemble packets that are forwarded
       * reassembly not possible if multiple paths exist, etc.  etc.
   -  Multicast handling
      Minimal discussion.  Steve Deering (``Mr.  Multicast'')
      volunteered to write some draft text

o TTL

   -  Long discussion about schizophrenic use of TTL as time AND hop
      count
       * TCP makes assumptions about real time of packet life vs.
         TTL handling (problem can occur with sequent number
         wraparound)
       * no implementors expect to implement use of TTL as time (fact
         of life)
       * deprecate ``SHOULD'' to ``MAY'' for decrementing TTL by time
       * include discussion of why this should be done (what TCP
         expects, etc)
   -  Handling of TTL boundary conditions:
       * TTL 0 - router MUST NOT drop packets to itself on TTL = 0
         (HR sez)
       * router MUST NOT ever send a packet with TTL = 0 (ditto)
       * router SHOULD return ICMP time exceeded if it decrements TTL
         to 0
       * router MUST NOT ``pre-discard'' packets with TTL > 0 even if
         it knows (via link-state routing, for example) how many hops
         a destination is (it breaks ``traceroute'' to do so and
         doesn't really gain much)
       * should there be some discussion of ``traceroute's''
         expectations?



                                2






Minutes:  Tuesday, 1-May (PM)

A review of writing assignments/document sections was done The following
(mostly un-written) sections were worthy of mention (mainly because no
one is doing anything about them):

7.  Routing protocols - RIP, EGP, BGP (Yakov Rekhter/IBM), OSPF

8.  Network Management Protocols - SNMP (Steve Willis/Wellfleet),
CMIP/CMOT

9.  Administrative and Policy controls, including:  filters (both
traffic and routing info), interchange between EGP's and IGP's,
preference of routes by [protocol, neighbor, network number, etc.],
conditions for default generation, etc.  (subcommittee formed and had
preliminary discussion over lunch - included Steve Willis/Wellfleet,
Philip Almquist/Consultant/Stanford, Vince Fuller/Stanford/BARRNet,
Michael Reilly/DEC, and one or two others forgotten by the editor --
they and others interested in these issues (Milo, Jeff?)  should get in
touch with the Chair ASAP)

10.  Initialization, operation, management

Appendix A - Internet-specific requirements

Appendix B - Requirements for specific uses (i.e.  regional network)


   o Multicast

      -  forwarding of multicasts is not yet required
      -  router SHOULD perform host multicast functions (per RFC1112 and
         HR)
      -  router MUST NOT pass ``letter-bomb'' multicasts (as target of
         source route)
      -  record route doesn't present a problem (according to Steve D.)
      -  multicasts should not be used as an hop in a source route
         either

   o TOS, take 2 (Yakov had a few things to say)

      -  in current Internet, virtually no use (according to NSFNet
         statistics)
      -  chicken and egg problem (Steve D.)
      -  3 bits are too coarse to be useful for policy control
      -  all routers in AS (at least) must make same routing decision on
         TOS in order to prevent loops
          * what about for paths through multiple AS's?
          * what if AS's are multi-homed?
      -  how to use in presence of sources (protocols) of routing
         information?
          * use to prefer protocol if it has exact TOS match?

                                   3






   -  opinion:  TOS 0 is default - must always exist and is used if
      no exact match
   -  opinion:  forbid setting of multiple TOS bits (``Christmas
      tree'') - enforce by treating as treating as TOS 0 (?)
   -  no definite conclusion (no surprise here!)

o Broadcast handling

   -  Directed broadcasts
       * routers MUST support, MAY provide knob to disable
       * justification:  widely used, part of IP architecture
   -  All-subnets broadcast
       * current behavior:  only sent to first subnet seen
       * Chair will make case to IESG to make it an obsolete part of
         the IP architecture (by creating a successor to RFC922)
       * consider as a SHOULD NOT - may support, but MUST provide
         knob which defaults behavior to disabled

o IP options

   -  Record route - MAY in HR, specify as MUST in RREQ
   -  Timestamp - ditto
       * long discussion about when during packet processing the
         timestamp should be added - no conclusion
       * document should state that when it happens is not defined
         and will be implementation-dependent
       * Yakov (opinion):  all routers should do timestamp at same
         point in packet processing - not much agreement from rest of
         WG
   -  Option insertion by routers
       * security option must be inserted, so it MUST be allowed
         (RFC1108)
       * what if no option space available - Martin Gross/DCA will
         address
       * are there other options that need to be inserted?
   -  non-understood options - MUST be passed unchanged
   -  source route - only one source route option may exist

o Precedence

   -  OSPF mandates that routers set precedence to Internet Control
   -  BGP - ditto
   -  issue:  may be political problems with this
   -  what about network management traffic?
   -  DCA group is working on paper describing scheme

o Martian address filtering
  MUST provide functionality and provide switch to enable/disable
  (long discussion ensued about performance impact of making it
  strictly a MUST)
o What's next?

   -  video-conference will take place in June (tentatively, Monday,
      June 11th)

                                4






-  Internet-Draft is expected after August IETF



                             5






ATTENDEES

    Richard Smith             smiddy@dss.com
    David Waitzman            djw@bbn.com
    John Wobus                jmwobus@suvm.acs.syr.edu
    Pablo Brenner
    Jonathan Wenocur          jhw@shiva.com
    Dave Forster
    Steve Willis              swillis@wellfleet.com
    Michael Reilly            reilly@nsl.dec.com
    Martin Gross              martin@protolaba.dca.mil
    Peter Vinsel              farcomp!pcv@apple.com
    Stev Knowles              stev@ftp.com
    Vince Fuller              fuller@jessica.stanford.edu
    Frank Kastenholz          kasten@interlan.interlan.com
    John Moy                  jmoy@proteon.com
    Roxanne Streeter          streeter@nsipo.arc.nasa.go
    David Miller              dtm@mitre.org
    Douglas Bagnall           bagnall_d@apollo.hp.com
    Walt Wimer                ww0n@andrew.cmu.edu
    Kanchei Loa               loa@sps.mot.com
    Yoni Malachi              yoni@cs.stanford.edu
    Karen Frisa               karen@kinetics.com
    Stepanie Price            price@mcvax!ucsbcsl.edu
    Stan Froyd                sfroyd@salt.acc.com
    John Cavanaugh            john.cavanaugh@stpaul.ncr.com
    John Veizades             veizades@apple.com
    Steven Senum              sjs@network.com
    Kannan Varadhan           kannan@oar.net
    Steven Bruniars
    Paul Tsuchiya             tsuchiya@thumper.bellcore.com
    Kathy Huber               khuber@bbn.com
    Steve Deering             deering@pescadero.stanford.edu
    Greg Satz                 satz@cisco.com
    Curtis Cox                zk0001@nhis.navy.mil
    Milo Medin                medin@nsipo.nasa.gov
    Phil Karn                 Karn@Thumper.Bellcore.Com
    Y Wang
    Keith Hogan               keith%penril@uunet.uu.net
    Richard Woundy            rwoundy@ibm.com
    Mary Youssef              mary@ibm.com
    Jim Sheridan              jsherida@ibm.com
    Dino Farinacci            dino@bridge2.3com.com
    Steve Storch              sstorch@bbn.com
    Phil Park                 ppark@bbn.com
    Sze-Ying Wuu              wuu@nisc.junc.net
    Tim Hunter                thunter@allegum.bitnet
    Steve Hubert              hubert@cac.washington.edu
    John Vollbrecht           jrv@merit.edu
    Joel Replogle             replogle@ncsa.uiuc.edu
    Paul Pomes                paul-pomes@uiuc.edu
    Drew Perkins              ddp@andrew.cmu.edu
    Stephanie Price           price@cmcvax!uscbcsl.edu


                                   6








7