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

Hello Andrew and Brian,


<Regarding treatment of LSR/LSPR received during proving>

Andrew queried:
> What do you think of section 2.5 of Jeff's document?  Is it a
legitimate
> concern?

Brain replied:
> 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.

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

One issue is that the M2PA RFC does not mandate that LSR be sent more
than
once. Another issue is that the RFC does not mandate a rate to send LSR,
if the implementer chooses to send it periodically. An optimally
interoperable M2PA implementation, therefore, should send LSRs
periodically
and should handle a peer that sends only one LSR (which may arrive
during
proving). The IG says this.


<Regarding failing the link if timely LSR(1) not received after LSPR
sent>

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

Brian, are you saying that the scenario can't happen or are you saying
it
can only happen for contrived test cases (of which I have at least one)?

Brian, please explain in more detail why this form of 'failing the link'

results in more message loss than other forms of 'failing the link',
such 
as association failure. Please explain why M2PA should not fail a
blocked 
link when the association fails. Citing applicable standards text would
be
a good start.

Brian stated:
> I believe transport grade of service should be dealt with at the
network 
> and transport levels and is largely an operational consideration.

Perhaps I am misunderstanding what you are trying to say, but
I know of a few large operators who disagree with it as written.
M2PA should have an awareness of its transport and implement error rate
monitors, somewhat like MTP2 and ATM, to ensure that the quality of the
transport is sufficient to sustain an in-service signaling link. T7
expiry
is not the best mechanism for achieving this.

Regards,

Jeff

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email protected]] 
Sent: Friday, May 26, 2006 5:33 PM
To: Andrew Booth
Cc: [email protected]; Davidson, Mark
Subject: Re: [Sigtran] (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/

_______________________________________________
Sigtran mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/sigtran