home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / rolc / rolc-minutes-95jul.txt < prev    next >
Text File  |  1995-10-18  |  11KB  |  262 lines
  1.  
  2. CURRENT_MEETING_REPORT_
  3.  
  4. Reported by Greg Ruth/GTE Laboratories and
  5. Andrew Malis/Ascom Nexion
  6.  
  7. Minutes of the Routing Over Large Clouds Working Group (ROLC)
  8.  
  9. These minutes were reported by Greg Ruth and Andrew Malis with
  10. assistance from David Horton.
  11.  
  12. The ROLC Working Group met in one session at the 33rd IETF. There were
  13. 87 attendees.
  14.  
  15.  
  16. Agenda
  17.  
  18.    o Agenda bashing
  19.    o Classical IP over ATM update
  20.    o ATM Forum/MPOA update
  21.    o NARP and NHRP implementation experience
  22.    o NHRP specification and open issues (draft-ietf-rolc-nhrp-04.txt)
  23.    o Applicability Statement (draft-ietf-rolc-nhrp-appl-II.txt)
  24.    o Protocol Analysis Document
  25.    o NHRP MIB (draft-ietf-rolc-nhrp-mib-00.txt)
  26.    o Status and workplan
  27.  
  28.  
  29. Classical IP over ATM Update
  30.  
  31. Mark Laubach is updating the ``Classical IP and ARP over ATM'' RFC, and
  32. plans to have a new draft out by 1 August.  A change in that document is
  33. that NHRP will be used as a fallback if there is no answer to the ATMARP
  34. request.  The implication of this is that he needs an NHRP RFC to refer
  35. to, and he challenged the group to produce an RFC in time.
  36.  
  37.  
  38. ATM Forum/MPOA Update
  39.  
  40. Joel Halpern gave a brief update on recent progress at the ATM Forum's
  41. MPOA (MultiProtocol Over ATM) SWG, chaired by George Swallow.  Joel
  42. described the MPOA effort as closely paralleling the NHRP effort, but
  43. intended to be protocol independent supporting IP, IPX, DECNET-IV,
  44. Appletalk, etc.  At the June 1995 meeting a baseline document was
  45. adopted as the basis for further development.  The ATM Forum invites
  46. IETFers (and the world at large) to review this document and comment.
  47. There is a mutual desire to bring ROLC and MPOA standards into closer
  48. alignment with one another, the major current difference being NHRP's
  49. encapsulation in IP headers.
  50.  
  51. The ATM Forum has provided public access to a few ATMF documents by the
  52. following means:
  53.  
  54.  
  55.    o Web site:  http://atmforum.com
  56.  
  57.    o Anonymous FTP from ftp.atmforum.com
  58.      pub/contributions/atm94-0471.ps (P-NNI)
  59.      pub/contributions/atm95-0824.ps or .txt (MPOA)
  60.  
  61.  
  62. It was recommended that you read the postscript version of the MPOA
  63. document.
  64.  
  65. Two mailing lists will be set up to discuss the above documents with the
  66. public:
  67.  
  68.  
  69.    o x-pnni@atmforum.com
  70.    o x-mpoa@atmforum.com
  71.  
  72.  
  73. To register with either list, send a traditional subscription request to
  74. the -request mailbox.  (Note:  as of 1 August, these lists were not yet
  75. operational.)
  76.  
  77.  
  78. NARP and NHRP Implementation Experience
  79.  
  80. No NARP implementation experience was reported.
  81.  
  82. The chair reported that Ascom Nexion has an implementation in progress.
  83.  
  84. Bruce Cole (Cisco) reported that he has an NHRP implementation now
  85. shipping.  Support for purge messages has been added, no support for
  86. router-to-router, no real customer use yet.  The implementation will be
  87. updated to reflect changes in the specification.
  88.  
  89. David Horton (Centre for Information Technology Research, University of
  90. Queensland) presented some overheads concerning his implementation.  To
  91. summarize, it implements both the NHRP client (NHC) and server (NHS) in
  92. the same device, and currently uses different protocol numbers to
  93. identify each.  The server handles multiple LISs, includes an SNMP agent
  94. for monitoring, does not include server-server forwarding (yet), does
  95. support purge, and is SunOS-based.  His future plans include one
  96. protocol number with the NHC and NHS choosing which packets to ignore
  97. when both receive, forwarding between multiple NHSs, extensions, SNMP
  98. R/W for configuration, and an NHC SNMP agent.
  99.  
  100.  
  101. NHRP Specification and Open Issues
  102.  
  103. The working group next discussed some NHRP open issues from the mailing
  104. list.
  105.  
  106.  0. Remove router-to-router parts of the specification from the NHRP
  107.     document.  Consensus was to allow all ``safe'' router-to-router
  108.     cases to remain and reserve treatment of the rest to another
  109.     document.  This way the NHRP document (now referred to as NHRP
  110.     Version 1) can go forward.  Internet-Drafts dealing with the full
  111.     router-router case were solicited for the Dallas meeting.  The safe
  112.     cases are those described in the NHRP specification as having the
  113.     ``stable'' (B) bit set.
  114.  
  115.  1. How should a client and server behind the same ATM address be
  116.     distinguished?  Three possible solutions are:  a) give them
  117.     different IP addresses; b) assign each different protocol numbers;
  118.     c) let them sort out incoming NHRP messages between themselves.
  119.     The consensus was that this is an implementation issue (it does not
  120.     affect interoperability), and should not be included in the
  121.     protocol specification.
  122.  
  123.  2. Include destination address in Purge requests.  Agreed.
  124.  
  125.  3. Code Responder Address Extension and Prefix Extension consistently.
  126.     Agreed.  The Prefix Extension is now coded as a mask rather than an
  127.     integer prefix length.
  128.  
  129.  4. Add an ``Invalid Extension'' error code (9).  Agreed.
  130.  
  131.  5. Allow clients to send Purge Requests to servers (e.g.  if the
  132.     client is about to go down).  Agreed.
  133.  
  134.  6. Order extensions to facilitate parsing.  Rejected.
  135.  
  136.  7. Add an ``Invalid Reply Received'' error code (10), e.g., when no
  137.     request was sent but a reply was received.  Agreed.
  138.  
  139.  8. Should we define a format for multiple Vendor Private Extension
  140.     (VPE) entries or just allow multiple instances of VPEs.  Allow
  141.     multiple instances.
  142.  
  143.  9. Preventing the ``domino effect'' (if a datagram is forwarded along
  144.     the routed path, all the routers on the path will send NHRP
  145.     Requests for the destination address).  Various solutions were
  146.     suggested, including having intermediate routers maintain a
  147.     temporary state or requiring them not to initiate their own
  148.     requests depending on the port data comes in on, but none was a
  149.     clear win.  Since the coexistence of different solutions will not
  150.     impair interoperability, it was decided to let each implementer do
  151.     as he chooses.  The consensus was to document the problem in the
  152.     draft, list the possible solutions, and require implementors to
  153.     choose one.
  154.  
  155. 10. Request for Address Prefix.  Deferred (since this is a
  156.     router-router issue, it does not have to be resolved in this
  157.     draft.)
  158.  
  159. 11. Router-router improvements.  Deferred, for the same reason.
  160.  
  161.  
  162. The working group was asked if there were any other issues to discuss.
  163. Rob Coltun would like an NHRP request that goes to end stations, rather
  164. than the end station's NHS, so that the end station can do load sharing.
  165. For example, a file server may have multiple ATM interfaces between
  166. which it would like to spread the incoming load.  The end station would
  167. indicate whether or not it should receive requests when it registers
  168. with its NHS. Rob was asked to write this up to discuss further over the
  169. list and at the next meeting.
  170.  
  171.  
  172. Applicability Statement
  173.  
  174. Derya Cansever (GTE Laboratories) presented his latest draft of the
  175. applicability statement (draft-ietf-rolc-nhrp-appl-II.txt).  It was
  176. suggested that for now the discussion of routing looping mention that,
  177. because the NHRP Version 1 specification will only treat ``safe''
  178. router-to-router interactions, looping is not a problem for Version 1 of
  179. the protocol.  The document will continue to include the description of
  180. the problem, so that the knowledge is not lost.  It was also suggested
  181. that there should be a statement to the effect that NHRP is not, at
  182. present, appropriate for IP multicasting.
  183.  
  184.  
  185. Protocol Analysis Document
  186.  
  187. The protocol analysis document has not been released yet, and the
  188. author, Kanan Shah, was not able to attend the Stockholm meeting.  A
  189. draft is expected before the next IETF meeting.  Kanan will be attending
  190. that meeting.
  191.  
  192.  
  193. NHRP MIB
  194.  
  195. The new MIB editor, Avri Doria, was introduced to the working group.
  196. Avri has received the MIB document, along with all comments submitted to
  197. date.  He is planning to roll currently received comments into the MIB.
  198. All are encouraged to read the MIB and comments already posted to the
  199. list, and to submit comments of your own.
  200.  
  201.  
  202. Removing IP Encapsulation and Server Mode
  203.  
  204. During open discussion, Rob Coltun requested that the working group
  205. simplify NHRP, and allow it to be directly adopted by the ATM Forum MPOA
  206. group, by removing server mode and its IP encapsulation.  During the
  207. discussion, Joel Halpern described how NHRP can be transitioned into a
  208. network without server mode.  As NHRP is deployed, requests will begin
  209. to be sent to directly attached neighbors, along the routed path.  If
  210. the next hop is also NHRP-capable, the request will be properly handled;
  211. if not, it will be dropped on the floor because the receiver does not
  212. recognize the protocol type.  In that case, datagrams will simply follow
  213. the routed path as before, so nothing breaks.  Configuration is much
  214. easier than it had been for server mode.
  215.  
  216. The chair listed the necessary changes to the specification:
  217.  
  218.  
  219.    o All server mode references must be removed from the text.
  220.    o The IP encapsulation must be removed from the packet formats.
  221.    o An LLC/SNAP encapsulation is required.  The chair will send a
  222.      request to the IANA for a PID codepoint in the IANA's OUI space.
  223.  
  224.  
  225. Given the scope of these changes, the chair asked for clear consensus
  226. for this change, and it was provided by the working group.  There were
  227. no objections, including those with existing or ``in progress''
  228. implementations.  There was no support for retaining server mode.
  229.  
  230.  
  231. Work Plan
  232.  
  233. The NHRP Version 1 specification will be updated (in a timely manner)
  234. based upon the above changes, and published as -05.  Following review on
  235. the list and electronic working group consensus, it will be submitted to
  236. the Routing Area Director for IESG consideration as a Proposed Standard
  237. RFC.
  238.  
  239. Internet-Drafts on the full router-router case are solicited for
  240. discussion over the list and at the Dallas meeting.
  241.  
  242. The applicability statement and protocol analysis, when complete, will
  243. become Informational RFCs.
  244.  
  245. We plan to submit the MIB as a Proposed Standard RFC following the
  246. Dallas meeting.  The work plan in the charter will now read:
  247.  
  248.  
  249.  Jul 95  Discuss implementation experience, NHRP open issues, companion 
  250.          documents.
  251.  
  252.  Aug 95  Submit NHRP Version 1 specification to the IESG as a Proposed 
  253.          Standard following post-Stockholm revisions.
  254.  
  255.  Dec 95  Discuss router-router case.  After the Dallas meeting, submit 
  256.          the MIB to the IESG as a Proposed Standard, and Applicability 
  257.          Statement and Protocol Analysis for Version 1 as Informational RFCs.
  258.  
  259.  Mar 96  Finalize router-router case as NHRP Version 2; submit NHRP 
  260.          Version 2 as an upgrade to NHRP Version 1.
  261.  
  262.