Operational Requirements Area Director(s): o Scott Bradner: sob@harvard.edu Area Summary reported by Scott Bradner/Harvard University The one BOF held under the Operational Requirements Area was: o Generic Internet Service Specification (GISS) The working groups currently open in the Operational Requirements Area are: o Benchmarking Methodology Working Group (BMWG) o BGP Deployment and Application Working Group (BGPDEPL) o Network Joint Management Working Group (NJM) o Network OSI Operations Working Group (NOOP) o Operational Statistics Working Group (OPSTAT) o User Connectivity (UCP) BGPDEPL and OPSTAT met in Amsterdam. Generic Internet Service Specification BOF (GISS) A presentation was given on the current GISS work. The document, aimed at service providers, has undergone many changes since the previous BOF. The consensus of the group was that a document of this type is badly needed by service providers, but the proper location for the work is in an ``operators forum,'' rather than an IETF working group. Until a global operators forum comes into existence, the IETF seems to target the correct audience. The chair will talk to Scott Bradner, the Area Director of the Operational Requirements Area, about forming a working group. A prospective charter was discussed. The group is changing its name from ``GISS'' to ``GISD'' for Generic Internet Service Description. BGP Deployment and Application Working Group (BGPDEPL) A summary of CIDR deployment, including both route aggregation and IP address assignment, was presented. The current plan for CIDR deployment 1 is: 1. Deploy BGP4 without aggregation 2. Advertise test aggregated route 3. Aggregate at the site level or single policy level, whichever is a smaller block 4. Understand more 5. Aggregate more Steps four and five will be repeated, one after the other, until CIDR is fully implemented. The group agreed that IBGP doesn't scale to very large numbers. However, it is currently tractable, and will be supported for a while, but the group should consider options for the future. It was suggested that another aggregation rule should be added saying that no network should aggregate routes without informing other networks; a route aggregate registry could provide a means for communicating this information. It was also suggested that de-aggregation should not be done in the initial stage. This should not cause a problem since initial aggregation will only occur at the site level or single policy level. ANS, 3com, cisco, Proteon and Wellfleet were all asked about the status of their CIDR implementations. Feedback was requested on BGP4 interoperability tests so that the interoperability matrix could be updated and sent to the list. A syntax for registering route aggregates was presented. Several people volunteered to write a paper analyzing the effectiveness of CIDR to be ready by September 1993. There was a discussion on both the effectiveness and complexity of renumbering. Further analysis will be done. Operational Statistics Working Group (OPSTAT) The chair of the working group was unable to make the meeting, and the agenda was shortened as a result. The ideas about the client/server strawman developed at, and since, the last meeting need to be incorporated into the strawman. Henry Clark volunteered to do this and send the result to the list. 2