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
> > >
> > >
> >