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

Andrew,

Andrew Booth wrote:                                                 (Fri, 26 May 2006 15:01:51)
> Hi Brian,
> 
> Some comments and questions inline.
> 
> Brian F. G. Bidulock wrote:
> 
> >Mark,
> >
> >Davidson, Mark wrote:                      (Fri, 26 May 2006 09:22:50)
> >  
> >
> >>The waiting occurs after the LSPR is sent (an LSR has not yet been
> >>sent).
> >>I.e., the LPO side waits for the first LSR, but the RPO side does not
> >>need to wait for the second one.  The change you refer to affected
> >>the RPO side.  The wait I'm referring to is on the LPO side.
> >>    
> >>
> >
> >Just as the side exiting LPO must wait for a FISU or MSU in ANSI
> >T1.113.3-2000 Clause 8 (Q.703 has little to say on the matter).
> >M2PA just uses LSR in this case instead of a FISU or MSU.
> >
> >I take it back: "receive" in the passage you quoted can stay at
> >"receive".  No change required.
> >  
> >
> I agree that the behaviour is similar to MTP2, but the effect on the
> network is bad (link congestion or messages queued for arbitrary time). 
> I think failing the link after T7 in this case would make the protocol
> better.  Do you agree?

Experience with SS7 makes me disagee.  Forcing a link to fail is bad, the
result being increased message loss in the network.

It think that implementations should be validated to behave correctly as
with SS7; therefore, the only thing that could delay the LSR would be the
transport.  I believe transport grade of service should be dealt with at
the network and transport levels and is largely an operational consideration.

For example, we recently discussed a case (on tsvwg) where the SCTP stack
parameters were set so that it took over 3 seconds for a multi-homed SCTP
host to switch from the primary address to the secondary, resulting in link
failure from T7 time expiry whenever the primary failed.

Before failing the link in such a manner, one would need to check that the
LSPR was acknowledged by the other end at the transport and that the current
experienced RTT is not approaching T7, or even that it is beneath T6, and that
MTP3 has already changed over (Q.704-T1 expiry, processor outage is of a long
duration).  This later is because failing the link before changeover will
result in message loss.  But then, if you wait for MTP3 T1 to expire and
changeover to occur, it makes no difference whether you wait or fail the
link because changeover has occured.

I think that, asside from excessive delay of acknowledgement of actual MSUs,
MTP3 should decide when to fail a blocked link.

> 
> >  
> >
> >>If Q.703 is followed closely the link will not align.  I think that's
> >>a problem.
> >>    
> >>
> >
> >It doesn't appear that all those Q.703 implementations out there have
> >any problem aligning.
> >
> >So you don't think that M2PA should correct Q.703 SDLs?
> >  
> >
> What do you think of section 2.5 of Jeff's document?  Is it a legitimate
> concern?

No, I don't.  I've had running code there for 5 years.

Where does it say RFC 4165 that LS Ready is ignored while T4 is running?

I see where it says that a peer MAY send additional LS Ready messages while
timer T1 is running.  If you are concerned that the other end has sent LS
Ready and is (for some bad reason) ignoring your previous LS Ready messages,
send another in response.  You are permitted by the RFC to do so.  That is
you always MAY send additional LS Ready messages while timer T1 is running.
In fact, you could pace them in the same manner as LS Proving messages from
the moment you send the first one.

I think that the RFC should prescribe the desired behaviour rather than going
to lengths to counter-recommend all undesired behavior.

Again I think that implementations should be validated.  See test case 3.1.5.
Would such a misbehaving implementation even align with itself?  Or would it
fail this test.

--brian

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