home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / 92mar / area.operations.92mar.txt < prev    next >
Encoding:
Text File  |  1993-02-17  |  7.7 KB  |  205 lines
  1.  
  2. Operational Requirements Area
  3.  
  4. Director(s):
  5.  
  6.  
  7.    o Susan Estrada:  estradas@cerf.net
  8.    o Phill Gross:  pgross@nis.ans.net
  9.    o Bernhard Stockman:  boss@sunet.se
  10.  
  11.  
  12. Area Summary reported by Bernhard Stockman/NORDUnet
  13.  
  14. Operational Statistics Working Group (OPSTAT)
  15.  
  16. The OPSTAT Working Group met two times during this IETF. At the first
  17. session the document ``An Internet Model for Operational Statistics''
  18. was reviewed.  Only minor changes were approved and the document is now
  19. ready to be submitted as an Internet Draft.
  20.  
  21. At the second session a review was made on which NOC's are able to adopt
  22. the OPSTAT model.  NOC's in the US, in Europe and in the Pacific
  23. expressed interest in participating in a test of the model.
  24.  
  25. Finally the Group discussed future activities for the OPSTAT Working
  26. Group.  A client/server based retrieval system may be useful to offload
  27. routing equipment from extensive SNMP-querying and to enforce access
  28. control to statistical data.
  29.  
  30. As some of the thinking in the OPSTAT model is based on common practises
  31. there is a need for a theoretical model verifying the assumptions made.
  32. Research in this direction was presented at the BOF on Wide Area Network
  33. Measurement at this IETF. The outcome of this research may show very
  34. fruitful for the OPSTAT work.
  35.  
  36. BGP Deployment and Application BOF (BGPDEPL)
  37.  
  38. BGP deployment status
  39.  
  40. The current status of BGP deployment was reviewed.  There are today
  41. around 21 regional networks using BGP towards NSFnet in production mode.
  42. Europe is actively doing a BGP pilot and some sites are already running
  43. BGP. Some of the MILnet sites are using BGP.
  44.  
  45. Drawbacks in today cisco implementation of BGP:
  46.  
  47.  
  48.    o Only one BGP process.
  49.    o The box choked after 9 routing process.
  50.    o BGP/EGP conflicts.
  51.    o Not a good idea to run BGP and EGP to the same AS.
  52.  
  53.  
  54.  
  55.                                    1
  56.  
  57.  
  58.  
  59.  
  60.  
  61. Routing Policy Description
  62.  
  63. The Group recognized the need of sharing routing policy between networks
  64. in the Internet in order to avoid contradictory routing policies and
  65. therefor artificial routing disconnections.  The Group discussed
  66. mechanisms to describe routing policy and share them.  As a first cut, a
  67. routing policy description form will be developed.  Merit will collect
  68. such forms and install them as a nis.nsf.net database.
  69.  
  70. The next step is to develop a mechanism for using the the policy
  71. database as input to a routing processor.  A very interesting approach
  72. is the possibility of using configuration compilers.  The idea is that
  73. input are parsable forms like the above described routing policy
  74. description which are processed into loadable configuration files.
  75.  
  76. Routing policy description processing:
  77.  
  78.  
  79.  
  80.                                   Routing policies
  81.                                   from other relevant domains
  82.                                    !  !
  83.      !---------------------------!  !  !
  84.      !                          !  !  !
  85.      !                          V  V  V
  86.      !                     !----------------!
  87.      !                     ! Common Routing !<------- Query
  88.      !                     ! Policy storage !
  89.      !                     !-------!--------!
  90.      !                             !             !-------------!
  91.      !                             !    !--------! Negotiation !
  92.      !                             V    V        !------!------!
  93.      !  !---------------!   !----------------!           ! YES
  94.      !  !  Domain A's   !   ! Routing Policy !     /-----!----\
  95.      !  !   Routing     !-->!   Processor    !----< Conflict ? >
  96.      !  ! Requirements  !   !----------------!     \-----!----/
  97.      !  !---------------!                               ! NO
  98.      !                     !----------------!           !
  99.      !                     !   Domain A's   !           !
  100.      !----------------------! Routing Policy !<----------!
  101.                            !-------!--------!
  102.                                    !
  103.                                    V
  104.                            !----------------!
  105.                            !  Configuration !    Configuration
  106.                            !    Compiler    !--> File
  107.                            !----------------!
  108.  
  109.  
  110.  
  111. By using gated it would be possible to modify sources to accommodate for
  112. increased hash tables.  If a fast unix host is used gated may be used in
  113. production traffic networks.  It is also possible to trace almost
  114.  
  115.                                    2
  116.  
  117.  
  118.  
  119.  
  120.  
  121. everything in the routing process.  Finally, gated could be used in
  122. stand by mode just logging the incoming routing updates and by this be
  123. used as a routing traffic analyzer.  For example when changes to the
  124. routing configuration are being installed it is possible to verify that
  125. everything works as intended before starting up gated in active mode.  A
  126. version with, besides the usual roting protocols, support for IS-IS,
  127. OSPF and BGP-II/III was recently announced as an alpha-version and is
  128. ftp:able from gated.cornell.edu.
  129.  
  130. Peter Ford of Los Alamos National Laboratory (LANL) presented the latest
  131. thinking on the NSFnet future.  A resolicitation will be made for the
  132. NSFnet backbone.  It is foreseen that at least two different carriers
  133. will provide the basic NSFnet infrastructure.
  134.  
  135.  
  136.  
  137.               !--------------------------------!
  138.               !          Carrier #1            !
  139.               !--!----!-----!-----!----!----!--!
  140.                  !    !     !     !    !    !
  141.                  O    O     O     O    O    O
  142.                  !    !     !     !    !    !
  143.               !--!----!-----!-----!----!----!--!
  144.               !          Carrier #2            !
  145.               !--------------------------------!
  146.  
  147.               O = Network Access Point (NAP)
  148.  
  149.  
  150. Regional networks will then be interconnected at one or more NAP's.
  151. This may also be the right place for networks like EBONE to hook on to
  152. the US infrastructures, especially if there will be no AUP in the NAP's
  153. but only in the backbones circuits.
  154.  
  155. Benchmarking Methodology Working Group (BMWG)
  156.  
  157. The document on ``Testing methodology'' was reviewed.  It will need one
  158. more iteration on the body of the material before it is ready to be
  159. submitted as an Internet Draft.
  160.  
  161. There are some appendices that need more work and a video conference
  162. will be set up within one month to accomplish this.
  163.  
  164. There is a companion document on the test frame formats that shall be
  165. ready by the Boston IETF. Next on the Agenda are two things:
  166.  
  167.  
  168.   1. A document giving advice on how to interpret the test results.
  169.   2. Definition of host based protocol testing.
  170.  
  171.  
  172. Wide Area Network Measurement BOF (WAIS)
  173.  
  174.                                    3
  175.  
  176.  
  177.  
  178.  
  179.  
  180. Mike Schwartz of the University of Colorado presented part of his
  181. research in network measurements with regards to metrics and tools as
  182. compared to the resources being measured.  His work includes
  183. measurements of telnet and ftp connection durations, modeling and
  184. generation of random topologies, measurement of availability and
  185. bandwidth, etc.  The intention is to create a model of traffic sources,
  186. i.e., a work load model of the Internet and by this be able to predict
  187. network growth and requirements.
  188.  
  189. A PhD thesis is under preparation by Kim Claffy at the San Diego
  190. Supercomputer Center.  4 million packet headers, collected during 10pm
  191. December 24 and 2am December 25 at fix-west, were analyzed with regards
  192. to application distributions, flows, protocol distributions and
  193. performance.  Resource consumption and latency behavior where
  194. investigated.  Performance degradation under resource starvation was
  195. studied.  A remarkable discovery was that to make an analysis with
  196. regards to application distribution, it was not necessary to collect
  197. every packet.  A collection of every 10:th packet or a collection of
  198. continuous 10 packets at every 1000:th packet gave almost identical
  199. patterns.  Diagrams were presented on interagency traffic and network to
  200. network traffic.
  201.  
  202.  
  203.  
  204.                                    4
  205.