Re: [mpls] proposed drafts for aligning MPLS-TP PSC linear protection protocol to transport requirements

[Huub van Helvoort <[e-mail]>]

Hello Eric,

You wrote:

> Thanks for this; the threads I started some time back seem to have
> died down, it's good to get them going again.

There was atwo week ITU-T plenary meeting, and after that I took
(and still have) a holiday.

> I have two things I never quite understood, can you clarify them
 > for me?

OK, I'll try. See in-line [Huub]

> i) can you explain EXER at a higher level?  I'm not looking for a
> description of the state machine changes, and I'm not looking for the
> one line "It allows the FSM to be tested".  We have all of that in
> the draft and in the equivalent ITU specs.
>
> What I'd like to understand about EXER is where it came from.  The
> ITU specs that define it are pretty hard to follow, they seem to
> assume the reader already knows what EXER is and what problem it
> solves.  It feels very much like a mechanism used to catch a very
> specific implementation bug, back when transport gear was far less
> debuggable than what we have today.

[Huub] EXER was not designed/intended to be used for bug finding
although it will detect problems with implementation.

[Huub] EXER was designed to verify that the state-machine at the
far end is able to respond to APS/PSC messages it receives from
the local end.
Even though state-machines should be tested extensively, there is
no 100% warranty. It can still have stopped due to external
circumstances, be in a deadlock due to unforseen order of events,
etc.

[Huub] note that APS/PSC should continue to operate even if no
control plane is available. The EXER is to enable an operator to
take corrective action before a protection switch request fails
and the 50ms switch time is not met.

> No other state machines that I'm familiar with (RSVP, LDP, BGP, OSPF,
> ISIS) have explicit signaling in them just to ask the neighbor
> whether it *would* be broken if if were, in the future, to be given a
> particular input.

[Huub] All these rely on a control plane, some of then include
"keepalive" messages to see if the far end responds.

> Part of my reluctance to get behind EXER has been
> that I don't feel comfortable with the idea of keeping a 30-year-old
> workaround in a protocol.

[Huub] it is NOT a workaround, it is an essential part of the
protocol.

> Is there more to it than that?  Have I
> misread and misunderstood EXER?  Does modern transport gear ever
> actually detect a problem via EXER/RR that wasn't obvious to the
> operator using other means?

[Huub] if there is no control plane I have no other means.
What means are available to verify if a state-machine that is
in a stable state is still functioning?

> ii) Why the push to standardize the SD state changes before we've
> defined SD?  I certainly agree that handling signal degrade is a good
> idea, but coming up with a definition for it has been challenging.
> What happens if we change the FSM to handle it, then come up with
> something more sophisticated (say, multiple levels of SD) that
> doesn't quite fit with the FSM changes?

[Huub] the definition of the signal degrade defect that causes the
SD event for the APS/PSC is still under discussion, but the APS/PSC
response to an SD event should be included. If we don't do it now
we have to issue another version of PSC later with all kinds of
backwards compatibility issues, additional complexity, and options
that operators do not like to have to manage.

[Huub] APS/PSC now responds to an SF event, based on detected
signal fail defects. However in the future we may extend the
signal fail defect by another probable cause. This will not
affect the existing APS/PCS.

Regards, Huub.



-- 
*****************************************************************
               请记住，你是独一无二的，就像其他每一个人一样