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 Generic Internet Service Specification BOF (GISS) Tony Bates gave a brief overview of a project to try to produce a specification for a ``Generic Internet Service Specification''. The primary emphasis of this work is at the ``provider/provider'' interface rather than at the ``user/provider'' interface. The goal is to make it easier for new service providers to understand and interwork with various other service providers. The plan is to have a specification document that will need to be updated and also highlight areas for further study or beyond scope. A pointer was raised to the FYI16 document which could be augmented slightly to cover the ``user/provider'' interface in a less ``U.S.'' centric approach. However, this is not the primary focus of this current specification. Within the brainstorming session some concerns were raised as to whether such a document could mandate items that a service provider should provide. The document would raise issues rather than mandating anything. It was clear that the document would have to be revised on a regular basis. A list of ``first-pass'' items for the specification were worked through. Many of the items could easily fall into more than one category. The first pass list will cover the following items: o Routing issues o Addressing o Information Provision o Operations o Connectivity o Engineering and Maintenance o Attachment o Generic Services Coordination o Other networks o AUP (more than routing) o Remote/Local management Tony Bates will draft the details and circulate to the giss list. those wishing to join the giss list they can do so by sending a message to: giss-wg-request@ripe.net 1 Dan Long, John Curran and David Conrad will act as reviewers. Daniel Karrenberg will follow up on the revision of FYI 16. It was decided not to ask for an IETF working group at this stage. The draft will be sent out to the ORAD list and see whether or not there is enough interest to create a working group. MBONE Engineering and Operations BOF (MBONE) Initially some general issues were discussed. The Mbone is dangerous, but the applications are very useful. Critical problems are largely due to the lack of tools to manage the mbone. The meeting discussed different approaches to deal with problems from various groups involved in the mbone community such as network operators, network subscribers and end users. The Group unanimous agreed that it is bad practice of network operators to support mbone tunnels into other regions to solve the problem that a subscriber does not get satisfactory service from his network operator. The meeting continued with discussing the new encapsulated tunneling code. The original code is a seriously bastardized use of LSRR seriously violating the IP specifications. The new mrouted supports both, defaulting to encapsulation. There was talk of adding clean source routing options to the encapsulating code such that network operators could prevent tunnels from moving to fall back infrastructure during network failures. Most of the rest of the meeting was spend drafting a wish list. Some of the items are appropriate for a future meeting of this BOF or WG. Other items are appropriate for specific groups or projects involved in multicast research. The items are ordered by priority within each section, but the sections are independent of each other. Throughout the discussion it was understood that resources are tight, and in many cases we were asking people to contribute effort without additional support. The wish lists were presented to both the AVT Working Group and to the Operational Requirements Area Directorate (ORAD). There was general agreement that the items on the wish list are desirable and appropriate, but nobody agreed to implement anything. There were some network operators present at the ORAD meeting who were upset that the MBONE BOF did not become a WG or take stronger positions regarding operational practices. However most of these people were operators who had chosen not to participate in the mbone, and were therefore not in control of its impact on their own facilities. BGP Deployment Working Group (BGPDEPL) BGP-4 deployment: 2 ANS/NSFnet/GATED BGP4 is working in a test mode. CISCO BGP4 is under still under development. 3-COM Expects to support BGP4 in early this fall. Wellfleet Anticipates rolling out BGP4 support this summer. Telebit/EuropaNet No current plans for BGP4 deployment. CIDR core plans (Alternet, CIX, EBONE, NSFnet/ANS, NSI, PSI, Sprint): 1. Start deploying BGP4 code as soon as possible. 2. NSI (or some alternative) starts announcing one aggregated network. 3. Additional CIDR core members start aggregating networks. 4. Aggregation is officially ``turned on'' in the Internet. The members of the CIDR core are progressing as fast a possible, and are well coordinated among themselves. CIDR configuration issues: There is some controversy over how to do global configuration checking. In addition, how can we one ensure topology matches policy? Merit presented a preliminary plan for aggregation support in the NSFnet. This support would: 1) accept aggregate routes from a midlevel. or 2) would accept site routes from a midlevel, and aggregate on the midlevels behalf. A strawman database format proposal is documented in the ``Inter-domain Routing Policy Description and Sharing'' Internet-Draft (draft-yu-rpd.00.txt). The representatives from RIPE pointed out that the existing U.S. databases, including the current Merit configuration database and the above proposal are not adequate to solve international routing problems. In particular none can be used to determine which backbone (CIDR core member) is the preferred path to a given US network. The sense of urgency came primarily from concerns about configuration management and database issues. Although there is still a lot of work to be done to complete the BGP4 roll out, it seems to be a fairly well understood problem except for configuration management. CIDR and BGP4 do impose some new requirements on the databases but the majority of the issues center around topology and AUP enforcement. For theses reasons it makes sense to broaden the scope of this Working Group from just BGP deployment to the wider task of fostering sanity in topology, routing policy, and configuration databases. Network OSI Operations Working Group (NOOP) 3 Russell Blaesing talked about his Transport MIB. He is going to put his implementation up for anonymous ftp. He is also going to submit a new version of the draft because the old one expired. The Group decided that it don't know if the MIB needed variables added or removed, so we will put it out there and see how it works. The Essential Tools for the OSI Internet was discussed. With some minor changes it is going to be submitted as a Proposed Standard. The Echo draft will also be submitted as a Proposed Standard. Work is going to be put into trying to keep the OSI infrastructure up and operational. Sue Hares is going to have one of her folks put the EON tunnel configuration up for anonymous ftp along with information about reachable CLNS hosts throughout the Internet. She will also try to get someone to start pinging these hosts (via CLNS) and sending mail if there are outages. The deployment of TUBA was discussed. Several implementations are available and folks are interested in trying them. The Group concluded that unless there is more work that needs to be done with the deployment of TUBA that NOOP will probably suspend their work for a time until they are needed again. Operational Requirements Area Directorate (ORAD) The ORAD mandates were discussed. It was agreed that ORAD was a good forum for discussing operational related items among network service providers. Thus the purpose of the meeting should be to coordinate operation of individual networks, not to change each networks own policy. It was pointed out that many Standard RFC's have fallen through the cracks towards complete implementation without operational concerns have been addressed. John Curran agreed to make sure that at least a fraction of new RFC's are read for operational impact. Bill Manning agreed to do some reviewing, but cannot do the whole job himself. There is a need for a working group to deal with a policy routing description language, Many of the routing efforts (BRG, SDRIP, etc.,) are defining a need for a common routing policy language. ORAD needs to form a liaison with the protocol developers to help define such a language. The Operations Area working groups were discussed and a new scheme were proposed by Dan Long. The intentions and actual planning according to this scheme will continue on email. The need for a tunnel coordination working group was discussed. There are MBONE tunnels which could be removed. TUBA tunnels may in the future need coordination for the same reasons. ORAD did not see a need for such a working group in the immediate future. 4 CIDR issues were treated with respect to timeliness. Will CIDR deployment be in time before router hard- and software start to hit the limits or has this already begun to happen. There is a need to find adequate measurements here. ANS is doing some investigation within this area. Operational Statistics Working Group (OPSTAT) Reports on current effort in deploying the OPSTAT model (RFC1404) revealed some work. RIPE NCC have a tool known as Monster which could be adapted but manpower is lacking. Craig Haney from Sprint has written a PERL parser. Some other efforts are also known. FARNET had promised funding if a site could be found to take on the implementation work. Some problems with the RFC1404 storage format were reported and it was decided to make the necessary changes to fix them. Henry Clark from OARnet has done some implementation work of the OPSTAT client/server draft specification. This was discussed and Ittai Hershman/ANS reported on a similar tool implemented by Merit. The specification of the client/server query language was extensively discussed. Finally it was agreed that the SNMP/MIB people should be contacted with respect to variables needed in statistical gathering but which as of today are not present in the Internet Standard MIB. 5