RE: [RPRWG] Wait To Restore
Please also note that the reflector has re-sent the
message below (dated July 31, 2002 10:51 PM) on Aug 5th,
so time-wise it arrived out-of-context of other messages in
the thread.
thanks
George
At 07:24 PM 8/5/2002 -0700, John Lemon wrote:
>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
>>
>>