|
I
guess, one thing we, definitely need to decide is boundary (in terms of the OSI
layers) of work. My default understanding is
MAC
layer but, we know that issues like priority and basic queing (of data &
control messages) require
the
boundary to extend towards data link. Also for ring protection, we may need
parameters, including
link
status which may take us to PHY too. Since we do not control all layers, we need
to decide
one
layer as our dominant area of work (I pre-assume MAC+ any additional sub layer)
and other in liasion capacity
(like
10G Ethernet group on PHY and IETF for networking/data
link)
Regards,
Devendra Tripathi
VidyaWeb, Inc
90 Great
Oaks Blvd #206
San Jose, Ca 95119
Tel: (408)226-6800,
Direct:
(408)363-2375
Fax: (408)226-6862
Bob,
I
guess I was not entirely clear. I agree that it may be premature to decide
what should be in RPR and what should not. Having said that, I believe that
agreeing on terminology and what each statement (in the requirements) means
will take us a long way ahead. I believe that it would be difficult to work on
a standard when we can't have at least a common language. I have already
encountered cases (in our group) where a certain word meant one think for one
person and another for someone else. In general, I believe it is unhealthy to
prolong such a situation.
Offer
Offer Pazy
Sr. Product Manager
Native Networks
15 Gonen St.
Petah Tikva 49170
Israel
The
Native Way = Ethernet Simplicity + SONET Reliability
In reply to Offer Pazy's note attached, let me
express my point of view, which includes a belief that we must define our
requirements in a systematic fashion:
Based on almost two decades of deep involvement
in standards creation, it is my strong belief that an early discussion that
attempts to lock down what requirements are will produce a huge amount of
discussion, but few answers. It is also likely to help polarize
positions, making it more difficult to develop resolution later
on. Frankly, I am concerned that
it is too early to decide on any but the very highest level objectives at
the January interim meeting. In addition, we do have other very high
priority tasks in front of us, including the agreement on how we will move
this standards development process forward.
Certainly, we can include a discussion of high
level objectives at the January meeting. If there is time, we can
begin to drill down to see if there are areas where we have concensus.
I would be adverse to any lenghy discussions to defend positions at this
meeting. Rather, I would prefer to note where there are multiple
opinions, and document the different directions we may decide to take, so we
can solicit email discussion and papers at future meetings to help resolve
the issues.
Offer, I understand that it can be frustrating
to focus on process when there are real problems out there that need to be
solved, and decisions that must be made. In addition, we must not
spend too much time organizing, thereby losing time precious development
time. I propose that taking next weeks meeting to define the playing
field, and the rules, and to understand where the issues are, rather than
attempting to resolve them will prepare us to move quickly on resolving
issues from that point on.
Best regards,
Robert D. Love President, LAN Connect Consultants 7105 Leveret
Circle Raleigh, NC 27615 Phone: 919
848-6773 Mobile: 919 810-7816 email:
rdlove@xxxxxxxx
Fax: 720 222-0900
----- Original Message -----
Sent: Saturday, January 06, 2001
12:40 PM
Subject: RE: Jan 15-17 meeting. I'm
confused, please help
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
The
Native Way = Ethernet Simplicity + SONET
Reliability
Rob,
Thanks. I was trying to get the logistics. Here
is what I read from your comments
For us to complete the standard there are many
sections and sub sections to be written.
Before that can be done there are many proposal
to evaluate.
Before that can be done there are the
objectives and scope.
I propose a framework and then identify the
scope and objectives....
Network
single
Ring
Interconnected
Rings
Bridges and
router
MAC Layer
Data path
function
forwarding
filtering
error correction/detection
Control
Plane
header
definition
network size
header field definition
customer separation
header bit definition
L2
functions
Node
discovery
Fairness
L3
interface
L1 management
I/F
L1
control
L1
Interfaces
Generic Packet interface
SONET
SDH
Gigabit Ethernet
DWDM
Digital Wrapper
Network Applications
Ring
interconnect
Transparent LAN
Service
ISP
Harry, here is my 2¢ on this one: I would
expect us to continue to refine our detailed scope and objectives,
going much further than the PAR input. I anticipate that 802.17
will be doing a significant amount of voting at the March plenary
meeting, some of which will be establishing things like
objectives. Hopefully a great deal of the work will have been
done ahead of time, including at the upcoming meeting, and via email
discussion. All of this work should fundamentally build on what the
Study Group has previously decided, even though the Study Group's
output is not binding on the decisions of the Working Group.
I don't know how much time will be
available at the January interim meeting to address the issue of
refinement of the Scope and Objectives. If there is time, I
think the topic will fit well with the meeting's overall
focus.
Best regards,
Robert D. Love President, LAN Connect Consultants 7105
Leveret Circle Raleigh, NC 27615 Phone: 919
848-6773 Mobile: 919
810-7816 email: rdlove@xxxxxxxx
Fax: 720 222-0900
----- Original Message -----
Sent: Tuesday, January 02, 2001
11:40 AM
Subject: Q: Jan 15-17
meeting
mike:
Are you gathering scope an objectives to
help defining the tasks in the schedule to complete the
standard?
Some of the scope were
discussed in previous meetings. Now that we are a WG are we
recapturing and additional detail scope
and objectives as confined in the PAR and
5 Criteria?
Regards,
Harry
|