home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / noop / noop-minutes-92mar.txt < prev    next >
Text File  |  1993-02-17  |  17KB  |  440 lines

  1.  
  2. CURRENT_MEETING_REPORT_
  3.  
  4.  
  5. Reported by Sue Hares/Merit, David Bolen/ANS and Dave Miller/MITRE
  6.  
  7. Minutes of the Network OSI Operations Working Group (NOOP)
  8.  
  9. The Network OSI Operations Group met three times during the week of the
  10. San Diego IETF. The first meeting took place on Monday morning.  Steve
  11. Deering presented his ideas behind his paper ``City Codes is an
  12. Alternative to Topological NSAP Allocation (RFC 1237).''  In addition,
  13. Ross Callon presented the basics of RFC 1237.  Both presentations
  14. prompted a great deal of discussion.  Sally Tarquinio took very detailed
  15. notes of the discussion.  Due to the length of both the notes and the
  16. discussion, the notes will not be available in the Proceedings.  Notes
  17. may be retrieved via anonymous ftp from merit.edu in
  18. /pub/iso/noop/notes/notes.03.16.92.am).
  19.  
  20. In addition to the City Code discussion, the following topics were
  21. discussed:
  22.  
  23.  
  24.    o Mobile Hosts
  25.    o Comparison Geographical Area Code (GARP) with NAT and CNAT
  26.    o GARP vs RFC 1237
  27.    o Whether asymmetric pathways are acceptable.
  28.  
  29.  
  30. The second NOOP session occurred on Wednesday morning at 9:00 a.m.  and
  31. covered several different items.  Notes were taken by David Bolen.
  32.  
  33. Usage Questionnaire
  34.  
  35. Sue Hares made available copies of the OSI usage questionnaire and
  36. requested that anyone involved with OSI work try to complete one.  This
  37. was a copy of the same questionnaire that was previously distributed
  38. electronically.
  39.  
  40. A question was raised as to why DECnet was considered different than
  41. CLNP (p.  9) - the answer was that it wasn't really, but the goal was to
  42. see if DECnet usage was pushing CLNP usage (here, DECnet really means
  43. DECnet Phase V traffic).
  44.  
  45. NEARnet OSI Routing/Addressing Plan
  46.  
  47.  
  48.    o Introduction
  49.      John Curran from NEARnet (New England Academic & Research Network)
  50.      made a presentation of NEARnet's OSI Plan.  NEARnet is comprised of
  51.      120 members in six states, and coordinates with other New England
  52.      service providers to provide service in that area.  Cisco routers
  53.      are used throughout NEARnets network.
  54.  
  55.                                    1
  56.  
  57.  
  58.  
  59.  
  60.  
  61. o Address Assignment Plan
  62.   When researching an address assignment plan, NEARnet found that
  63.   area codes were a nice match for population density, and therefore
  64.   for assignment beneath NEARnet's AAI.
  65.   NEARnets final address format breakdown assumed the following
  66.   limits:
  67.  
  68.    -  Total of 16 COs per area code.
  69.    -  Total of 256 RDs per CO. This could be a real problem in a
  70.       fairly short-term (~ two years).  It is hard to gauge demand
  71.       though, and NEARnet isn't the only network assigning in the New
  72.       England area.
  73.  
  74.   CO codes are assigned to aggregate at other boundaries as well:
  75.  
  76.           .00-.3F = Massachusetts    (.10 = 508 area code, .20 = 617, etc..)
  77.           .40-.4F \
  78.           .50-.5F  \  Assign to different states - allows room for
  79.           .60-.6F  /  expansion according to area code.
  80.           .70-.7F /
  81.           .80-    still some slack available for future expansion
  82.  
  83.  
  84.   The next step is then to assign RDs logically under this scheme.
  85.   The multiple aggregation points within this scheme helps to limit
  86.   the routing table size.
  87. o Routing (ala RFC1237)
  88.   The following points were raised with respect to routing issues
  89.   under this sort of an address assignment scheme:
  90.  
  91.    -  Routes will often have to be manually injected.
  92.    -  IGRP is not currently collapsing routes - hopefully newer
  93.       protocols will begin to do this.
  94.    -  NEARnet doesn't like the fact that they have to accept all
  95.       routes as it allows NEARnet's routing tables to grow without
  96.       bounds.
  97.    -  NEARnet sees NSAP changes as a lot of work currently - thus, if
  98.       a customer has already been assigned an RD, NEARnet lets the
  99.       customer keep it.
  100.    -  NEARnet will accept any other assignments, but isn't sure what
  101.       will happen with other networks - will they be as accepting as
  102.       NEARnet?
  103.  
  104. o Questions
  105.   John brought up the general question as to what the general opinion
  106.   of this plan was.  Could the approach be viewed as dangerous?  The
  107.   following points were raised:
  108.  
  109.                                 2
  110.  
  111.  
  112.  
  113.  
  114.  
  115.       -  Something has to be done, and at least this policy allows
  116.          future aggregation - it's very hard to take back what we give
  117.          out today.
  118.       -  There could be a problem if all service providers don't become
  119.          as accepting as NEARnet.  If routes begin to be refused, it
  120.          might cause everyone to bail out to their own AAI which would
  121.          create a flat address space once again.
  122.       -  If we are allowing entropy at all (as this plan does), then
  123.          there needs to be some sort of entropy reduction in the system.
  124.          A possible recourse might be the need to start charging for the
  125.          announcement of a special route to other networks.
  126.  
  127.      A general point was made that at the moment, the whole area of
  128.      addresses and assignment represents more of a controlled economy
  129.      than a true market economy.  Moving from one to the other is always
  130.      tough.
  131.      NEARnet's addressing and routing plan may be found (via anonymous
  132.      ftp) in:
  133.      nic.near.net:/docs/osi-routing-plan.txt or
  134.      merit.edu:/pub/iso/noop/papers/nearnet.osi-routing-plan.txt
  135.      John also gave credit to CICNet for their previously released OSI
  136.      plan, and said that NEARnet's plan borrowed a lot from CICNet's.
  137.  
  138.  
  139. OSI Pilot Projects
  140.  
  141. The discussion of OSI pilot projects centered around some documentation
  142. that Sue supplied describing some of the work that RARE is doing in this
  143. area.  RARE has a suite of tests that they are requesting users at their
  144. sites to perform, sending them results back to a central site to be
  145. summarized.  Sue was interested in whether or not their was enough
  146. interest in trying the same sort of pilot plan here in the U.S., as well
  147. as trying to get together another OSI demo for Interop East.
  148.  
  149. The general consensus of the Group was that, yes, it would be useful to
  150. try the same sort of pilot project here, and that the RARE approach
  151. seemed a reasonable way to proceed.  It would also be nice to see about
  152. some coordination with RARE, although mostly for inter-domain and
  153. application level than at the ES-IS and IS-IS level.  The
  154. application-level portion of the RARE plan was a little weak, and may
  155. need to be augmented for our tests.
  156.  
  157. A possible problem was brought up in that a number of sites have beta
  158. implementations of OSI code, and may not be able to publish the results
  159. of tests.  Sue suggested that at least saying ``I've tested'' is useful,
  160. even if the exact results of the test cannot be released.
  161.  
  162. NIST was brought up as an organization that was already handling some
  163. OSI testing in the same vein as what was being discussed.  NIST has
  164. provided open labs and a test environment for multiple vendors to come
  165. together in order to test interoperability.  There has been no automated
  166.  
  167.                                    3
  168.  
  169.  
  170.  
  171.  
  172.  
  173. or documented test procedures followed, however - just vendor engineers
  174. running particular tests.  Richard Collela will be sending some further
  175. information about this testing to the NOOP mailing list.
  176.  
  177. The fundamental difference between the testing that has been performed
  178. at NIST, and the type of pilot projects being run by RARE is that the
  179. latter case involves actual end users, while the former is run by the
  180. vendors and their engineers.
  181.  
  182. John Curran suggested that the request for tests be sent out to the NOOP
  183. list.  While many midlevels may not run the tests themselves, they may
  184. have clients that can.  Sue Hares agreed to send the test plan, and a
  185. request for volunteers to the NOOP mailing list.
  186.  
  187. Document Review:  (reported by Dave Miller)
  188.  
  189.  
  190.    o TOOLS RFC
  191.      Their was a brief discussion on the ``Tools'' Document and the need
  192.      for tools to provide OSI ping, OSI traceroute, and OSI routing
  193.      table dump utilities.  The discussion then focused on what routing
  194.      table information should be available via SNMP. It was noted that
  195.      the document should specify a minimal set of objects as MUST
  196.      requirements for this specification.
  197.      For CLNS MIB objects, no one took exception to the list in the
  198.      draft document.  For IS-IS, the document currently states the
  199.      object in very general terms.  Dino Farinacci was asked to write-up
  200.      a minimal list of IS-IS objects and send them to the NOOP mailing
  201.      list.  For IDRP, no one took exception to the list in the draft
  202.      document.
  203.      There was no review of objects for CMIP management at this time.
  204.    o SURVEY FORM
  205.      Sue Hares gave a status overview of the OSI in the Internet Survey.
  206.      The plan to maintain the survey is to perform a monthly revision to
  207.      incorporate any new information received.  Sue also encouraged
  208.      others to respond to the survey since only about ten responses have
  209.      been received to date.
  210.      There were a few suggestions to modify the survey (it was noted
  211.      that the changes should be highlighted when new surveys are sent
  212.      out):
  213.  
  214.       -  DECnet traffic should refer to DECnet Phase V traffic.
  215.       -  Text should refer to RFC 1006 as opposed to a TCP/IP stack.
  216.       -  There should be a context section added to identify who's
  217.          responding to the survey and what their role in OSI is.
  218.  
  219.      Cathy Wittbrodt suggested that the surveys be stored individually
  220.      on-line so particular responses could be retrieved as desired.  Sue
  221.      agreed to do this.
  222.  
  223.                                    4
  224.  
  225.  
  226.  
  227.  
  228.  
  229.      Dave Farber suggested sending the survey out to the IETF mailing
  230.      list to reach a broader community.  Sue agreed to do this.
  231.    o SECURITY RFC
  232.      Walt Lazear gave an overview of the OSI Packet Filtering document.
  233.      The document discusses the issues associated with filtering OSI by
  234.      application type in the context of using packet filtering to
  235.      restrict OSI connections (establishing firewalls).
  236.      Walt noted that he has not received comments on the current
  237.      document and solicited feedback.
  238.      There was some discussion of what were the security requirements
  239.      that were trying to be met.  MITRE was asked if they could put
  240.      together a short paper on OSI security policy to set the context
  241.      for this work and to stimulate further discussion.  Bill Barns
  242.      volunteered himself and Walt to pursue this.
  243.    o NIST IS-IS TEST LAB
  244.      Rich Colella gave a quick overview of the IS-IS test lab
  245.      established at NIST. Two Open Lab sessions have been conducted to
  246.      date to perform vendor interoperability testing.
  247.      A report of the router testing is being prepared.  Rich agreed to
  248.      get a copy of the completed report sent to the NOOP list.
  249.  
  250.  
  251. The third NOOP sessions took place during the 7:00 p.m.  session on
  252. Wednesday, March 18th, and was devoted to discussion of the IDRP for IP
  253. document.  A new working group will be formed to discuss the IDRP
  254. issues.  Detailed notes are available via ftp, cd ietf, get
  255. noop-minutes-92mar.txt).
  256.  
  257. NOTES>>>>>>>
  258.  
  259. IDRP for IP
  260.  
  261. IDRP can be found in merit.edu:/pub/iso/idrp.ps IDRP for IP will be
  262. submitted as an Internet Draft by April 1st.
  263.  
  264.  
  265.   1. BISPDU (IDRP packet) in IP packet with unique protocol ID.
  266.      IDRP provides a reliable transport so TCP not needed.
  267.   2. IP addresses encoded in NLRI and NET.
  268.      Current ANSI ballot proposal will allow direct encoding.  This
  269.      ballot proposal will be a correction on the current DIS ballot
  270.      text.
  271.   3. IDRP for IP only has:
  272.  
  273.        o No CLNP forwarding
  274.        o No IDRP GMDO for CMIP: (MIB will be part of an Internet
  275.          standard.  Internet is using SNMP over CLTS.)
  276.  
  277.  
  278.                                    5
  279.  
  280.  
  281.  
  282.  
  283.  
  284.   4. Minimal Configuration Information needed for IDRP.
  285.  
  286.        o Intra-Domain ISs (routers)
  287.        o Location and identity of BIS (Border routers) in Domain
  288.        o IP addresses for Routing Domain (bag of networks)
  289.        o Routing Domain Identifier (RDI)
  290.          (New style AS)
  291.          47:0005:81:aa:aa
  292.          Where if AS number needs to be expanded, the aa:aa field can go
  293.          to 4 bytes.
  294.        o Rib Attribute Set = null
  295.          Rib Attributes identify QOS. QOS will be examined in a separate
  296.          document.
  297.        o Routing Domain Confederations - RDCs
  298.          Routing Domain Confederations this node is a part of.
  299.        o SNPAs of this node
  300.  
  301.   5. IDRP compared to BGP-4.
  302.      Additional Features
  303.  
  304.        o DIST_LIST_INCL, DIST_LIST_EXCL
  305.          DIST_LIST_INCL indicates which routing domains a set of routing
  306.          information may be passed to.  DIST_LIST_EXCL states this
  307.          routing information may be passed to all RDs but the ones
  308.          listed.
  309.        o Local Preference (may be added to BGP-4)
  310.        o MULT_EXIT_DISC (may be added to BGP-4)
  311.        o RDC
  312.        o RD Sets
  313.        o IDRP has its own transport
  314.        o Hierarchical Recording
  315.  
  316.   6. IDRP Deployment.
  317.  
  318.        o Minimum configuration:  1 BIS, 1 BIS can pass to intra-domain
  319.          routing.
  320.        o IP Prefix goes in 1 Routing domain, not multiple.
  321.          Prefix is really 1 campus or RD, not the large ``bags'' of
  322.          networks that make up AS now.
  323.  
  324.  
  325. Attendees
  326.  
  327. Andy Adams               ala@merit.edu
  328. Vikas Aggarwal           aggarwal@jvnc.net
  329.  
  330.                                    6
  331.  
  332.  
  333.  
  334.  
  335.  
  336. Robert Aiken             raiken@nsf.gov
  337. Steve Alexander          stevea@i88.isc.com
  338. Nagaraj Arunkumar        nak@3com.com
  339. Zorica Avramovic         zorica@sparta.com
  340. William Barns            barns@gateway.mitre.org
  341. Tony Bates               tony@ean-relay.ac.uk
  342. William Biagi            bbiagi@cos.com
  343. David Bolen              db3l@nis.ans.net
  344. Scott Brim               swb@cornell.edu
  345. J. Nevil Brownlee        nevil@aukuni.ac.uz
  346. Eric Brunner             brunner@practic.com
  347. Niels Brunsgaard         nob@dowtyns.dk
  348. Ross Callon              callon@bigfut.enet.dec.com
  349. John Chang               jrc@uswest.com
  350. A. Lyman Chapin          lyman@bbn.com
  351. Henry Clark              henryc@oar.net
  352. Alan Clegg               abc@concert.net
  353. Richard Colella          colella@osi.ncsl.nist.gov
  354. Rob Coltun               rcoltun@ni.umd.edu
  355. Robert Cooney            cooney@wnyose.nctsw.navy.mil
  356. Curtis Cox               ccox@wnyose.nctsw.navy.mil
  357. Dave Cullerot            cullerot@ctron.com
  358. John Curran              jcurran@bbn.com
  359. Steve Deering            deering@xerox.com
  360. Kathleen Dodd            kathy@gateway.mitre.org
  361. Tom Easterday            tom@cic.net
  362. Dino Farinacci           dino@cisco.com
  363. Stefan Fassbender        stf@easi.net
  364. Peter Ford               peter@lanl.gov
  365. Karen Frisa              karen.frisa@andrew.cmu.edu
  366. Vince Fuller             vaf@stanford.edu
  367. Eugene Geer              ewg@nvuxr.bellcore.com
  368. Robert Hagens            hagens@cs.wisc.edu
  369. Susan Hares              skh@merit.edu
  370. Jeff Hayward             j.hayward@utexas.edu
  371. Juha Heinanen            juha.heinanen@datanet.tele.fi
  372. Randy Hoebelheinrich     rho@rowan.lanl.gov
  373. Kathleen Huber           khuber@bbn.com
  374. Bob Jeckell              rrj@3com.com
  375. Barbara Jennings         bjjenni@sandia.gov
  376. Dan Jordt                danj@nwnet.net
  377. Dave Katz                dkatz@merit.edu
  378. H. A. Kippenhan          kippenhan@fndcd.fnal.gov
  379. Yoav Kluger              ykluger@fibhaifa.com
  380. Deidre Kostick           dck2@sabre.bellcore.com
  381. Eva Kuiper               eva@hpindda.cup.hp.com
  382. John Larson              jlarson@parc.xerox.com
  383. Walter Lazear            lazear@gateway.mitre.org
  384. Eliot Lear               lear@sgi.com
  385. Kurt Lidl                lidl@sura.net
  386. Susan Lin                suelin@ibm.com
  387. Tony Li                  tli@cisco.com
  388. Triet Lu                 trietl@sparta.com
  389. Gary Malkin              gmalkin@xylogics.com
  390.  
  391.                                    7
  392.  
  393.  
  394.  
  395.  
  396.  
  397. Bill Manning             bmanning@rice.edu
  398. Glenn McGregor           ghm@merit.edu
  399. Milo Medin               medin@nsipo.nasa.gov
  400. David Miller             dtm@mitre.org
  401. Henry Miller             henrym@sacusr.mp.usbr.gov
  402. Greg Minshall            minshall@wc.novell.com
  403. Dennis Morris            morrisd@imo-uvax.dca.mil
  404. Donald Morris            morris@ucar.edu
  405. Brad Passwaters          bjp@sura.net
  406. David Piscitello         dave@sabre.bellcore.com
  407. Jon Postel               postel@isi.edu
  408. Rex Pugh                 pugh@hprnd.rose.hp.com
  409. Yakov Rekhter            yakov@watson.ibm.com
  410. Ron Roberts              roberts@jessica.stanford.edu
  411. Jonathan Rodin           rodin@ftp.com
  412. Benny Rodrig             4373580@mcimail.com
  413. Manoel Rodrigues         manoel.rodrigues@att.com
  414. Sharad Sanghi            sharad@ans.net
  415. Erik Sherk               sherk@sura.net
  416. William Simpson          Bill_Simpson@um.cc.umich.edu
  417. Keith Sklower            sklower@cs.berkeley.edu
  418. Mark Sleeper             mws@sparta.com
  419. Frank Solensky           solensky@clearpoint.com
  420. Walter Stickle           wls@ftp.com
  421. William Streilein        bstreile@wellfleet.com
  422. Sally Tarquinio          sally@gateway.mitre.org
  423. Richard Thomsen          rgt@lanl.gov
  424. Claudio Topolcic         topolcic@nri.reston.va.us
  425. Paul Traina              pst@cisco.com
  426. Kannan Varadhan          kannan@oar.net
  427. Huyen Vu                 vi@polaris.dca.mil
  428. Carol Ward               cward@westnet.net
  429. Bert Wijnen              wijnen@vnet.ibm.com
  430. Steve Willens            steve@livingston.com
  431. Scott Williamson         scottw@nic.ddn.mil
  432. Walter Wimer             walter.wimer@andrew.cmu.edu
  433. Linda Winkler            lwinkler@anl.gov
  434. Cathy Wittbrodt          cjw@nersc.gov
  435. Peter Yee                yee@ames.arc.nasa.gov
  436.  
  437.  
  438.  
  439.                                    8
  440.