Subject: RE: [Sigtran] (M2PA) Initial version of M2PA IG is Now Available

From: "Davidson, Mark" <[email-masked]>
Date: Fri, 26 May 2006 08:40:15 -0500

>
>
>-----Original Message-----
>From: Brian F. G. Bidulock [mailto:[email-masked]] 
>Sent: Thursday, May 25, 2006 6:39 PM
>To: Davidson, Mark
>Cc: [email-masked]
>Subject: Re: [Sigtran] (M2PA) Initial version of M2PA IG is Now
Available
>
>Davidson,,
>
>Davidson, Mark wrote:                                           (Thu,
25 May 2006 08:25:27)
>> Brian's objections are the same ones he raised before Jeff's draft
was 
>> even written.
>> 
>> I was at the M2PA plugtest and I will say that most of the issues in 
>> Jeff's draft did not appear (the one I know of for sure was that not 
>> everyone had the same initial FSN).  But the testing I saw only 
>> covered basic alignment, traffic handling, processor outage of 
>> in-service links and congestion.  Issues such as processor outage and

>> recovery during proving were not tested to my knowledge.
>
>I agree that it would be a good starting point to strike all items from
Jeffery's IG expect the FSN.

Not what I wrote.  Please don't put words in my mouth.

> 
>> The additional states introduced by the processor outage recovery 
>> procedure (waiting for an LSR on stream 1) introduces several issues 
>> that should be clarified (or failing the link should be an option as 
>> they really aren't worth the effort required to solve them).
>
>That was the change made at 48 hours.  There is no waiting for LSR
state in the RFC.

Waiting for the 2nd LSR after LSPR was changed, but NOT waiting for 
the first one. This text is still there:

"M2PA SHALL cease transmitting User Data messages after sending the 
 Link Status Processor Recovered message, until it has received the 
 Link Status Ready message ..."

>> 
>> Some of the issues in the draft WERE discussed on this list (e.g.
>> alignment bugs in Q.703 SDLs) and satisfactory answers were not 
>> forthcoming.
>
>Which issues where those?  
>
>I don't think that bugs in SDLs developed by the ITU are within the
scope of M2PA.  Do you?

M2PA says you can base an implementation on Q.703.  If Q.703 has errors 
that affect operability of M2PA implementations they should be
addressed.

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 26 May 2006 08:03:09 -0600

Davidson,,

Davidson, Mark wrote:                                            (Fri, 26 May 2006 08:40:15)

<snip>
>  Link Status Ready message ..."

and it continues, ... "(see below)".  And below it says:

   "M2PA SHALL NOT resume transmitting User Data messages until it has
   sent the Link Status Ready message."

The change made at 48 hours.

No waiting.

Also changed at 48 hours was the Example in 5.4, Figure 16, that quite
clearly shows (at the bottom of Page 40 and the top of Page 41) that
after LS Ready is _sent_ messages are accepted for transmission and
user data is transmitted.  The notes in the diagram also states:

  "B has completed synchronization of sequence numbers and has sent
   and LS Ready, so it is able to resume sending data at this point
   with the new sequence numbers (starting with FSN=14)."

No waiting.

Perhaps "received" should be changed to "sent" in the initial passage
that you quote, but that is a far cry from the several pages of text
that the IG suggests be replaced.

> that affect operability of M2PA implementations they should be

Q.703 SDLs are not authorative on their own: where they disagree with the
text of Q.703, the text wins.  You think that M2PA should correct Q.703 SDLs?

--brian

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