CURRENT_MEETING_REPORT_ Reported by Sue Hares/Merit, David Bolen/ANS and Dave Miller/MITRE Minutes of the Network OSI Operations Working Group (NOOP) The Network OSI Operations Group met three times during the week of the San Diego IETF. The first meeting took place on Monday morning. Steve Deering presented his ideas behind his paper ``City Codes is an Alternative to Topological NSAP Allocation (RFC 1237).'' In addition, Ross Callon presented the basics of RFC 1237. Both presentations prompted a great deal of discussion. Sally Tarquinio took very detailed notes of the discussion. Due to the length of both the notes and the discussion, the notes will not be available in the Proceedings. Notes may be retrieved via anonymous ftp from merit.edu in /pub/iso/noop/notes/notes.03.16.92.am). In addition to the City Code discussion, the following topics were discussed: o Mobile Hosts o Comparison Geographical Area Code (GARP) with NAT and CNAT o GARP vs RFC 1237 o Whether asymmetric pathways are acceptable. The second NOOP session occurred on Wednesday morning at 9:00 a.m. and covered several different items. Notes were taken by David Bolen. Usage Questionnaire Sue Hares made available copies of the OSI usage questionnaire and requested that anyone involved with OSI work try to complete one. This was a copy of the same questionnaire that was previously distributed electronically. A question was raised as to why DECnet was considered different than CLNP (p. 9) - the answer was that it wasn't really, but the goal was to see if DECnet usage was pushing CLNP usage (here, DECnet really means DECnet Phase V traffic). NEARnet OSI Routing/Addressing Plan o Introduction John Curran from NEARnet (New England Academic & Research Network) made a presentation of NEARnet's OSI Plan. NEARnet is comprised of 120 members in six states, and coordinates with other New England service providers to provide service in that area. Cisco routers are used throughout NEARnets network. 1 o Address Assignment Plan When researching an address assignment plan, NEARnet found that area codes were a nice match for population density, and therefore for assignment beneath NEARnet's AAI. NEARnets final address format breakdown assumed the following limits: - Total of 16 COs per area code. - Total of 256 RDs per CO. This could be a real problem in a fairly short-term (~ two years). It is hard to gauge demand though, and NEARnet isn't the only network assigning in the New England area. CO codes are assigned to aggregate at other boundaries as well: .00-.3F = Massachusetts (.10 = 508 area code, .20 = 617, etc..) .40-.4F \ .50-.5F \ Assign to different states - allows room for .60-.6F / expansion according to area code. .70-.7F / .80- still some slack available for future expansion The next step is then to assign RDs logically under this scheme. The multiple aggregation points within this scheme helps to limit the routing table size. o Routing (ala RFC1237) The following points were raised with respect to routing issues under this sort of an address assignment scheme: - Routes will often have to be manually injected. - IGRP is not currently collapsing routes - hopefully newer protocols will begin to do this. - NEARnet doesn't like the fact that they have to accept all routes as it allows NEARnet's routing tables to grow without bounds. - NEARnet sees NSAP changes as a lot of work currently - thus, if a customer has already been assigned an RD, NEARnet lets the customer keep it. - NEARnet will accept any other assignments, but isn't sure what will happen with other networks - will they be as accepting as NEARnet? o Questions John brought up the general question as to what the general opinion of this plan was. Could the approach be viewed as dangerous? The following points were raised: 2 - Something has to be done, and at least this policy allows future aggregation - it's very hard to take back what we give out today. - There could be a problem if all service providers don't become as accepting as NEARnet. If routes begin to be refused, it might cause everyone to bail out to their own AAI which would create a flat address space once again. - If we are allowing entropy at all (as this plan does), then there needs to be some sort of entropy reduction in the system. A possible recourse might be the need to start charging for the announcement of a special route to other networks. A general point was made that at the moment, the whole area of addresses and assignment represents more of a controlled economy than a true market economy. Moving from one to the other is always tough. NEARnet's addressing and routing plan may be found (via anonymous ftp) in: nic.near.net:/docs/osi-routing-plan.txt or merit.edu:/pub/iso/noop/papers/nearnet.osi-routing-plan.txt John also gave credit to CICNet for their previously released OSI plan, and said that NEARnet's plan borrowed a lot from CICNet's. OSI Pilot Projects The discussion of OSI pilot projects centered around some documentation that Sue supplied describing some of the work that RARE is doing in this area. RARE has a suite of tests that they are requesting users at their sites to perform, sending them results back to a central site to be summarized. Sue was interested in whether or not their was enough interest in trying the same sort of pilot plan here in the U.S., as well as trying to get together another OSI demo for Interop East. The general consensus of the Group was that, yes, it would be useful to try the same sort of pilot project here, and that the RARE approach seemed a reasonable way to proceed. It would also be nice to see about some coordination with RARE, although mostly for inter-domain and application level than at the ES-IS and IS-IS level. The application-level portion of the RARE plan was a little weak, and may need to be augmented for our tests. A possible problem was brought up in that a number of sites have beta implementations of OSI code, and may not be able to publish the results of tests. Sue suggested that at least saying ``I've tested'' is useful, even if the exact results of the test cannot be released. NIST was brought up as an organization that was already handling some OSI testing in the same vein as what was being discussed. NIST has provided open labs and a test environment for multiple vendors to come together in order to test interoperability. There has been no automated 3 or documented test procedures followed, however - just vendor engineers running particular tests. Richard Collela will be sending some further information about this testing to the NOOP mailing list. The fundamental difference between the testing that has been performed at NIST, and the type of pilot projects being run by RARE is that the latter case involves actual end users, while the former is run by the vendors and their engineers. John Curran suggested that the request for tests be sent out to the NOOP list. While many midlevels may not run the tests themselves, they may have clients that can. Sue Hares agreed to send the test plan, and a request for volunteers to the NOOP mailing list. Document Review: (reported by Dave Miller) o TOOLS RFC Their was a brief discussion on the ``Tools'' Document and the need for tools to provide OSI ping, OSI traceroute, and OSI routing table dump utilities. The discussion then focused on what routing table information should be available via SNMP. It was noted that the document should specify a minimal set of objects as MUST requirements for this specification. For CLNS MIB objects, no one took exception to the list in the draft document. For IS-IS, the document currently states the object in very general terms. Dino Farinacci was asked to write-up a minimal list of IS-IS objects and send them to the NOOP mailing list. For IDRP, no one took exception to the list in the draft document. There was no review of objects for CMIP management at this time. o SURVEY FORM Sue Hares gave a status overview of the OSI in the Internet Survey. The plan to maintain the survey is to perform a monthly revision to incorporate any new information received. Sue also encouraged others to respond to the survey since only about ten responses have been received to date. There were a few suggestions to modify the survey (it was noted that the changes should be highlighted when new surveys are sent out): - DECnet traffic should refer to DECnet Phase V traffic. - Text should refer to RFC 1006 as opposed to a TCP/IP stack. - There should be a context section added to identify who's responding to the survey and what their role in OSI is. Cathy Wittbrodt suggested that the surveys be stored individually on-line so particular responses could be retrieved as desired. Sue agreed to do this. 4 Dave Farber suggested sending the survey out to the IETF mailing list to reach a broader community. Sue agreed to do this. o SECURITY RFC Walt Lazear gave an overview of the OSI Packet Filtering document. The document discusses the issues associated with filtering OSI by application type in the context of using packet filtering to restrict OSI connections (establishing firewalls). Walt noted that he has not received comments on the current document and solicited feedback. There was some discussion of what were the security requirements that were trying to be met. MITRE was asked if they could put together a short paper on OSI security policy to set the context for this work and to stimulate further discussion. Bill Barns volunteered himself and Walt to pursue this. o NIST IS-IS TEST LAB Rich Colella gave a quick overview of the IS-IS test lab established at NIST. Two Open Lab sessions have been conducted to date to perform vendor interoperability testing. A report of the router testing is being prepared. Rich agreed to get a copy of the completed report sent to the NOOP list. The third NOOP sessions took place during the 7:00 p.m. session on Wednesday, March 18th, and was devoted to discussion of the IDRP for IP document. A new working group will be formed to discuss the IDRP issues. Detailed notes are available via ftp, cd ietf, get noop-minutes-92mar.txt). NOTES>>>>>>> IDRP for IP IDRP can be found in merit.edu:/pub/iso/idrp.ps IDRP for IP will be submitted as an Internet Draft by April 1st. 1. BISPDU (IDRP packet) in IP packet with unique protocol ID. IDRP provides a reliable transport so TCP not needed. 2. IP addresses encoded in NLRI and NET. Current ANSI ballot proposal will allow direct encoding. This ballot proposal will be a correction on the current DIS ballot text. 3. IDRP for IP only has: o No CLNP forwarding o No IDRP GMDO for CMIP: (MIB will be part of an Internet standard. Internet is using SNMP over CLTS.) 5 4. Minimal Configuration Information needed for IDRP. o Intra-Domain ISs (routers) o Location and identity of BIS (Border routers) in Domain o IP addresses for Routing Domain (bag of networks) o Routing Domain Identifier (RDI) (New style AS) 47:0005:81:aa:aa Where if AS number needs to be expanded, the aa:aa field can go to 4 bytes. o Rib Attribute Set = null Rib Attributes identify QOS. QOS will be examined in a separate document. o Routing Domain Confederations - RDCs Routing Domain Confederations this node is a part of. o SNPAs of this node 5. IDRP compared to BGP-4. Additional Features o DIST_LIST_INCL, DIST_LIST_EXCL DIST_LIST_INCL indicates which routing domains a set of routing information may be passed to. DIST_LIST_EXCL states this routing information may be passed to all RDs but the ones listed. o Local Preference (may be added to BGP-4) o MULT_EXIT_DISC (may be added to BGP-4) o RDC o RD Sets o IDRP has its own transport o Hierarchical Recording 6. IDRP Deployment. o Minimum configuration: 1 BIS, 1 BIS can pass to intra-domain routing. o IP Prefix goes in 1 Routing domain, not multiple. Prefix is really 1 campus or RD, not the large ``bags'' of networks that make up AS now. Attendees Andy Adams ala@merit.edu Vikas Aggarwal aggarwal@jvnc.net 6 Robert Aiken raiken@nsf.gov Steve Alexander stevea@i88.isc.com Nagaraj Arunkumar nak@3com.com Zorica Avramovic zorica@sparta.com William Barns barns@gateway.mitre.org Tony Bates tony@ean-relay.ac.uk William Biagi bbiagi@cos.com David Bolen db3l@nis.ans.net Scott Brim swb@cornell.edu J. Nevil Brownlee nevil@aukuni.ac.uz Eric Brunner brunner@practic.com Niels Brunsgaard nob@dowtyns.dk Ross Callon callon@bigfut.enet.dec.com John Chang jrc@uswest.com A. Lyman Chapin lyman@bbn.com Henry Clark henryc@oar.net Alan Clegg abc@concert.net Richard Colella colella@osi.ncsl.nist.gov Rob Coltun rcoltun@ni.umd.edu Robert Cooney cooney@wnyose.nctsw.navy.mil Curtis Cox ccox@wnyose.nctsw.navy.mil Dave Cullerot cullerot@ctron.com John Curran jcurran@bbn.com Steve Deering deering@xerox.com Kathleen Dodd kathy@gateway.mitre.org Tom Easterday tom@cic.net Dino Farinacci dino@cisco.com Stefan Fassbender stf@easi.net Peter Ford peter@lanl.gov Karen Frisa karen.frisa@andrew.cmu.edu Vince Fuller vaf@stanford.edu Eugene Geer ewg@nvuxr.bellcore.com Robert Hagens hagens@cs.wisc.edu Susan Hares skh@merit.edu Jeff Hayward j.hayward@utexas.edu Juha Heinanen juha.heinanen@datanet.tele.fi Randy Hoebelheinrich rho@rowan.lanl.gov Kathleen Huber khuber@bbn.com Bob Jeckell rrj@3com.com Barbara Jennings bjjenni@sandia.gov Dan Jordt danj@nwnet.net Dave Katz dkatz@merit.edu H. A. Kippenhan kippenhan@fndcd.fnal.gov Yoav Kluger ykluger@fibhaifa.com Deidre Kostick dck2@sabre.bellcore.com Eva Kuiper eva@hpindda.cup.hp.com John Larson jlarson@parc.xerox.com Walter Lazear lazear@gateway.mitre.org Eliot Lear lear@sgi.com Kurt Lidl lidl@sura.net Susan Lin suelin@ibm.com Tony Li tli@cisco.com Triet Lu trietl@sparta.com Gary Malkin gmalkin@xylogics.com 7 Bill Manning bmanning@rice.edu Glenn McGregor ghm@merit.edu Milo Medin medin@nsipo.nasa.gov David Miller dtm@mitre.org Henry Miller henrym@sacusr.mp.usbr.gov Greg Minshall minshall@wc.novell.com Dennis Morris morrisd@imo-uvax.dca.mil Donald Morris morris@ucar.edu Brad Passwaters bjp@sura.net David Piscitello dave@sabre.bellcore.com Jon Postel postel@isi.edu Rex Pugh pugh@hprnd.rose.hp.com Yakov Rekhter yakov@watson.ibm.com Ron Roberts roberts@jessica.stanford.edu Jonathan Rodin rodin@ftp.com Benny Rodrig 4373580@mcimail.com Manoel Rodrigues manoel.rodrigues@att.com Sharad Sanghi sharad@ans.net Erik Sherk sherk@sura.net William Simpson Bill_Simpson@um.cc.umich.edu Keith Sklower sklower@cs.berkeley.edu Mark Sleeper mws@sparta.com Frank Solensky solensky@clearpoint.com Walter Stickle wls@ftp.com William Streilein bstreile@wellfleet.com Sally Tarquinio sally@gateway.mitre.org Richard Thomsen rgt@lanl.gov Claudio Topolcic topolcic@nri.reston.va.us Paul Traina pst@cisco.com Kannan Varadhan kannan@oar.net Huyen Vu vi@polaris.dca.mil Carol Ward cward@westnet.net Bert Wijnen wijnen@vnet.ibm.com Steve Willens steve@livingston.com Scott Williamson scottw@nic.ddn.mil Walter Wimer walter.wimer@andrew.cmu.edu Linda Winkler lwinkler@anl.gov Cathy Wittbrodt cjw@nersc.gov Peter Yee yee@ames.arc.nasa.gov 8