Subject: [Sigtran] M3UA plugtest - Day 1 summary

From: Ken Morneault <[email-masked]>
Date: Tue, 26 Feb 2002 03:34:43 -0500

The M3UA plugtest is off to a strong start with 11 companies
participating (see ETSI site for details).  A special thanks to 
Michael Tuxen and the ETSI staff for having the the test bed 
setup and ready for use early Monday morning.  Participants 
began testing after a brief introduction by the ETSI staff.

Here are the issues from Day 1:

1)  what is the scope of Network Appearance?
     - is it unique across SG/AS, or
     - is it unique across SCTP associations

Across SCTP associations provides flexibility, but there are
questions about whether that flexibility is needed or practical.

2)  IPSP text is not clear enough 

the single exchange and double exchange methods make it 
difficult to create a generic product.  Suggestion that only
one (single or double) be allowed.  Further suggestion that
people interested in IPSP get together this week to suggest
text changes (which, at this point, would probably need to be
in an extension draft).

3)  NA in SSNM

case of a network becoming unavailable is easier and more
clearly expressed by using NA (and not RC).  in general, there
is some discontent about RC becoming semi-optional in
messages.

4)  optional parameters are not always optional

text needs to be clear about when optional parameters are
not optional (RC is case in point).

5)  use of broadcast mode not fully specified (use of 
correlation id not fully specified either)

general feeling that without the correlation id draft (refer to 
draft-bidulock-sigtran-corid-00.txt) broadcast mode and
use of correlation id cannot be fully implemented.  

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 26 Feb 2002 03:37:17 -0600

Ken,

Ken Morneault wrote:              (Tue, 26 Feb 2002 03:34:43)
> questions about whether that flexibility is needed or practical.

How about unique within a network.

> is some discontent about RC becoming semi-optional in

We've been over this before.  Any suggestions how to handle
the case where different AS do not have the same routing in
the SS7 network?  Where NA is insufficient to communicate
SSNM?

> correlation id not fully specified either)

Any comments on what is missing?  Any proposals for addition
to text?

> use of correlation id cannot be fully implemented.  

Well, that's a strange statement...

draft-bidulock-sigtran-corid-00.txt does not address broadcast
mode.  It merely reiterates what is already stated in the M3UA
spec:

"     In addition, when a ASP becomes active for a Broadcast AS, an SGP
"  MUST tag the first message in each traffic flow towards the ASP to
"  allow the ASP to synchronize its entry into the Broadcast AS.

--brian

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Tue, 26 Feb 2002 08:59:55 -0500

Hi,

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Ken Morneault
> Sent: Tuesday, February 26, 2002 3:35 AM
> To: [email-masked]
> Subject: [Sigtran] M3UA plugtest - Day 1 summary
>
>
>
>
[TOLGA] I hope any suggested changes will be discussed on this list, before
a decision is met.
> is some discontent about RC becoming semi-optional in
[TOLGA] I thought the draft is pretty much clear that when traffic belonging
to more than one RK is carried over one SCTP association, RC is mandatory.
IMHO, RK (=RC) is the main construct of communciation between SGP-ASP (or
between IPSP-IPSP). IMHO, even for special cases, where other solutions
might seem more practical, for the sake of keeping communication mechanism
to work always based on the same construct, using RC seems more clean.

---

From: Ken Morneault <[email-masked]>
Date: Wed, 27 Feb 2002 02:10:26 -0500

Pls see comments below.

Ken

>How about unique within a network.

This would be nice but it would require each network/NA
to be registered with an org like IANA.

Practically speaking, the service provider is going to 
ensure that their equipment has the unique NA
for each network they connect to.  Therefore, there
is no need to allow them to change NA per SGP/ASP.
This flexibility is not needed.

>the SS7 network?  Where NA is insufficient to communicate

Maybe this should not have been listed as an "issue", but
instead "general comment" or "general grumblings".  There
are several (including myself) that think making the RC
semi-optional was a bad decision.  But, life goes on...