RE: [RPRWG] Wait To Restore
Bob (and others),
I appreciate your encouragement of the P802.17 editors and also your
recognition of their hard work. Their progress is particularly
noteworthy when considering that most of them have had no previous
802 standards experience at all.
I also echo your concern that there are significant portions of the
draft that could be made clearer and easier to read. However, this
will take time. In addition, note that the P802.17 draft text is
produced by EDITORS, not AUTHORS. This distinction is actually quite
important. As editors, the team does not have the power to dive in
and arbitrarily modify large masses of text that they deem to be
unclear or unreadable. Instead, they are constrained to implement the
instructions of the WG (as expressed in resolved comments and
accepted proposals), and further constrained to refrain from making
changes that are not authorized by the WG. Therefore, quite apart
from the fact that all the editors have day jobs unrelated to improving
the draft text for P802.17, they are not even empowered to make changes
to the draft text willy-nilly in order to enhance readability.
In light of this, therefore, I have the following constructive
suggestion to the WG members. When a paragraph (or page, or subclause)
is found that is difficult to understand, submit an editorial (not
technical, please!) comment identifying the specific portion of
text to be improved, and also offer one or more suggestions for how
it can be improved. Remember that the text in question may have been
the editors' best attempt at something that would clearly express
some concept. Simply requesting a rewrite is not going to help them
produce anything better. Specific suggestions would instead help them
to understand just why a particular piece of the draft is difficult
to comprehend and how it can be fixed. The existence of the comment
would then empower them to make the necessary changes.
Please do not submit technical comments demanding readability
improvements. Technical comments have to be debated within the WG
before anything is implemented; editorial comments are normally
covered under the editorial license that is customary at this stage
in the draft. If we are forced into lengthy debates about wordsmithing
within the comment resolution sessions, there will be no time left
for dealing with the real technical issues that must be closed. (In
addition, after extended wordsmithing it is not unusual to wind up
with even more of a camel than when you started out!) If a WG member
has specific concerns about the wording of a paragraph, then he or she
should submit an editorial comment, and later get in touch with the
respective editor in order to ensure that the comment is addressed in
a proper and satisfactory manner.
Best regards,
- Tom Alexander
Chief Editor, P802.17
-----Original Message-----
From: Robert D. Love [mailto:rdlove@xxxxxxxxx]
Sent: Wednesday, August 07, 2002 12:12 PM
To: djz@xxxxxxxxxxx; John Lemon; George Suwala; stds-802-17@xxxxxxxx
Subject: Re: [RPRWG] Wait To Restore
David, with regard to your comment:
> If you are not familiar with Clause 11, this discussion
> will make no sense.
"The point I was trying to make is that I have tried to read
Clause 11 and it is very difficult to do so. If that is true
of others, as well, then the clause may not be getting the
level of review that is desired."
I entirely agree with you. Draft 0.3 was the first draft that I focused on
reading through with understanding. Although I did make considerable
headway, there are still significant areas that will require at least one
and perhaps more readings to understand well enough to raise important
issues. I too am concerned that all 802.17 standard authors need to strive
to make the document clear to the uninitiated, so that it can be reasonably
reviewed by people that have other jobs than just reviewing the standard.
Having been on the writing end of standards, I realize that I am asking a
lot from our hard working authors. It generally takes longer and
significantly more effort to make the document clear. In addition, those
close to a particular issue need to be able to mentally stand back to see
what requires more explanation. Still, that is what all the authors need to
strive for.
To the authors: Thank you for your diligent efforts to date. Consider this
note a plea to persevere and continue to strive to make the document
exceptionally clear, especially for those of us that do not read it as
experts in the details of your clauses.
Best regards,
Robert D. Love
President, 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
----- Original Message -----
From: "David James" <djz@xxxxxxxxxxx>
To: "John Lemon" <JLemon@xxxxxxxxxxxx>; "George Suwala" <gsuwala@xxxxxxxxx>;
<stds-802-17@xxxxxxxx>
Sent: Tuesday, August 06, 2002 1:54 PM
Subject: RE: [RPRWG] Wait To Restore
>
> John,
>
> Thanks for the responsive note. A few minor points, however.
>
> > You'll find these all defined in Clause 11.
> Should also be defined in 3.1, I believe.
>
> > Quickly, WTR = Wait To Restore, SF = Signal Fail.
> Thats the acronym listing, not the functional definition.
> Both are needed.
>
> > If you are not familiar with Clause 11, this discussion
> > will make no sense.
> The point I was trying to make is that I have tried to read
> Clause 11 and it is very difficult to do so. If that is true
> of others, as well, then the clause may not be getting the
> level of review that is desired.
>
> DVJ
>
>
> David V. James, PhD
> Chief Architect
> Network Processing Solutions
> Data Communications Division
> Cypress Semiconductor, Bldg #3
> 3901 North First Street
> San Jose, CA 95134-1599
> Work: +1.408.545.7560
> Cell: +1.650.954.6906
> Fax: +1.408.456.1962
> Work: djz@xxxxxxxxxxx
> Base: dvj@xxxxxxxxxxxx
>
> > -----Original Message-----
> > From: owner-stds-802-17@xxxxxxxxxxxxxxxxxx
> > [mailto:owner-stds-802-17@xxxxxxxxxxxxxxxxxx]On Behalf Of John Lemon
> > Sent: Monday, August 05, 2002 7:25 PM
> > To: 'djz@xxxxxxxxxxx'; George Suwala; stds-802-17@xxxxxxxx
> > Subject: RE: [RPRWG] Wait To Restore
> >
> >
> >
> > David,
> >
> > You'll find these all defined in Clause 11. Quickly, WTR = Wait To
Restore,
> > SF = Signal Fail. If you are not familiar with Clause 11, this
discussion
> > will make no sense.
> >
> > jl
> >
> > -----Original Message-----
> > From: David James [mailto:djz@xxxxxxxxxxx]
> > Sent: Monday, August 05, 2002 4:40 PM
> > To: George Suwala; John Lemon; stds-802-17@xxxxxxxx
> > Subject: RE: [RPRWG] Wait To Restore
> >
> >
> > Guys,
> >
> > I really appreciate these attempts at interation though email,
> > which has the promise of relieving next-meeting congestion.
> >
> > However, I would like to understand and (if time allows)
> > contribute some thoughts on the topic. Although my expertise
> > is in different areas, many of the issues are similar on
> > mini-networks (backplanes) and metro-networks.
> >
> > For me, the conversation would help if the acronyms were
> > a bit less persuasive, as I (and some others, I suspect)
> > are not necessarily aware of the WTR or SF acronyms,
> > much less their functional definition.
> >
> > The problem is, of course, compounded by this being
> > a portion of the document that needs alot of refinement,
> > as its quite hard for (at least some of) us to understand.
> >
> > Could you perhaps provide a bit of an intro when
> > broadcasting these and looking for feedback. That
> > would help for us less enlightened.
> >
> > DVJ
> >
> >
> > David V. James, PhD
> > Chief Architect
> > Network Processing Solutions
> > Data Communications Division
> > Cypress Semiconductor, Bldg #3
> > 3901 North First Street
> > San Jose, CA 95134-1599
> > Work: +1.408.545.7560
> > Cell: +1.650.954.6906
> > Fax: +1.408.456.1962
> > Work: djz@xxxxxxxxxxx
> > Base: dvj@xxxxxxxxxxxx
> >
> > > -----Original Message-----
> > > From: owner-stds-802-17@xxxxxxxxxxxxxxxxxx
> > > [mailto:owner-stds-802-17@xxxxxxxxxxxxxxxxxx]On Behalf Of George
Suwala
> > > Sent: Wednesday, July 31, 2002 10:51 PM
> > > To: John Lemon; stds-802-17@xxxxxxxx
> > > Subject: RE: [RPRWG] Wait To Restore
> > >
> > >
> > >
> > > John,
> > >
> > > While I agree on the WTR usage and it's role I see 2 differences
> > > between dampening through WTR and dampening through holding down link
> > > as a Signal Fail (SF):
> > >
> > > 1. Signaling to other nodes: when the link is in SF dampening, the SF
> > > is advertised to other nodes without any state transitions (even
> > > if the actual link keeps going up and down). When there is a WTR
> > advertised
> > > and a change takes place to SF (link down), the SF should be
advertised
> > > ( I agree there is no change to steering/wrapping and no flapping in
both
> > cases,
> > > but the signaling is different)
> > >
> > > 2. Reaction by other nodes: other nodes (and even the node which
dampens)
> > > will react differently to other ring conditions. For example if there
is
> > > a Signal Degrade (SD) elsewhere, WTR will be removed and SD actions
> > > (steering/wrapping) will take place. However if a link is dampened
through
> >
> > > holding down the SF, as SD elsewhere on a link will be ignored.
> > >
> > >
> > > So I see the dampening through SF as a solution which augments
> > > WTR without replacing WTR or being replaced by WTR.
> > >
> > > We could leave mentioning of the SF dampening out of the standard and
let
> > the
> > > users/implementors think of it any way they like, but since
> > > Manav has brought up the dampening algorithms I suspect that
> > > mentioning the SF dampening (as being outside of the standard but
> > > allowed at implementor's discretion) may be a clarification of some
value
> > >
> > > thanks
> > >
> > > George
> > >
> > >
> > > At 06:03 PM 7/31/2002 -0700, John Lemon wrote:
> > > >George,
> > > >
> > > >I guess I don't see the difference. I think the main usage for WTR is
to
> > > >avoid link flapping. (One would dampen by moving to WTR state, not by
> > > >remaining in SF state. See, for example, D0.3, page 115, line 3.)
(Are
> > there
> > > >any other uses for WTR?) The only new idea being introduced is
possibly
> > > >changing the value for the WTR timer based on recent events on the
link,
> > > >which I think we all agree should be possible, but handled outside of
the
> > > >standard.
> > > >
> > > >jl
> > > >
> > > >-----Original Message-----
> > > >From: George Suwala [mailto:gsuwala@xxxxxxxxx]
> > > >Sent: Wednesday, July 31, 2002 3:52 PM
> > > >To: John Lemon; 'Leon Bruckman'; stds-802-17@xxxxxxxx
> > > >Cc: 'Manav Bhatia'
> > > >Subject: RE: [RPRWG] Wait To Restore
> > > >
> > > >
> > > >John,
> > > >
> > > >I agree with you about leaving the current WTR text as is.
> > > >
> > > >However Manav has brought up a good point and it may help
> > > >if we differentiate between 2 concepts:
> > > >
> > > >1. WTR, which says to the other nodes: "the link is fine, but I'm
> > choosing
> > > >not to use it yet"
> > > >
> > > >2. Damping of flapping of a link by keeping it in a "down" state,
which
> > > >says to the other nodes: "the link is down".
> > > >
> > > >Point 1 and it's dampening effect has already been covered in this
thread
> > > >(I think :-)
> > > >
> > > >Point 2. Such damping has only local significance and it should not
> > > >introduce interoperability issues as each node uniquely controls
> > > >it's own interface state.
> > > >
> > > > From the protocol perspective it is immaterial to this and other
nodes
> > > >if a link is declared Signal Fail (SF) because a fiber has no signal,
> > > >or because fiber receives a perfect signal but interface circuitry
> > > >failed and is unable to interpret it correctly, or because the node
> > > >made an arbitrary decision to keep the interface in a SF state.
> > > >
> > > >It is common for a SF condition to be detected
> > > >by software through an interrupt which is a subject to interrupt
> > > >throttling which in fact dampens the SF state changes.
> > > >
> > > >So perhaps, while keeping the WTR text unchanged, we could
> > > >add some text to the effect of: "The interface state changes
> > > >may also be dampened by a local station by keeping the interface
> > > >in a Signal Fail condition while the state changes frequently.
> > > >The definition of "frequently" and the dampening algorithm are
outside
> > > >of the scope of this standard as they have no impact on the RPR
protocol"
> > > >
> > > >What do you think?
> > > >
> > > >(I don't think that we should be trying to standardize the dampening
> > > >algorithm or parameters)
> > > >
> > > >thanks
> > > >
> > > >George
> > >
> > >
> >