Bob:
Thanks a lot for stressing the issue. May I add that the aim is not to
successfully choose either of two proposals, but to:
- Create a proposal that has best of all proposals, so
good features from different proposals are brought in to create a framework
for further discussions
- Keep the proposal as
independent of internal buffer design details as possible
I wouldn't want to go to January to vote on choosing one proposal - I'd
like to create a proposal out of all the proposals. And I'd like to add things
that are not currently present in any of the proposals. And I'd like to
continually enhance the proposal in subsequent meetings. It would be a
proposal we create, we own, and we become accountable for in case it doesn't
succeed.
Currently even we, just a bunch of people within a closed group, can't
agree on different buffer and fairness schemes and we see lots of holes in
different approaches. It would get worse when it goes to the industry.
As technology improves people would start putting more queues, one per node
and one per class, to give fine-grained QoS/CoS, and to avoid HOL problems. If
RPR freezes specs to the hardware level and doesn't allow use of advanced
techniques in traffic engineering, people will simply bypass it and move on.
Bob, may I propose that we don't even raise an item in January meeting to
vote on choosing one from many proposals, but to start work on a draft
document based on items from different proposals. Sometimes we may leave
two/three options to start with and complete the draft. Later we can review
the options and coalesce into one.
As long as there is a move to choose one proposal from many proposals,
proponents would continue to stick by their stand and try to win votes. They
will keep showing simulations after simulations ad nauseam, but not move an
inch from where they have been all along :-)
=Pankaj
RDLove wrote:
All, as we get ready for our upcoming January
interim meeting we need to redouble our efforts to bring the three RPR
proposals into agreement. There should be multiple avenues of
communication between the Alladin and Gandalf camps, and additional efforts
to integrate the DVJ proposal. I am concerned that moving toward
agreement is being hampered because too few people are
involved. We need to work
through differences and ideally develop a single proposal going into the
January meeting. My best technical judgment is that the group will
have a much better first draft if there is a single proposal going into the
January meeting, than if we arrive at a decision by voting. The reason
is obvious. Voting at a meeting does not allow the quiet reflection
time that a carefully crafted proposal can have that has been studied
closely over a more significant time period beforehand. In addition,
if we go into the January meeting with a single proposal, we will have the
entire meeting to focus on and potentially improve that proposal, rather
than arguing the merits of competing proposals or creating a new compromise
proposal. For the benefit of
all RPR stakeholders I implore everyone involved in this standards
development to study the existing proposals and seek out ways of bringing
them together. Best
regards, Robert D.
Love
Chair, Resilient
Packet Ring Alliance
President, LAN Connect Consultants
7105 Leveret Circle
Raleigh, NC 27615
Phone:
919 848-6773 Mobile: 919
810-7816
email: rdlove@xxxxxxxx
Fax: 208 978-1187