home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / rolc / rolc-minutes-94dec.txt < prev    next >
Text File  |  1995-02-28  |  8KB  |  198 lines
  1.  
  2. CURRENT_MEETING_REPORT_
  3.  
  4. Reported by Andrew Malis/Ascom Timeplex
  5.  
  6. Minutes of the Routing Over Large Clouds Working Group (ROLC)
  7.  
  8. There were 108 attendees, many of whom were newcomers.  The chair
  9. announced that in order to get work done, the group would focus its
  10. discussion on the current draft and not rehash earlier decisions
  11. (especially the requirements and goals).  He then presented a set of
  12. overheads to start the meeting and provide some background to
  13. first-timers.
  14.  
  15. During the presentation, Curtis Villamizar reminded the group that at
  16. the Seattle meeting, a goals and requirements document was discussed.
  17. While they have been documented in both the Seattle and Toronto minutes
  18. and proceedings, The chair invited him to write such a document.  He may
  19. do so if he has the time.
  20.  
  21.  
  22. ATM Forum Update
  23.  
  24. The working group received an ATM Forum update from Drew Perkins and
  25. Joel Halpern, direct from the previous week's ATM Forum meeting in
  26. Kyoto.
  27.  
  28. The primary news was from the Multiprotocol over ATM group.  Most of the
  29. discussion there was concerning requirements, along with some discussion
  30. of reference models.  The main agreement from the meeting was there will
  31. be one host behavior, query-response (based upon Classical IP over ATM,
  32. NHRP, and ATM Forum LAN Emulation).
  33.  
  34.  
  35. Implementation Experience Reports
  36.  
  37. The one detailed report was from Kanan Shah of NRL. She has been
  38. finishing her code and it is almost at the testing stage.  Testing will
  39. take place on the ATDnet (a large-scale OC-48 ATM testbed that rings the
  40. Washington DC area).  She plans on testing with Rob Coltun's PNNI
  41. routing code.  Dave Katz said that cisco also has an implementation
  42. under way (being developed by Bruce Cole), but was not at liberty to
  43. further discuss its status.
  44.  
  45.  
  46. Current NHRP Draft Review
  47.  
  48. Dave Katz, along with Dave Piscitello, the NHRP editors, led a detailed
  49. review of the current draft, draft-ietf-rolc-nhrp-03.txt, which had been
  50. distributed on the mailing list the previous week.  Among the major
  51. issues discussed were:
  52.  
  53.    o There has been a change in the packet format.  The MBMA family
  54.      identifier is now a 16-bit number, and can be found in ``Assigned
  55.      Numbers.''
  56.  
  57.    o The Authentication option has also been changed.  An option has
  58.      been added for MD5.
  59.  
  60.    o Curtis Villamizar brought up a question as to the semantics of the
  61.      S bit, which will be better clarified in the text.  There will be
  62.      further investigation of the usefulness of the ``S'' bit, which is
  63.      used to identify whether a potential looping scenario exists.
  64.  
  65.    o The working group needs to further investigate the usefulness of a
  66.      ``C'' bit to distinguish destinations attached directly to NBMA
  67.      fabric from those that are not, and a ``J'' bit to say ``I assert
  68.      that the destination I'm informing you of is directly reachable via
  69.      me (no intervening routers).''
  70.  
  71.    o Curtis was recognized for his contribution in Section 8.1.
  72.    
  73.    o The working group needs to improve the description of destination
  74.      masks (guidelines for constructing the mask, means by which
  75.      requester distinguishes the appropriate mask length).
  76.  
  77.    o There was discussion on ``hole punching'' in cached aggregated
  78.      destinations.
  79.  
  80.    o A discussion on options took place referencing non-optional and
  81.      optional options.  For clarification, there is an option bit that
  82.      tells the implementation what to do if it does not support
  83.      particular options.  The terminology has been changed to
  84.      ``discretionary'' and ``non-discretionary'' options.  Three of the
  85.      options have been made discretionary:  destination mask option
  86.      (Section 5.6.1); QoS option (Section 5.6.6); vendor-private
  87.      (Section 5.6.8).
  88.  
  89.    o The discussion on page 2 that suggests that NHRP obviates the need
  90.      for LISs will be revised.
  91.  
  92.    o A discussion of routing loops was led by Curtis.  The solution when
  93.      a routing loop is detected is to break the VC. The group concluded
  94.      that routing loops only occur in the router-to-router case, and
  95.      then only if routers use NHRP information to take precedence over
  96.      information learned by routing protocols.  Curtis is going to send
  97.      mail to the list on the subject.
  98.  
  99.    o The question of when you use Classical ARP and when you use NHRP
  100.      was raised.  The sequence of events will be:
  101.    
  102.       1. Only ARP servers are used as per RFC 1577.
  103.       2. NHRP is phased in:
  104.    
  105.          -  Hosts continue to register with the ARP server (until ARP
  106.             servers go away, for the benefit of non-NHRP hosts).  ARP
  107.             servers will leak registrations to NHRP servers, so NHRP
  108.             hosts do not have to register twice if they do not wish to
  109.             (but then they must agree to certain defaults, such as the
  110.             registration timeout period).  [Note that this is one way;
  111.             NHRP servers never leak information to ARP Servers.]  If
  112.             NHRP hosts wish to override these default values, then they
  113.             must also register with the NHRP server.  Explicit
  114.             registrations always take precedence over leaked
  115.             registrations.
  116.  
  117.          -  NHRP source hosts send all address resolution requests to
  118.             the NHRP server (without regard to the ``mask and match''
  119.                operation).
  120.  
  121.          -  NHRP source hosts may send ARP requests to their ARP server
  122.             if they get a NHRP NAK and the destination is in the same
  123.             LIS.
  124.  
  125.       3. NHRP servers completely replace ARP servers.  All hosts are
  126.          NHRP-capable.
  127.  
  128.    o Intermediate router operation:  If the IR is willing to set up a
  129.      direct VC to the destination, it must be willing to cache the fact
  130.      it has generated and/or forwarded the NHRP request for that address
  131.      (so that it will not generate another).  If it is not willing to
  132.      set up a VC, then it will not need to cache the fact that the
  133.      request was forwarded.
  134.  
  135.    o On a related issue, the document should adequately cover how to
  136.      restrict generation of NHRP requests (will every packet generate
  137.      one if one is already in flight, will every NHS generate a request
  138.      along the routed path, etc.).
  139.  
  140.    o Note that when a router returns an NHRP reply for its own IP
  141.      address, it should mark the S bit as originating from a host.
  142.  
  143.    o A request to the group was made for someone to help with
  144.      authentication, and Sandra Murphy of TIS volunteered to provide
  145.      assistance.
  146.  
  147.    o It was agreed that more text should be added to the document
  148.      discussing the aging of information.
  149.  
  150.    o The suggestion was made for a host implementation cookbook.
  151.  
  152.    o There was a request for volunteers who are willing to explore other
  153.      protocols in the context of NHRP. Other protocols of interest are
  154.      IPv6 and IPX. There were no volunteers in the room.  Please send
  155.      mail to the chair if you are interested.
  156.  
  157.  
  158. Dave and Dave will be producing a new revision reflecting the
  159. discussion.
  160.  
  161.  
  162. New Work Items
  163.  
  164. The Routing Area Director told the working group that a protocol
  165. analysis document, while required for protocol standardization, was
  166. probably premature at this point.  However, Kanan Shah has volunteered
  167. to begin its preparation.
  168.  
  169. Two other documents were assigned to volunteers:
  170.  
  171.  
  172.    o Protocol Applicability:  Derya Cansever.
  173.    o The NHRP MIB: Mike Patrick.  Mike will begin by compiling an
  174.      initial list of objects of ``interest'' for debugging, operational
  175.      support, tuning knobs, and so on, and sending them to the list for
  176.      review and suggestions.
  177.  
  178.  
  179. Anyone interested in helping out with these documents should contact
  180. either the authors or the chair.
  181.  
  182.  
  183. Work Plan Update
  184.  
  185.    o It was decided that the NHRP document should be submitted to the
  186.      IESG as a proposed standard following at least one more revision.
  187.      The working group has a goal of Feb.  95 submission.
  188.  
  189.    o The working group should submit the companion applicability
  190.      document to the IESG in April 95.
  191.  
  192.    o The working group should have a draft of the MIB document by April
  193.      95.
  194.  
  195.  
  196. An updated charter will be forthcoming.
  197.  
  198.