home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1997 December
/
Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso
/
ietf
/
orad
/
orad-minutes-92nov.txt
< prev
next >
Wrap
Text File
|
1993-02-17
|
6KB
|
196 lines
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