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