Re: (M2PA) Initial version of M2PA IG is Now Available

Andrew,

Andrew Booth wrote:                                                (Tue, 30 May 2006 12:55:07)
> Hi Brian,
> 
> I appreciate that minimal corrections leave less room for errors, but I
> think your recommendation on its own may be a bit too subtle.
> 
> What I do like about Jeff's description is that the issue under
> discussion is very clearly laid out, that page of text is informative
> only and hence has a minimal risk of introducing errors.
> I don't see any errors introduced in Jeff's proposed text, but if
> minimal changes are desirable perhaps the following (it may be possible
> to shorten things up even more):
> 
> 2.5.3.        Text Changes
> 
>    Original Text (4.1.3. Link Alignment)
>    ---------------------------------------------------------------------
>    The Link Status Ready message replaces the FISU of MTP2 that is sent
>    at the end of the proving period.  The Link Status Ready message is
>    used to verify that both ends have completed proving.  When M2PA
>    starts timer T1, it SHALL send a Link Status Ready message to its
>    peer in the case where MTP2 would send a FISU after proving is
>    complete. If the Link Status Ready message is sent, then M2PA MAY
>    send additional Link Status Ready messages while timer T1 is
>    running. These Link Status Ready messages are sent on the Link
>    Status stream.
> 
>    In the case that MTP2 sends an MSU or SIPO message at the end of
>    proving, M2PA SHALL send (respectively) a User Data or Link Status
>    Processor Outage message.
> 
>    New Text
>    ---------------------------------------------------------------------
> 
>    (Paste in old text here).
> 
>    While timer T4 is running, M2PA SHOULD mark reception of either a
>    Link Status Ready message or a Link Status Processor Outage message.
>    Upon expiration of timer T4, M2PA SHOULD check whether a Link Status
>    Ready message or a Link Status Processor Outage message was
>    received, and if either message was received, M2PA SHOULD NOT start
>    timer T1 and instead SHOULD operate as if the message had been
>    received after timer T1 had been started. If neither message was
>    received during proving, then M2PA SHOULD start timer T1 and proceed
>    according to the applicable MTP2 standard.
> 
> Brian, Jeff, any thoughts on this?

Several problems with that text.  It misses User Data (MSU) which is an
appropriate way of completing alignment.

Also, it does not indicate that when configured for proving either a
Link Status Proving Normal message or a Link Status Proving Emergency
message must be received before the LS Ready, LS PO or User Data can
be considered valid.  Also, the messages must contain the correct sequence
numbers to be considered valid as well.  It is not just the fact that
T4 is running that makes these messages valid.

This is the problem we faced when we developed the RFC: if you start
describing part of the state machine, you wind up describing large portions
of it, duplicating one standard.  There are subtle differences between
standards even during alignment.  ANSI and ITU SDLs are different in this
regard, and that is not even considering TTC.

I would be safer to say that the LS Ready replaces the FISU(s) sent after
proving.  If you want, stress the fact that once the LS Ready is sent, the
receiver should consider it in lieue of any FISU that might have otherwise
been sent after T4 expires.

--brian

-- 
Brian F. G. Bidulock
[email protected]
http://www.openss7.org/