home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Standards 1993 July / Disc.iso / inet / ietf / 92jul / nsfnet.min < prev    next >
Encoding:
Text File  |  1993-02-17  |  6.4 KB  |  158 lines
  1.  
  2. CURRENT_MEETING_REPORT_
  3.  
  4.  
  5. Reported by Laura Breeden/FARNET
  6.  
  7. Minutes of the Perspectives on the Next Generation of the NSFnet BOF
  8.  
  9. At this BOF, Laura Breeden of FARNET reviewed the results of a meeting
  10. held the previous week to discuss and analyze the NSF's Draft
  11. Solicitation for the next generation of the NSFNET/IINREN. The meeting
  12. (on July 9-10) included FARNET members, NSF representatives, other
  13. Federal agency representatives, and interested members of the networking
  14. community.  The purpose was to understand better the goals and
  15. intentions of the NSF and to provide commentary to them by August 3.
  16.  
  17. A full report of the two-day workshop is available on host farnet.org,
  18. in the farnet/iinren directory.
  19.  
  20. Participants in the BOF were able to ask clarifying questions about
  21. NSF's plans as expressed in the FARNET workshop.  Peter Ford, one of the
  22. architects of the plan, and Laura Breeden, who had extensive notes based
  23. on a tape of the NSF presentation, fielded most of the questions.  Other
  24. workshop attendees also contributed.
  25.  
  26. Key items of interest were the number, location and operating policies
  27. of the proposed Network Access Points (NAPs), the NSF requirement for
  28. support of video conferencing on the Very High Speed Backbone, and the
  29. transition from the current NSFNET to the planned follow-on.
  30.  
  31. The highlights of FARNET's recommendations are:
  32.  
  33.  
  34.   1. NSF should place the new solicitation more clearly within the NREN
  35.      context.
  36.      The introduction to the solicitation should be enhanced or expanded
  37.      to address the NREN context and to place the NSFNET in that
  38.      context....  We believe that it is critically important to clarify
  39.      this relationship, because just as the NSFNET backbone forms the
  40.      architectural core of the current Internet, the communities
  41.      attached to the NSFNET provide a strong foundation for continued
  42.      growth.
  43.      We hope that the solicitation will include a recognition that the
  44.      community of scientific scholars has diverse needs, from electronic
  45.      mail to high-bandwidth applications such as visualization.  NSF has
  46.      a mission and a responsibility to support the entire community.
  47.  
  48.   2. The plans for governance and management of the new infrastructure,
  49.      and the process for achieving them, should be stronger and more
  50.      explicit.
  51.  
  52.   3. Transition planning must begin early and must include the provider
  53.      community -- the organizations and institutions that furnish
  54.  
  55.                                    1
  56.  
  57.  
  58.  
  59.  
  60.  
  61.     network services today.
  62.  
  63.  4. Separate the Routing Arbiter function from that of the NAP Manager.
  64.     The solicitation should separate the Routing Arbiter from the NAP
  65.     Manager.
  66.     A majority of the Group, but not the entire Group, felt that it
  67.     should be mandatory to bid separately on vBNS and NAP provision,
  68.     but that a bidder should be permitted to show combined (lower)
  69.     costs as part of the bid if desired.  (The Routing Arbiter should
  70.     remain separate.)
  71.  
  72.  5. Enforcement of ``appropriate use'' policies will continue to be an
  73.     issue under the new plan.
  74.  
  75.  6. NSF's leadership role in extending networking to all of research
  76.     and education should be reaffirmed and continued.
  77.  
  78.  7. Criteria for attachment to NAPs and to the vBNS are critical and
  79.     should be described by NSF in the solicitation.
  80.     NSF should specify the criteria for attachment to the vBNS and the
  81.     NAPs in the solicitation.  Not doing so invites a bidding war for
  82.     access, which could destabilize the NSFNET, create unhealthy
  83.     competition among user institutions, and "skim the cream" from the
  84.     current set of network service providers.
  85.  
  86.  8. We recommend the following priorities in setting evaluation
  87.     criteria for the review of responses to the final solicitation..
  88.  
  89.  
  90.                GOAL                                                PRIORITY
  91.  
  92.     Promotion of broad infrastructure                               Very High
  93.     Interaction with community, including technology transfer        Very High
  94.     Continuity and stability of services                            High
  95.     QOS* measurement, accountability                                High
  96.     Advancement of technology                                       High/Medium
  97.     Commercialization                                               Medium
  98.     Cost-effectiveness                                              Medium
  99.     CLNP availability                                               Medium
  100.     Facilitation of new applications                                Medium
  101.     Provision of video services                                     Low/Medium
  102.  
  103.         *Quality of service
  104.  
  105.  
  106.  9. NAP parameters should be based on multiple dimensions and should
  107.     not be set solely on the basis of cost, which is only one component
  108.     of the total NSFnet system.
  109.  
  110. 10. We strongly recommend that the following technical requirements be
  111.     included in the solicitation.
  112.  
  113.                                   2
  114.  
  115.  
  116.  
  117.  
  118.  
  119.      The vBNS provider should be required to provide restoration
  120.      capability among NAPs using proven technology.
  121.      NSF should require in the solicitation that a plan be developed to
  122.      connect the current T3 network to the NAPs, as part of the
  123.      transition from the current backbone to the next generation.
  124.      The vBNS provider should be able to carry full routing information
  125.      (given the limitations of route server technology).
  126.      The vBNS provider should have a publicly available and appropriate
  127.      MIB (network Management Information Base).
  128.  
  129.  
  130. Attendees
  131.  
  132. Bill Manning             bmanning@rice.edu
  133. John Curran              jcurran@bbn.com
  134. Donald Morris            morris@ucar.edu
  135. Jane Wojcik              jwojcik@bbn.com
  136. Patricia Smith           psmith@merit.edu
  137. Mark Knopper             mak@merit.edu
  138. Kraig Owen               tko@merit.edu
  139. John Labbe               labbe@merit.edu
  140. Evan Wetstone            evan@rice.edu
  141. Susan Estrada            estradas@cerf.net
  142. Tony Hain                hain@nersc.gov
  143. Guy Almes                almes@ans.net
  144. Peter Ford               peter@lanl.gov
  145. Padma Krishnaswamy       kri@sabre.bellcore.com
  146. Dan Jordt                danj@nwnet.net
  147. E. Paul Love             loveep@sdsc.edu
  148. Eugene Hastings          hastings@a.psc.edu
  149. Matt Mathis              mathis@a.psc.edu
  150. Carol Ward               cward@westnet.net
  151. Ari Ollikainen           ari@es.net
  152. Ross Veach               rrv@uiuc.edu
  153. Marsha Perrott           mlp+@andrew.cmu.edu
  154.  
  155.  
  156.  
  157.                                    3
  158.