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

Hi,

Some comments and questions inline.

Brian F. G. Bidulock wrote:

>Jeffrey,
>
>Craig, Jeffrey wrote:                          (Sat, 27 May 2006 14:45:54)
>  
>
>>Brian, are you saying that it is obvious that M2PA implementers should
>>mark received LSR during proving? Please cite the section of the
>>applicable standard that mandates for MTP2 the equivalent procedure
>>during proving. Hopefully, your citation will apply to implementations
>>for which FISU is not sent continuously (as is the case for M2PA LSR).
>>    
>>
>
>MTP2 does not send Link Status Ready.  It has no such message.  RFC 4165
>states that Link Status Ready is used by each side to indicate alignment
>instead of the FISU [or MSU].  What it does _not_ say is to ignore Link
>Status Ready when T4 is running.  Doing so is simply someone's mishappen
>invention or just a bug of an implementation.
>  
>
I think the RFC does (implicitly) say to ignore LS Ready during proving.
If I recall correctly, MTP2 (q.703/T1.111.3) ignores FISU during
proving. Hence in the absence of specific text, M2PA should ignore LS
Ready during proving.

The successfull M2PA implementors seem to have figured out that this
doesn't work since M2PA is not required to repeat LS Ready the way MTP2
repeats FISU. I would guess that everyone has concluded that they should
accept LS Ready during proving.

That doesn't mean the RFC wording is correct. If an implementor's guide
does go forward I think it's worth including some clarifying text,
something similar to what Jeff has in section 2.5 of his document.

[snip]

>  
>
>>Brian stated:
>>    
>>
>>>Experience with SS7 makes me disagee.  Forcing a link to fail is bad, the
>>>result being increased message loss in the network.
>>>...
>>>This later is because failing the link before changeover will
>>>result in message loss.
>>>...
>>>I think that, asside from excessive delay of acknowledgement of actual
>>>MSUs, MTP3 should decide when to fail a blocked link.
>>>      
>>>
>>Un-bounded protocol waits are bad.
>>    
>>
>
>The wait is not unbounded: it is bounded by MTP3 T1.
>
>  
>
>>Sometimes it is necessary for M2PA to fail the link, and not receiving
>>LSR(1) for seconds after sending LSPR is one of those times.
>>    
>>
>
>MTP3 will fail the link in T1 (2 seconds).
>  
>
I don't follow you here, perhaps we're talking about different scenarios.

If an MTP3 (or an "implementation specific management function") has
sent "Local Processor Recovered" and "Flush" or "Resume" to MTP2 then it
perceives the link as "In Service". Hence T1 will either be cancelled
(short duration LPO) or have expired. In neither case is T1 running when
MTP3 starts to send Data on the link again. If at this point the remote
M2PA doesn't provide the expected LSR then any messages from MTP3 are
stuck in the M2PA TB, there is no primitive between M2PA and MTP3 that
notifies MTP3 of this "funny" situation.

The best you can hope for is that MTP3 will try to perform an SLT
procedure (which will fail) at the end of LPO before performing a
changeback, and hence will fail the link. I believe SLT is optional at
the end of processor outage though, so this isn't a complete solution.
If the SLT procedure is skipped, data from MTP3 will continue to
accumulate in the M2PA TB until "false link congestion" takes the link
out of service or another SLT procedure is fails (again, I IIRC the
periodic SLT procedure is optional, but practically it is used fairly
universally).

Aside: AFAIK, MTP3 doesn't fail a link after a time controlled
changeover, it just doesn't use it for traffic. Maybe that's just a
difference in terminology.

>>As Brian suggests, for the scenario to happen, something serious must
>>go wrong.  So why keep the link aligned when something has gone
>>seriously wrong?
>>    
>>
>
>I did not say that something was seriously wrong: I said that the only
>reason for a delay from a validated implementation was a transport
>delay.  As LSPR is sent in the data stream, this could simply be
>because of HOL blocking on user Data messages already queued for
>delivery to the peer by SCTP with a closed cwnd, not anything serious.
>  
>
It seems to me that this transport delay is a reasonable reason for
taking the link out of service (provided we have data pending on the LSR).

After all, if the link were in service when a transport delay caused T7
to expire then the link would fail. I don't see the two cases as
substantially different.

Does that make any sense? Or am I missing something?

Regards,
Andrew

[snip]