Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

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