Editor's Note: Minutes received 12/7/92 CURRENT_MEETING_REPORT_ Reported by Gene Hastings/PSC Minutes of the Operational Area Directorate (ORAD) Recruiting of ORAD Members What is expected of recruits? o Provide guidance as to what needs attention (what WGs need to be formed?) (Example: mbone coordination) o Provide guidance to working groups in other areas, e.g. BGP Deployment and IPv7. For example Network Management and SAAG explicitly assign people to working groups. o Document review. Particularly early on, i.e., I-D, etc. As things are going in the POISED Working Group, it looks like the direction is for the IAB to delegate more of its activity and responsibility to the IESG which will increase the need for area advisory groups like ORAD. Two kinds of review: - All kind of Operations working group documents. - Selected review of other area groups (like ROAD stuff, etc.). Discussion There is a need for an explicitly nominated ORAD membership as distinct from the open ORAD meetings at the IETFs. This closed group will be responsible for the above listed topics. It is for example not necessary that those part of the ORAD personally have to review documents but that they shall see to that such a review is made. Current Operations Area working group Chairs could be part of ORAD but this is not implicitly required. There is necessary with a group of people that have the interest and time to undertake the ORAD responsibilities. There is a need for a method of flagging documents for ORAD review. If enough ORAD members thinks it needs ORAD review one member is assigned the responsibility to see that this happen. To make ORAD having broad coverage it will be necessary to invite operators that traditionally do not participate at IETFs. Interested in ORAD participation: 1 Tony Bates University of London Nevil Brownlee University of Auckland Henry Clark OARnet Michael Conn MCI John Curran NEARnet Phill Gross Advanced Network and Services, Inc. Daniel Karrenberg RIPE NCC Peter Lothberg EBONE Bill Manning SESQUINET Bernhard Stockman SUNET Evan Wetstone SESQUINET Christopher Wheeler University of Washington Proposed Charter 1. What is the ORAD (and what is it not). 2. Forum for OPs groups. 3. Development of methods and practices. 4. Guidance and review. 5. OPs information and education. The need for a backbone requirements document was discussed. There is value to documents outlining needs, services, and interoperation, but if it is too proscriptive, they may fail to accommodate all economic or organizational models. The meeting concluded that ORAD should not start off too big but initially concentrate on document review and presentation of issues to working groups. Discussion around MBONE Coordination There is a need to increase multicast performance in today routers Matt Mathis volunteered to track MBONE contacts for the subversive purpose of collapsing connections to the highest level possible. The right thing to do is prevent the mbone from being heavily used until mrouted is fixed. If the operators were to turn it off, however, there would be a grass roots mbone appearing which we would have NO control over. 2 ORAD should issue a statement of recommendations on mbone utilization, requirements and operation. In the meantime, can we get debugging tools, can we get multicast support from vendors? Architectural weakness: 25 speakers at once fills a T1. This would create a situation of denial of service. Mrouted needs more knobs. Must be able to do route pruning. Action items for mbone: o Major mrouted work o Get together and list some bullets to take to Steve Deering and Steve Casner. o Remove redundant tunnels. o Public versions released as receive-only? o Restrict to one audio and one video until more experiences. o More tests and freeze of topology. Tests shall happen before IETFs which includes announcements of tunneling and requests to be made further in advance of conferences. Strict cut-off date after which no more tunnels Others actions: o Need for more efficient diagnostic tools. o mrouted related work. - Put throttling in the tunnels. - Treatment for misconfiguration (view others' configurations). - Pruning of the tree (no more than 12?). - Encaps, not LSRR. - Experiment with one-way path. - Encourage codings which conserve bandwidth. - Experiment outside of IETF meetings. The Working Group needed to flesh these out with representatives from Merit, PSC, NEARnet. Attendees Tony Bates t.bates@nosc.ja.net Rebecca Bostwick bostwick@es.net J. Nevil Brownlee nevil@aukuni.ac.uz Henry Clark henryc@oar.net Michael Conn 4387451@mcimail.com John Curran jcurran@bbn.com Hans Eriksson hans@sics.se Dennis Ferguson dennis@ans.net 3 Richard Fisher rfisher@cdhf1.gsfc.nasa.gov Peter Ford peter@goshawk.lanl.gov Phillip Gross pgross@nis.ans.net Robert Gutierrez gutierre@nsipo.nasa.gov Eugene Hastings hastings@psc.edu Alisa Hata hata@cac.washington.edu Daniel Karrenberg daniel@ripe.net Mark Knopper mak@merit.edu Daniel Long long@nic.near.net Kim Long klong@sura.net Bill Manning bmanning@sesqui.net Dennis Morris morrisd@imo-uvax.disa.mil David O'Leary doleary@cisco.com Andrew Partan asp@uunet.uu.net Marsha Perrott mlp+@andrew.cmu.edu Bernhard Stockman boss@ebone.net Marten Terpstra marten@ripe.net Evan Wetstone evan@rice.edu Chris Wheeler cwheeler@cac.washington.edu Paul Zawada Zawada@ncsa.uiuc.edu 4