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

["Eric Osborne (eosborne)" <[e-mail]>]

Inline with EO#, trimmed a bit.

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

If you're on holiday, why are you working?  I thought that was a uniquely American trait.  Is this stuff that much fun to you? :)

...

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

EO#  I agree with your last two statements.  To me, though, that very text is a reasonable argument against EXER.  There is no mechanism within a protocol which can guarantee that the entire state machine is 100% perfect.  A node could be able to respond to EXER/RR but be unable to process a real failure properly, either due to bug or to (as you indicate) some unforseen combination of external events.  The class of problems which EXER can catch but which will not be detectable by other means (e.g. CC/CV, see below) seems pretty small.

In the transport world, what sort of problems does EXER _actually find_?  I'm not asking about things it _could_ find, but things that it *does*.

> 
> [Huub] note that APS/PSC should continue to operate even if no
> control plane is available. 

EO#  I agree, but this is not relevant to the discussion at hand.  Lots of work was done in TP to ensure that it would function without the ability to forward IP packets (which I think is what you mean by 'no control plane').  None of that has anything to do with the set of messages and states in PSC.

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

EO#  PSC has keepalives; see section 4.1 of rfc6378 - "The purpose of the continual messages is to verify that the PSC session is still alive."

The next sentence says "If no valid PSC message is received, over a period of several continual messages intervals, the last valid received message remains applicable."  As an implementor, what that means to me is that I time out only after the loss of a few retransmissions.  

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

EO#  In a TDM world, I can see this point.  APS is carried in the frame header, so the receipt of an APS message doesn't mean that there's any intelligence behind it as it could just be the hardware repeating the last APS overhead that it sent.  If a PSC message is sent it must have been sent deliberately, as during steady state we have periodic retransmissions.  Do you agree?

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

EO#  Periodic retransmission of current state by the remote side.  This performs the exact same function as a keepalive in any other protocol, and I think we agree that the keepalive function in protocols such as OSPF is sufficient to ensure the sanity of the remote end.  Many, many protocols use keepalives as a sort of belt-and-suspenders failure detection mechanism.  In the IP world these mechanisms are far, far less useful than they used to be as we now have BFD.  

That brings us to CC/CV.   Lots of work was done to ensure that it did not require IP to function.  I cannnot believe that any TP implementation would ship without some sort of CC/CV, and isn't that a strong enough mechanism to detect the failure of the remote end?


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


EO#
See my reply to Jeong-dong on this.  





eric



> [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.
> 
> 
> 
> --
> *****************************************************************
>                请记住，你是独一无二的，就像其他每一个人一样