OSI Interoperability Working Group Chairpersons: Ross Callon/DEC and Robert Hagens/U of Wisconsin CURRENT MEETING REPORT Reported by Ross Callon, Rob Hagens and Richard Colella AGENDA Monday, July 24th o Discussion and review of GOSIP V2 Tuesday, July 25th o Inter-domain routing o Intra-domain routing Wednesday, July 26th o General Meeting 1. BSD 4.4 Update 2. Review of the CLNP Echo proposal 3. Review of GOSIP comments 4. Strategies for encapsulating CLNP in DoD IP o X.500 o DEC DNS ATTENDEES 1. Abramowitz, Alyson/ala@hpindda.hp.com 2. Alberts, Charlie/charlie@banyan.banyan.com 3. Barker, Trudy/trudy@sri-nic.arpa 4. Bierbaum, Neal/bierbaum@vitalink.com 5. Blackwood, Craig/craig@hprnd.rose.hp.com 6. Brackenridge, Billy/brackenridge@isi.edu 7. Breslau, Lee/breslau@jerico.usc.edu 8. Brim, Scott/swb@devvax.tn.cornell.edu 1 9. Callon, Ross/callon@erlang.dec.com 10. Chapin, Lyman/lyman_chapin@dgc.mceo.dg.com 11. Chi, Debra/debee@sun.com 12. Colella, Richard/colella@osi3.ncsl.nist.gov 13. Collins, Mike/collins@ccc.mfecc.llnl.gov 14. Coltun, Rob/rcoltun@trantor.umd.edu 15. Deboo, Farokh/fjd@bridge2.esd.3com.com 16. Denny, Barbara/denny@sri.com 17. Doo, Way-Chi/wcd@bridge2.esd.3com.com 18. Farinacci, Dino/dino@bridge2.3com.com 19. Fedor, Mark/fedor@nisc.nyser.net 20. Fink, Bob/rlfink@lbl.gov 21. Forster, Jim/forster@cisco.com 22. Galvin, James/galvin@tis.com 23. Garcia-Luna, J. J./garcia@sri.com 24. Gary Ralls, Vicki/iruucp!sun!ntrlink!ralls 25. Gerich, Elise/epg@merit.edu 26. Gerlach, Chuck/cag@iwlcs.att.com 27. Gross, Martin/martin@protolaba.dca.mil 28. Hagens, Rob/hagens@cs.wisc.edu 29. Hollingsworth, Greg/gregh@gateway.mitre.org 30. Hytry, Tom/tlh@iwlcs.att.com 31. Ilnicki, Ski/ski 32. Jacobsen, Ole/ole@csli.stanford.edu 33. Jarza, Peggy 34. Jones, Bill/jones@nsipo.arc.nasa.gov 35. Jordt, Dan/danj@cac.washington.edu 36. Katz, Dave/dkatz@merit.edu 37. Kincl, Norman/kincl@iag.hp.com 38. Knopper, Mark/mak@merit.edu 39. Kullberg, Alan/akullberg@bbn.com 2 40. LaQuey, Tracy/tracy@emx.utexas.edu 41. Lebeck, Sue/lebeck@tandem.com 42. Lee, Young/youngl@jessica.stanford.edu 43. Lepp, Marianne/marianne@bbn.com 44. Leser, Norbert/nl@osf.org 45. Little, Mike/little@saic.com 46. Love, Paul/loveep@@sds.sdsc.edu 47. Lynch, Dan/lynch@isi.edu 48. Maas, Andy/maas@jessica.stanford.edu 49. Malkin, Gary/gmalkin@proteon.com 50. Mankin, Allison/mankin@gateway.mitre.org 51. Merritt, Don/don@brl.mil 52. Mockapetris, Paul/pvm@isi.edu 53. Mogul, Jeff/mogul@decwrl.dec.com 54. Montgomery, Doug/dougm@osi3.ncsl.nist.gov 55. Mundy, Russ/mundy@tis.com 56. Nitzan, Rebecca/nitzan@ccc.mfecc.llnl.gov 57. Ohle, Bill/ohle@osi.ncsl.nist.gov 58. Opalka, Zbigniew /zopalka@bbn.com 59. Oran, Dave/oran@oran.dec.com 60. Pak, Raylene/raylene@tardis.tymnet 61. Palmer, Howard/sun!iruucp!ntrlink!palmer 62. Pillalamarri, Shyam/shyam 63. Pugh, Jon/pugh@nmfecc.llnl.gov 64. Pugh, Rex/pugh@hprnd.rose.hp.com 65. Ramakrishnan, KK/rama 66. Reilly, Michael/reilly@atari.nac.dec.com 67. Reinstedler, Jim/jimr@ub.ubcom.com 68. Rekhter, Yakov/yakov@ibm.com 69. Replogle, Joel/replogle@ncsa.uiuc.edu 70. Reschly, Robert/reschly@brl.mil 3 71. Roberts, Mike/roberts@educom.edu 72. Roselinsky, Milt/cmcvax!milt@hub.ucsb.edu 73. Scanlan, Keely/keely@hprnd.rose.hp.com 74. Schoffstall, Martin/schoff@nisc.nyser.net 75. Schofield, Bruce/schofield@edn-vax.dca.mil 76. Sheridan, Jim/jsherida@ibm.com 77. Sklowear, Keith/sklower@okeeffe.berkeley.edu 78. Smith, Tom/toms@hprnd.rose.hp.com 79. Sollins, Karen/sollins@lcs.mit.edu 80. St. Johns, Mike/stjohns@beast.ddn.mil 81. Stahl, Mary/stahl@sri-nic.arpa 82. Steenstrup, Martha/msteenst@bbn.com 83. Stefferud, Einar/stef@nrtc.northrop.com 84. Sweeton, Jim/sweeton@merit.edu 85. Tausworthe, Bob/tozz@hpda.hp.com 86. Tharenos, Michael/tharenos@jessica.stanford.edu 87. Travis, Lance/cmt@apollo.com 88. Tsai, Howard/hst@mtuxo.att.com 89. Vance, L. Stuart/vance@tgv.com 90. Vaughan, Lynn/lynna@hprnd.rose.hp.cpm 91. Volk, Ruediger/rv@germany.eu.net 92. Wilder, Rick/rick@gateway.mitre.org 93. Youssef, Mary/mary@ibm.com MINUTES The meeting was convened by co-chairmen Ross Callon and Rob Hagens. The major issues discussed at this meeting included: GOSIP version 2, inter-domain and intra-domain routing, CLNP encapsulation, and directory services. GOSIP V2 COMMENTS (Monday) We went through the draft GOSIP version 2 document more or less front to back, and agreed on the following comments (to be submitted officially as OSIIWG comments): 4 Congestion Recovery: It was suggested that the congestion recovery mechanisms should be mandatory in GOSIP, rather than "strongly recommended". It was pointed out that there is a difference between congestion recovery and congestion avoidance, and that only the congestion recovery need be mandatory. After a brief discussion this proposal was accepted. Inclusion of CO/CL indicator in SEL part of NSAP address: Several people raised concern about the bit in the SEL part of the NSAP address which indicates whether the network service is connectionless or connection-oriented. It was explained that in some cases, in the absence of directory services, an ES which is to initiate communications may have the remote NSAP address available, but not know whether to use the connectionless or connection oriented network service. By looking at the bit in the remote NSAP address, it would know what protocol/service type to use. This was described as an interim measure. This explanation raised the level of interest from mild displeasure to serious concern. In particular, it was clear that some people were planning to write code which relied upon specific meaning in the SEL fields of remote NSAP addresses. Software written with this assumption would never be able to interact with any end system which happened to assign the wrong value to that bit of the NSAP address (such as non-Gosip OSI-compliant systems, or systems implementing future or past versions of GOSIP). We quickly agreed that this was undesirable. NSAP format: Other than the CO/CL bit in the SEL field, people were quite happy with the NSAP format. We agreed that RFC 1069 should be re-written to be compatible with GOSIP version 2.0. NSAP Assignment and Administration: There was a lengthy discussion about who was to administer NSAPs. Doug Montgomery suggested that since they were already setting up administrative procedures for the bulk of the Government, perhaps the same procedures should be used for the DoD. There was also some talk about whether the same procedures should be used for the entire Internet community, including educational institutions and government contractors. There was no agreement on this last group, except that in general there was no clear distinction between what was a government contractor and what was a private company (which would be expected to get their assignment from ANSI). Related to this 5 discussion was the issues surrounding the administration of ICD 0005 and ICD 0006. Although ICD 0006 is delegated to the DoD (and therefore, part of the Internet), many felt that all addresses should be registered under ICD 0005, and ICD 0006 left empty (or for private military use). There was also a discussion of the need for guidelines on (i) what sort of agencies should be considered an Administrative Authority; (ii) Under what conditions should specific grouping of networks be included in one domain, versus being split into several domains. We appeared to be in agreement that in many cases the specific people who are tasked to set up domain and address structures will be folks who do not fully understand the technical ramifications of these choices (such as the effect on routing). It was also suggested that commercial companies probably have the same need for information of value to clients setting up large networks. It was agreed that (i) There is a need for such guidelines; (ii) Writing these guidelines is beyond the scope of the OSIIWG, although we would like to review and comment upon any guidelines intended for the Internet; (iii) This was an important issue which should be brought to the attention of the IAB and the FRICC, but which did not result in any specific comment to GOSIP. It was agreed that it would be preferable to describe the address administration in a separate document from the NSAP address, rather than postpone re-issuance of RFC 1069 in order to include both issues in one RFC. O/R Names: We were generally in agreement that the X.400 O/R Names section in Gosip has problems. Priority Processing of PDUs: The GOSIP 2.0 spec contains a bullet item which could be interpreted to mean that in order to conform with GOSIP you HAVE to separate incoming traffic by priority before processing the header (which would seem to imply mostly processing the header to find the priority, then queueing the packet, then re-processing the header). On the other hand, it was pointed out that in some specific environments priority forwarding of packets is very important. We proposed alternate wording which we feel preserves the possibility for individual acquisition authorities to require priority handling of packets where appropriate, while correcting the possible mis-interpretation. Example of use of DoD Management Protocols: In the introductory section there is a discussion of the need to use "Tertiary" sources for protocol specifications (sources which are neither 6 standards nor proposed standards). An example was given of use of DoD management standards (designed for use with TCP/IP) for management of OSI systems. We agreed that this was a poor example, and proposed a better example (use of the ANSI MIB along with DIS version of CMIP). General: Various folks were tasked with writing up paragraphs describing each item, which Ross agreed to type up for submission to NIST. INTER-DOMAIN ROUTING (Tuesday) We had a half day for discussion of Inter-domain Routing Protocols, which was intended for two purposes: (i) For information purposes, to increase understanding of what possibilities are under development; (ii) To determine what we want to do short term in the Internet. Marianne Lepp (chair of the IETF Open Routing Working Group) gave a presentation of the inter-domain architecture on which the ORWG is working, and presented a schedule for more concrete written architectural and protocol specifications. Doug Montgomery gave a presentation of the NIST scheme, which ECMA and NIST are bringing to OSI. Finally Jacob Rehkter of IBM gave a presentation of the short-term proposal of the Interconnectivity Working Group. We then had a discussion of what to do for short term use in the Internet. Yacob Rechkter asked: "How many routing domains do we have currently in the Internet?" (obviously the answer is none). He then asked: "How many will we have in two years?" (probably not very many). He suggested that the number of domains will probably be very small for several years, and that we have much more pressing problems. So, why not just use fixed tables for now, and in a couple of years re-visit the question (with the benefit of the work of the other Internet groups working on this problem for TCP/IP). We quickly agreed on this. There ensued a brief discussion that essentially was of the question "How fixed are fixed routing tables, and what might one offer to allow remotely updating them". There was no clear conclusion. 7 INTRA-DOMAIN ROUTING (Tuesday) Dave Oran gave a presentation of the DEC/ANSI intra-domain IS-IS routing protocol, with emphasis on the changes made since the older (October 1987) version. Dave had a hard copy of the brand new updated proposal, which was sent to be copied and distributed. The new version of the ANSI IS-IS routing spec, which will be submitted to ISO in Sept. 1989 will follow, with luck, the following progression through ISO: o DP Jan, 1990 o DIS Oct, 1990 o IS June, 1991 GENERAL MEETING (Wednesday) BSD 4.4 STATUS REPORT A brief status report on 4.4 BSD was given by Rob Hagens. The ISODE is being ported to run over the Wisconsin lower layers. Testing of the now complete OSI stack will begin shortly. ECHO OPTION FOR ISO 8473 Two mechanisms for realizing an 8473 echo request/reply were discussed by Rob Hagens: using a SEL value to indicate that a DT pdu should be sent to an echo entity, or using a new type code in the pdu itself to distinguish a DT from an echo request/reply. The OSIIWG felt that the use of the SEL is a good short term solution. However, the new type field is the best long term solution. The echo draft (not yet public) should be edited to suggest that the SEL field be used in the short term. Concurrent to this, the new type code should be described in detail and submitted to ANSI as a work item. Finally, the source route option was discussed. Some people would like to use it in the echo-request and have it reversed in the echo-reply. Others would like it not copied from echo-request to echo-reply. Since the source route option is currently incorrectly specified in ISO 8473, it was suggested that the best approach is to discourage use of a source route option when using an echo facility. ENCAPSULATION The OSIIWG agreed that a production encapsulation method was a necessary transition aid. EON, as specified in RFC 1070 is insufficient. 8 The act of wrapping and unwrapping CLNP in DoD IP should be performed by gateways. The CLNP should run in native mode as far as possible. There are actually 3 sub-problems: a) The wrapper/unwrappers must know of each other of the purpose of network layer routing. b) The wrapper (when acting as a SNDCP for CLNP) must obtain the mapping from NSAP address to SNPA (DoD IP address) of the unwrapper. c) It is not clear if the CLNP packet should be placed directly into the DoD IP data field, or if a small header should be used. The header might contain the NSAP/DoD IP address mapping of the wrapper. The general consensus was not to include this extra header. The routing problem (a) is similar to that experienced when X.25 is used as an COSNS for CLNP. The group looked to the ANSI IS-IS proposal for support. The IS-IS solution does not provide a magic solution. A general opinion of the group was that static tables should be used. However, opinions varied considerably. The question really becomes: how static is static? Could we utilize a network management protocol to adjust static tables? This topic requires more discussion. The method of mapping the NSAP to DoD IP address (b) was not determined. Again, the ANSI IS-IS spec. was not helpful. Possibilities include: embed the DoD IP address in the NSAP address, use static tables, use an SNPA server. This topic requires more discussion. DIRECTORY SERVICES AND NAMING Dave Oran gave a presentation on the DEC DNS naming scheme. Karen Sollins gave an ad hoc presentation on the X.500 name service. 9