| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Mike
and others,
After
reading the exchange below and Mike's tentative agenda, I'm a bit uncertain as
to what exactly we want to achieve in the upcoming meeting. It is clear to me
that significant portion of the time will (and has to) be dedicated to bringing
everybody new on board. We have only two days and the question is how to we make
sure that the rest of the time is used productively.
Let me
explain what I'm mostly interested in and what I believe should be the first
priority of the meeting: Requirements, Requirements, Requirements. I've been
spending a lot of time in the past two months explaining to people what RPR is
about. But beyond "dual-counter rotating rings", I could not say anything else
in any confidence. Most people understand the issues and ask questions regarding
specific capabilities. All I have now (and I believe this is all we have) is an
unflushed and unsorted list of very high-level "things" that I've copied from
some presentations and from the white board and it is not
enough.
It is
clear to me that the interim meeting does not make decisions and that nailing
down specific requirements may take a long time, but at least I would like us to
move in that direction.
If
possible, my goal for the meeting would be to come up with a requirements list
that is as specific as to be clearly understood by everyone leaving as little as
possible for ambiguity or "between the lines" meaning. I expect that some issues
will be controversial and I don't expect we resolve this at the meeting.
Nevertheless having such concise and clear list will help us all focus and
understand where we agree and where we don't. We can establish a convention on
how to mark such issues.
Just
as an illustration (I do not wish to start a debate on
these):
Fairness: Is the intention fairness within a node or within the
ring?
Congestion management/control: Is it management or control? Is it CAC
based (probably not)? Do we assume buffers or not?
Again,
these are just examples. Another outcome of such an effort will be to have one
list of requirements instead of several (there are some differences
between the various presentations and the list we've
prepared to the 802.3).
What
do people think? Is it the right time and important enough to focus on this in
the upcoming meeting?
Offer Pazy
Sr. Product Manager
Native Networks
15 Gonen St.
Petah Tikva 49170 Israel Tel: +972 3 921-0010 Ext. 229
Fax: +972 3 921-0080 pazy@xxxxxxxxxxxxxxxxxx http://www.nativenetworks.com The
Native Way = Ethernet Simplicity + SONET Reliability
|