Operational Requirements Area Director(s): o Susan Estrada: estradas@cerf.net o Phill Gross: pgross@nis.ans.net o Bernhard Stockman: boss@sunet.se Area Summary reported by Bernhard Stockman/NORDUnet Operational Statistics Working Group (OPSTAT) The OPSTAT Working Group met two times during this IETF. At the first session the document ``An Internet Model for Operational Statistics'' was reviewed. Only minor changes were approved and the document is now ready to be submitted as an Internet Draft. At the second session a review was made on which NOC's are able to adopt the OPSTAT model. NOC's in the US, in Europe and in the Pacific expressed interest in participating in a test of the model. Finally the Group discussed future activities for the OPSTAT Working Group. A client/server based retrieval system may be useful to offload routing equipment from extensive SNMP-querying and to enforce access control to statistical data. As some of the thinking in the OPSTAT model is based on common practises there is a need for a theoretical model verifying the assumptions made. Research in this direction was presented at the BOF on Wide Area Network Measurement at this IETF. The outcome of this research may show very fruitful for the OPSTAT work. BGP Deployment and Application BOF (BGPDEPL) BGP deployment status The current status of BGP deployment was reviewed. There are today around 21 regional networks using BGP towards NSFnet in production mode. Europe is actively doing a BGP pilot and some sites are already running BGP. Some of the MILnet sites are using BGP. Drawbacks in today cisco implementation of BGP: o Only one BGP process. o The box choked after 9 routing process. o BGP/EGP conflicts. o Not a good idea to run BGP and EGP to the same AS. 1 Routing Policy Description The Group recognized the need of sharing routing policy between networks in the Internet in order to avoid contradictory routing policies and therefor artificial routing disconnections. The Group discussed mechanisms to describe routing policy and share them. As a first cut, a routing policy description form will be developed. Merit will collect such forms and install them as a nis.nsf.net database. The next step is to develop a mechanism for using the the policy database as input to a routing processor. A very interesting approach is the possibility of using configuration compilers. The idea is that input are parsable forms like the above described routing policy description which are processed into loadable configuration files. Routing policy description processing: Routing policies from other relevant domains ! ! !---------------------------! ! ! ! ! ! ! ! V V V ! !----------------! ! ! Common Routing !<------- Query ! ! Policy storage ! ! !-------!--------! ! ! !-------------! ! ! !--------! Negotiation ! ! V V !------!------! ! !---------------! !----------------! ! YES ! ! Domain A's ! ! Routing Policy ! /-----!----\ ! ! Routing !-->! Processor !----< Conflict ? > ! ! Requirements ! !----------------! \-----!----/ ! !---------------! ! NO ! !----------------! ! ! ! Domain A's ! ! !----------------------! Routing Policy !<----------! !-------!--------! ! V !----------------! ! Configuration ! Configuration ! Compiler !--> File !----------------! By using gated it would be possible to modify sources to accommodate for increased hash tables. If a fast unix host is used gated may be used in production traffic networks. It is also possible to trace almost 2 everything in the routing process. Finally, gated could be used in stand by mode just logging the incoming routing updates and by this be used as a routing traffic analyzer. For example when changes to the routing configuration are being installed it is possible to verify that everything works as intended before starting up gated in active mode. A version with, besides the usual roting protocols, support for IS-IS, OSPF and BGP-II/III was recently announced as an alpha-version and is ftp:able from gated.cornell.edu. Peter Ford of Los Alamos National Laboratory (LANL) presented the latest thinking on the NSFnet future. A resolicitation will be made for the NSFnet backbone. It is foreseen that at least two different carriers will provide the basic NSFnet infrastructure. !--------------------------------! ! Carrier #1 ! !--!----!-----!-----!----!----!--! ! ! ! ! ! ! O O O O O O ! ! ! ! ! ! !--!----!-----!-----!----!----!--! ! Carrier #2 ! !--------------------------------! O = Network Access Point (NAP) Regional networks will then be interconnected at one or more NAP's. This may also be the right place for networks like EBONE to hook on to the US infrastructures, especially if there will be no AUP in the NAP's but only in the backbones circuits. Benchmarking Methodology Working Group (BMWG) The document on ``Testing methodology'' was reviewed. It will need one more iteration on the body of the material before it is ready to be submitted as an Internet Draft. There are some appendices that need more work and a video conference will be set up within one month to accomplish this. There is a companion document on the test frame formats that shall be ready by the Boston IETF. Next on the Agenda are two things: 1. A document giving advice on how to interpret the test results. 2. Definition of host based protocol testing. Wide Area Network Measurement BOF (WAIS) 3 Mike Schwartz of the University of Colorado presented part of his research in network measurements with regards to metrics and tools as compared to the resources being measured. His work includes measurements of telnet and ftp connection durations, modeling and generation of random topologies, measurement of availability and bandwidth, etc. The intention is to create a model of traffic sources, i.e., a work load model of the Internet and by this be able to predict network growth and requirements. A PhD thesis is under preparation by Kim Claffy at the San Diego Supercomputer Center. 4 million packet headers, collected during 10pm December 24 and 2am December 25 at fix-west, were analyzed with regards to application distributions, flows, protocol distributions and performance. Resource consumption and latency behavior where investigated. Performance degradation under resource starvation was studied. A remarkable discovery was that to make an analysis with regards to application distribution, it was not necessary to collect every packet. A collection of every 10:th packet or a collection of continuous 10 packets at every 1000:th packet gave almost identical patterns. Diagrams were presented on interagency traffic and network to network traffic. 4