Re: [RPRWG] Wait To Restore
Tom, thank you for your reply and helpful suggestions. I have one further
suggestion for the editors themselves, in addition to other knowledgeable
readers. I urge all editors to read the text they have been instructed to
write with an eye towards how easy it is to understand. If you believe that
a rewrite would improve the text, then as editor, please submit an editorial
comment including as extensive a rewrite as you believe is necessary to
improve legibility. I have two caveats that go along with this request.
The first is that such proposed rewrites be posted on our reflector or web
site in such a way as to give everyone an adequate amount to review time.
The second is to scrupulously refrain from including any technical changes
in those rewrites. Instead keep the technical changes separate, possibly
submitting a second technical comment that contains the technical changes
within the rewrite, with those technical changes highlighted. Thank you.
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: "Tom Alexander" <Tom_Alexander@xxxxxxxxxxxxxx>
To: "'Robert D. Love'" <rdlove@xxxxxxxx>
Cc: <stds-802-17@xxxxxxxx>
Sent: Wednesday, August 07, 2002 4:45 PM
Subject: 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
> > > >
> > > >
> > >