home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / pktway / pktway-minutes-97aug.txt < prev   
Encoding:
Text File  |  1997-10-11  |  5.1 KB  |  125 lines
  1.      Minutes of the PktWay-WG meeting, at IETF'39, Aug-1997
  2.      ======================================================
  3.          (Reported by Marc Fidler and Mark Littlefield)
  4.  
  5. The PacketWay working group met at IETF'39 in Munich, Germany on
  6. Friday, August 15.  The list of attendees is attached.
  7.  
  8. Danny Cohen opened the meeting by asking all attendees introduce
  9. themselves and provide their background.
  10.  
  11. Danny next presented an overview of PacketWay and the meeting agenda that
  12. included:
  13.         Status of the documents)
  14.         PktWay and SRVLOC
  15.         Interoperability testing
  16.         MPI over PktWay
  17.  
  18. Thomas Narten (AD-INT) iterated the need to accelerate the work on the
  19. various documents, which are the expected delivery of the PktWay-WG.
  20. Thomas also provided much needed guidance about various aspects of the
  21. required work.
  22.  
  23. A number of document action items were discussed.  The PacketWay
  24. specification is now split into multiple documents:
  25.  
  26. 1. EEP The goal is to finish editing the document by the end of
  27.    the month and submit for proposed standard status by the end of
  28.    September, including a two-weeks last-call period.
  29.  
  30.    The EEP handling of destination-designation (using Hoffman Coding)
  31.    has to be better explained than the way it is in the current document.
  32.  
  33.    The EEP document will have a new section about address assignment,
  34.    which will be a recommendation, not a part of the PktWay standard
  35.     (just as IP address assignment is NOT a part of RFC0791).
  36.  
  37. 2. The enumeration appendix will be removed into a separate document,
  38.    to be eventually maintained by IANA.
  39.  
  40. 3. RRP    This document will be split into three documents:
  41.     a. Basic RRP
  42.     b. Capability handling
  43.     c. Dynamic routing table exchange
  44.  
  45.    The enumeration appendix will be removed from the RRP document and a 
  46.    separate document created as mentioned above).
  47.  
  48.    The goal is to submit the RRP documents for proposed standard status
  49.    by the December IETF meeting.
  50.  
  51. Marc Fidler and Robert George suggested to add to the PktWay standard
  52. also a "compressed header" of 8B only.  The consensus was that such a
  53. compressed PacketWay header should be proposed in a separate document
  54. (probably as a new version of the EEP).
  55.  
  56. Robert George proposed a certain format for the "compressed header"
  57. which he will circulate soon via a message to the mailing list.
  58.  
  59. The following milestones were judged by the working group as realistic:
  60.  
  61.     Aug-97  EEP interoperability demo (done, between MSU and LMMS)
  62.  
  63.     Sep-97  Submit the updated EEP Internet-Draft as a Proposed-Standard
  64.  
  65.     Sep-97  Submit the RRP specification as an Internet-Draft
  66.  
  67.     Oct-97  Demo test interoperability of the RRP
  68.  
  69.     Nov-97  Submit the updated RRP as a Proposed-Standard
  70.  
  71.     Dec-97  (IETF-DC) Submit initial specification of the PktWay REDAP
  72.             (Resource Discovery and Allocation Protocol) as an
  73.         Internet-Draft  
  74.  
  75.     Mar-98  Demo the PktWay REDAP
  76.  
  77.     Apr-98  Submit the updated REDAP as a Proposed-Standard
  78.  
  79.  
  80. Danny reported about the differences between SRVLOC and the way PktWay
  81. handles CAPAbilities.  In spite of the differences, some coordination is
  82. planned between the two working groups.  PktWay will add to its
  83. capabilities a SRVLOC-server, and some effort will be made to unify the
  84. capabilities code.  Danny will work on it with Erik Guttman of SUN, the
  85. co-chair of the SRVLOC-WG.
  86.  
  87. Robert George gave a presentation on PacketWay interoperability testing
  88. between Mississippi State University and Sanders.  Successful testing of
  89. level A (EEP) fields was outlined.  The implementations of MSU and LMMS
  90. not only were independent, but also use different computing models, as
  91. MSU maximizes the share of the host in implementing PktWay, whereas LMMS
  92. minimizes it, pushing tasks to the network interface processors.
  93.  
  94. This test covered most of the EEP features, but not all.  Among the
  95. features that were not tested yet are the endianness field, padding
  96. length, symbols, and priority.
  97.  
  98. The interoperability test was very successful.
  99.  
  100. Robert then presented a specific proposal for a compressed PktWay
  101. header.  The header was 8 bytes in length as opposed to the 16 byte
  102. EEP header.  It was requested that this header be sent to the PacketWay
  103. reflector to solicit comments from interested parties.
  104.  
  105. Robert also mentioned that the working group plans to commence RRP
  106. interoperability testing by October.
  107.  
  108. Since Robert already described the interoperability tests conducted with
  109. LMMS, Marc Fidler (of LMMS) did not deliver the presentation that he
  110. prepared of the same tests.  Marc reiterated the need to clean up the
  111. PktWay documents.
  112.  
  113. Shane Hebert gave a presentation dealing with the commercial need for
  114. PacketWay.  He detailed MPI-Software-Technology's desire for PacketWay, 
  115. along with the value of an IETF standardization for PacketWay.
  116.  
  117. In summary, Danny reiterated the need to push the EEP document through
  118. editing, while, in the process, work on the RRP documents.
  119.  
  120. All were encouraged to use the mailing list (the "PktWay-reflector").
  121. Danny thought that something was broken with the current reflector.
  122. He apologized for it, and promised to get it fixed soon.
  123.  
  124. ******************************************************************************
  125.