Operational Requirements Area Director(s): o Phill Gross: pgross@nis.ans.net o Bernhard Stockman: boss@ebone.net Area Summary reported by Bernhard Stockman/SUNET BGP Deployment and Application Working Group (BGPDEPL) The BGPDEPL Working Group met for one session during this IETF chaired by Matt Mathis. Of the approximately 5000 networks which are currently reachable, almost 3000 are being announced with EGP2. This situation is pretty bleak. There is only a short time available to test and deploy BGP-4, and operators who have not yet deployed BGP-3, will face additional difficulties phasing out EGP-2. It is desirable for all network operators to have BGP experience as soon as possible. Proposed deployment schedule for BGP-4/CIDR: 1/93-3/93 BGP-4 interoperability testing with the ANS testing facility (See below - all vendors are invited to participate). 3/93 BGP-4 capable code deployed in the production NSFnet backbone. Begin testing by propagating some test CIDR networks through the backbone. 6/93 Start aggregating *production* networks in the backbone. 12/93 Completely phase out all EGP-2 on NSFnet DMZs. There was some discussion about how this interacts with the new network assignment rules and schedule specified in RFC1366 and RFC1367. The first aggregation of production networks (scheduled for June 1993) will be a flag day for any site requiring full routing tables and not running BGP-4. Jordan Becker (ANS) estimated that full route aggregation will reduce the current routing tables by about 30%, because the old address assignment policies tended to allocate addresses in blocks anyhow. cisco's next scheduled code freeze is February 1993, so even if bug-free BGP-4 code exists today, the earliest it will appear in General Availability products is October 1993. All customers who need BGP-4 before then must run pre-GA code. 1 Benchmarking Methodology Working Group (BMWG) The BMWG Group met during one session Chaired by Scott Bradner. The Group discussed various test frame formats to be used in conjunction with earlier described network device testing methods as described in RFC 1242. Some router vendors have announced inadequate performance metrics with no consistent way defined for measuring of router performance. In some network devices, packet forwarding has priority above other functions which could result in loss of learning tree for bridges and loss of routing information for routers when the device is loaded. The Working Group discussed Performance impacts of filter lists. Various sizes of filter lists have been tested. Some vendors use hash-search where there is no significant difference in performance between various sizes of filter lists. When linear search is used the amount of list entries is proportional to the performance impact. Finally the Working Group discussed the performance impact of network management. It was noted that some network products do not update the SNMP MIB database as often as the hardware updates its counters. There may thus be a discrepancy between what actually is going on and how this is reflected in the MIB database. Network Status Report (NETSTAT) and Network Joint Management Working Group (NJM) o Mark Knopper, Merit, Jordan Becker, ANS - NSFnet: Transition T1 -> T3 ongoing. In October, 18.9 billion packets carried on T3 while T1 steadily decreasing Number of nets is 7354 whereof 2566 is foreign networks. OSI traffic 600000 - 1000000 packets per month during March to October 1992, August and September close to zero though. T3 not yet ready to forward native CLNP which will be carried encapsulated in IP. Of NSFnet/ANSnet configured networks nearly six thousands are actively announced. Around 90 percent of the networks are using T3 as primary. - The T3 backbone implementation. Dummy AS support for load splitting. Up to 5 high speed interfaces per router with 20 kpps in and out per interface and total of 50 kpps per router. Max performance is 22 Mbps in each direction at 270 byte packetsize. One way router hop delay = 0.165 msec which gives cross country router delay (8 hops) of 1.35 msec and a total cross country delay of 35 msec. A ping version using NTP for microsecond resolution is used. The dismantling of T1 backbone lines starts 12 Feb. - T3 Network Status. Announced corrections in peer behavior. Engineering changes in internal routing to minimize delay through T3 net. Map with delay numbers will be available 2 on-line. Deployment underway of encapsulated CLNP across T3, to enable decommissioning of T1 very soon. Announced deployment of BGP4 in spring. Invited vendors & operators to use ANS testnet. Support for CIDR is planned to start January 93. o DECNET IV support - Multiproto routers - Elimination of upgrade of tail circuits - Multinet DECNET in TCP encap support - Throughput on T1 over 200 Kbps - Gradual transition (if any) to DECNET V - Native DECNET not considered due to sever loss of performance depending on DECNET resend algorithm. o Milo Medin - NASA Science Internet: Awaiting US Department of Commerce clearance for connection to Russia. NASA portion of DoE/NASA ATM will ' initially include Langley, Lewis, Goddard, Ames, JPL. o Bernhard Stockman - EBONE: Deploying security access scheme in EBONE routers - combination of kerberos and TACACS. Plan for link from Stockholm to Bonn. o Bob Collet - Sprint: Sprint operates three logically distinct IP networks - domestic US, Atlantic-Europe-Mideast, and Pacific. Exclusively Cisco routers showed new maps with new perspectives. o Rich Fisher - GSFC: Satellite data collection & redistribution to distant research and processing centers. o Tony Hain - ESnet: ATM project sites Livermore, LBL, LANL, Fermi, Oak Ridge, SuperCollider All local loops will be fiber. o Mark Knopper - ERNET: Networking in India Funded by Indian governmental and UN plan to ``upgrade'' to vsat connections domestically to overcome shortcomings in domestic infrastructure. Operational Requirement Area Directorate (ORAD) The meeting discussed requirements of ORAD and its members. ORAD is expected to guide other working groups and review documents with special attention to operational needs. Current Operations Area working group Chairs could be part of ORAD, but this is not implicitly required. To make ORAD have broad coverage it will be necessary to invite operators who have not traditionally participated in IETF meetings. The meeting concluded that ORAD should not start off too big but 3 initially concentrate on document review and presentation of issues to working groups. Finally, the Group discussed various operational aspects of the ongoing audio and video multicast from IETFs. MBONE routers shall be positioned as high as possible in the topology. An ORAD operations recommendation was discussed. A variety of actions to improve the current MBONE implementation were identified. Tests shall happen before IETFs, which include announcements of tunneling and requests to be made further in advance of conferences, and a strict cut-off date after which there will be no more tunnels. Operational Statistics Working Group (OPSTAT) Before this meeting the Internet-Draft on a model for operational statistics had been submitted as an Informational RFC. This time the Working Group restarted the work on the client/server based protocol for retrieval of statistical data. Most of the simple commands where kept as is while the more complex part were significantly modified. Some discussion centered around where the selection processing should be done. For example, should the conditionals be processed on the server or client? Great economies could be realized by processing the conditional on the server versus downloading all data to the client and processing it there. Some discussion revolved around the SQL-ness of the select command. Consensus not to make it more complex than it already is. As the storage format in the above mentioned RFC has changed since the client/server specification was initially drafted it was necessary to change some part of the client/server command language to reflect this. Finally the Goals and Milestones section of the OPSTAT Charter was reviewed and updated. User Connectivity Problems Working Group (UCP) The Group had previously defined a data structure that would enable Trouble Ticket hand-offs between NOCs. Paul Zawada had written an ASN.1-like description of the fields in this data structure. Kaj Tesink drafted a document describing how some hand-off fields could be represented in electronic mail messages. The Group discussed this and agreed that the document needs to be revised to reflect more of the previously-defined hand-off fields. The goal is to allow trouble tickets to be mailed between NOCs both with and without internal trouble ticket systems. The format should be simple enough to enable humans to enter the data and yet regular enough to permit parsing. Paul and Kaj will work on this and get it out as an Internet-Draft. At that time, several groups agreed to experiment with the exchange format and to create a template to facilitate manual participation. The UCP Internet-Draft on a Trouble Ticket Tracking System, originally written by Matt Mathis, had been discussed and revised heavily by the Group and it has now expired. Dan Long has volunteered to draft a new version which reflects the current consensus of the Group. This will 4 also be published as an Internet-Draft. The Group also discussed the current status of various publicly available internal Trouble Ticket systems. 5