RE: [RPRWG] Wait To Restore
John,
Good news! After careful re-reading of the 802.17 Draft and GR-253
I've noticed that my suggestion is already indirectly included in the Draft
through a reference to GR-253 which addresses is.
Please note Draft 0.3 Chapter 11.4 point 2):
"Explicit definitions of the SF triggers and SF clearing criteria for SONET
are provided in GR-253..."
And the GR-253 CR5-52 (e.g. page 5-24 in Issue 2 Dec 95):
CR5-52 "Line Terminating Equipment may be required to be designated
to reduce the chance or number of rapid protection switching
oscillations that could occur in multiple failure or degradation
situations where one or more of the failures or degradations is
intermittent" [...]
" Two methods that LTE could use to meet CR5-52 are:
. Delay clearing SD and SF conditions for approx 10 sec [...]
. Monitor how often an SF or SD condition is detected and cleared on a line
and "lock on" to that condition if it is detected more than x times in y
seconds. After the LTE has locked on to the condition, it would
consider that line to be in an SF or SD condition until it determines
that the intermittent failure or degradation is gone (e.g. it would clear
the SF condition when it has detected that the BER is less than the
SF clearing threshold and no hard failures have occured for z seconds)."
So since (for a careful reader :-) this suggestion is already covered
I don't think that we need to submit the comment in an explicit
way (unless others feel that it needs to be stated more directly). BTW - the current state machine does not need modifications - it would be
all in addition to the existing WTR behaviour to cover cases which
are not covered by WTR (e.g. multiple intermittent failures)
thanks
George
At 10:46 AM 8/1/2002 -0700, John Lemon wrote:
>George,
>
>I believe what you suggest would violate expectations currently set for
>802.17 and based on existing usage of WTR in SONET. But, if you believe this
>is the correct approach, then I encourage you to submit a comment against
>Draft 1.0 with your suggestions on how to modify the current state machine.
>I would vote against it because I believe it is important for a link with
>potential to flap to be brought out of WTR upon a real SF elsewhere. If we
>left the link in SF, it would falsely force a double break that is likely to
>not really exist. But, I have only one vote, and others may disagree with
>me.
>
>jl
>
>-----Original Message-----
>From: George Suwala [mailto:gsuwala@xxxxxxxxx]
>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