CURRENT_MEETING_REPORT_ Reported by Bernhard Stockman/EBONE Minutes for the Operational Area Directorate (ORAD) Agenda o Operations Area Mandates - Operational standards - Operational Requirements - Operation Coordination - Review of standards o Coordination Issues - Routing - Policy Language - Routing Policy Registration o Coordination of Tunnels - MBONE - TBONE - *BONE o Operational Impact if IPNG o Class C Allocation Forecasts Side notes Do we need a single WG to handle issues regarding ``virtual Internets'' sitting on top of today's IP internet. How will the large blocks of Class Addresses allocated affect current routing platforms Operational Area Mandates Coordinations of network service providers; is it the job of the IETF? ``I can see no less biased venue.'' - Gene Hastings Historically the IETF has been a venue for providers to discuss the leading edge technology they have been deploying and to give developers feedback. 1 It seems as if providers are swamped by the rapid growth of the Internet. This forum allows providers to work on problems ``at the top of the list.'' As the Internet continues to grow, more ``fire-fighting'' resources may become available. At that time some other forum for NSP coordination may be appropriate... (i.e., Someone else may be willing to host such a forum.) Is it good to meet at the IETF? A great deal of technology of transfer takes place. If a separate operational venue is developed, it should collocate with the IETF. Another separate set of meetings would be poorly attended, as network operators have too many meetings to attend as it is. As for reading for RFCs. If the Operational Directorate read RFCs, would that alleviate some of the problems we have now? Many RFCs have fallen through the cracks towards complete implementation without operational issues being addressed (e.g., RFC1400). Informational RFCs need to be addressed as they don't follow a standards track. What about ``executive cooperation?'' A lot of informal agreements are made at the IETF meetings, but they can't be backed without network higher-ups agreeing to it. Thus the purpose of the meeting should be to coordinate operation of individual networks, not to change each network's own policy. A certain amount of consensus is built up in the operational area. The operational area seems to have fuzzy objectives and less concrete standards. NSP coordination actually also takes place within other organizations, e.g., FARNET. We'll continue to do things they way we are. If another forum develops, it would be wise to collocate it with the IETF meetings. One thing that ORAD needs to address is a mechanism to apply an ``ORAD seal of approval.'' There needs to be a mechanism to alert ORAD to [informational] RFCs which have significant operational impact. John Curran agreed to make sure that the job of reading at least a fraction of new RFCs for operational impact is handled. 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. It is possible that the Internet Working Group should be revived to deal with topology configuration. Such a group could form the liaison with the routing protocol developers to give input as to how develop future protocols. 2 Dan Long's proposed structure (areas to be addressed): o BGP Deployment - protocol/CIDR o IWG - NSP Routing Coordination o NSR - Growth o Tunnel OPS - Coordinate the deployment of things like MBONE, etc. o OPSTATS o NOOP o ORAD o UCP (???) - Gas running out - Possible to roll into NJM o Benchmarking - Bradner o NJM (new) - coordination of NSP, trading troubleshooting techniques, operational experience Three different types of working groups: 1. Exchanging Information 2. Coordinated/establishing operational procedures 3. Engineering standards (e.g., benchmarking.) 4. IWG/Tunnel Ops - Operational planning. 5. NJM/UCP/NOOP - Diagnostic procedures Tunnel Coordination No critical mass to form an MBONE engineering group. However, a number of different tunnel types may need to be organized to keep the collection of ``BONES'' melts down the Internet. MBONE seems to be causing operational problems. It is quite possible that this is the first of many other tunnel types which will appear again. Matt Mathis reported the happenings at the MBONE BOF. o General Issues o Procedures o Topology, Metric, and threshold engineering o Bandwidth Budget and policy o Infrastructure oriented tools (wish list) o Transport and application diagnostic tools (wish list) MBONE is only an example of very steep growth rates. It is hard to tell end users to not to use their connection whether it be MBONE, AFS, Internet Talk Radio, etc. At this point there is no need to address these issues with a working group, however it would probably be wise to hold some sort of meeting 3 before or at the next IETF. Discussion will be held on the ORAD list to organize such a meeting. Call C Allocation Forecasts Will CIDR save us in time to keep our routers from falling apart from too many routes? he number of Class C nets being allocated our quite high. The NSFNET routing table has grown at a rate of 6.5% per month. We'll probably see 10,000 routes by July. Is deploying CIDR going to save us? Which networks will hit the limit before CIDR is deployed? ANS feels their situation is undercontrol, but other service providers may feel the crunch. Controlled deaggregation may need to be dealt with for those providers who can't speak BGP4 but can't default. Ground rules need to be laid to define this policy. A mechanism also needs to be defined for negotiating the amount of aggregation which takes place between two networks. We're not sure when things will fall apart, so we may just have to deal with the problem when it occurs. All we can do is keep trying to get CIDR deployed in time and try to beat the clock. ANS is also performing tests with cisco and IBM routers to see how many routes can be flapped in and out before they suffer server performance degradation. Attendees Tony Bates tony@ripe.net Serpil Bayraktar sbb@noc.ans.net Erik-Jan Bos erik-jan.bos@surfnet.nl Rebecca Bostwick bostwick@es.net Douglas Carson carson@utcc.utoronto.ca Henry Clark henryc@oar.net David Conrad davidc@iij.ad.jp John Curran jcurran@nic.near.net Tom Easterday tom@cic.net Dale Finkelson dmf@westie.mid.net Francois Fluckiger fluckiger@vxcern.cern.ch Eugene Hastings hastings@psc.edu Alisa Hata hata@cac.washington.edu Ittai Hershman ittai@ans.net Steven Hubert hubert@cac.washington.edu Dale Johnson dsj@merit.edu Merike Kaeo merike@alw.nih.gov Daniel Karrenberg daniel@ripe.net Charley Kline cvk@uiuc.edu Daniel Long long@nic.near.net Kim Long klong@sura.net 4 Peter Lothberg roll@stupi.se Glenn Mackintosh glenn@canet.ca Bill Manning bmanning@sesqui.net Matt Mathis mathis@a.psc.edu Dennis Morris morrisd@imo-uvax.disa.mil Peder Norgaard pcn@tbit.dk David O'Leary doleary@cisco.com Andrew Partan asp@uunet.uu.net Brad Passwaters bjp@sura.net Kim Smith kas@noc.ans.net Bernhard Stockman boss@ebone.net Marten Terpstra marten@ripe.net Kaj Tesink kaj@cc.bellcore.com Claudio Topolcic topolcic@cnri.reston.va.us Curtis Villamizar curtis@ans.net Ruediger Volk rv@informatik.uni-dortmund.de Linda Winkler lwinkler@anl.gov Cathy Wittbrodt cjw@barrnet.net Paul Zawada Zawada@ncsa.uiuc.edu 5