Subject: Re: [Sigtran] M3UA plugtest - Day 1 summary

From: Vikas Chandra <[email-masked]>
Date: Tue, 26 Feb 2002 08:39:14 -0800 (PST)

hi,

----- Original Message -----
From: "Ken Morneault" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, February 26, 2002 2:04 PM
Subject: [Sigtran] M3UA plugtest - Day 1 summary

>
>
> 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.
>
[Vikas]  IMO another approach is to make the
Correlation Id parameter
mandatory for EACH message related to a broadcast mode
AS. In this way also,
i see no message loss/duplication/mis-sequencing as
long as each sent DATA is received to any ASPs. And
the sequence track of
messages can be maintained easily at MGC side even if
different ASPs receive
DATA out of order (which is possible due to multiple
streams in a SCTP
association).

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

__________________________________________________
Do You Yahoo!?
Yahoo! Sports - Coverage of the 2002 Olympic Games
http://sports.yahoo.com

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

---

From: "Ong, Lyndon" <[email-masked]>
Date: Tue, 26 Feb 2002 10:50:20 -0800

Hi Ken,

Thanks for the summary!  A couple of questions below.

Lyndon

-----Original Message-----
From: Ken Morneault [mailto:[email-masked]]
Sent: Tuesday, February 26, 2002 12:35 AM
To: [email-masked]
Subject: [Sigtran] M3UA plugtest - Day 1 summary

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.

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

** this sounds like an administrative issue more than protocol.**

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

** we can put some changes into an implementor's guide as we have **
** done with SCTP.

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.

** Can you clarify about this?  The text currently says that you
** MUST send it if you are using multiple keys/contexts across 
** the association - if not, there's no reason to send it... 

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.  

** Good input!

---

From: Ken Morneault <[email-masked]>
Date: Wed, 27 Feb 2002 03:56:44 -0500

Pls see comments below.

Ken

>** this sounds like an administrative issue more than protocol.**

in practice, it is (as I noted in previous email) an administrative
issue.  the additional flexibility of per association is not needed.

>** we can put some changes into an implementor's guide as we have **

sounds good.  

>** the association - if not, there's no reason to send it... 

as noted in previous email, this notes general discontent with
the RC/NA decision.  i think everyone understands the
text just fine, not all are happy with it though.....

---

From: "Duhoon, Rajiv" <[email-masked]>
Date: Wed, 27 Feb 2002 09:25:51 -0800

Hi All,

Please see my comments below....

-----Original Message-----
From: Ken Morneault [mailto:[email-masked]]
Sent: Tuesday, February 26, 2002 11:10 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Sigtran] M3UA plugtest - Day 1 summary

Pls see comments below.

Ken

At 03:37 AM 2/26/2002 -0600, Brian F. G. Bidulock wrote:
>Ken,
>
>Ken Morneault wrote:              (Tue, 26 Feb 2002 03:34:43)
>> 
>> 
>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.

I agree with the Ken and Brian. Practically we don't need to have
NA per SGP/ASP basis. This is of no use as each service provider 
have to ensure the uniqueness. Its much easier form interoperability
point of view to have unique NA assigned for each network type.

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

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

>Any comments on what is missing?  Any proposals for addition
>to text?
>
>> 
>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: "Schantz, John" <[email-masked]>
Date: Thu, 28 Feb 2002 16:54:05 -0600

-----Original Message-----
From: Schantz, John 
Sent: Thursday, February 28, 2002 9:44 AM
To: 'Duhoon, Rajiv'
Subject: RE: [Sigtran] M3UA plugtest - Day 1 summary

Comments below. John

-----Original Message-----
From: Duhoon, Rajiv [mailto:[email-masked]]
Sent: Wednesday, February 27, 2002 11:26 AM
To: 'Ken Morneault'; [email-masked]
Cc: [email-masked]
Subject: RE: [Sigtran] M3UA plugtest - Day 1 summary

Hi All,

-----Original Message-----
From: Ken Morneault [mailto:[email-masked]]
Sent: Tuesday, February 26, 2002 11:10 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Sigtran] M3UA plugtest - Day 1 summary

Pls see comments below.

Ken

[jls]  I agree that it should be unique to a network BUT it does not have to be coordinated over all scenarios.  I think we are talking about nodes that will set between a couple of networks.  Only the nodes that are connected and handling traffic from the separate networks need to know that an NA situation exists and what the NA value for them is.  Network Type is to general, all networks in Europe are the "ITU" type but they can NOT fully interconnect since they each use the same 14-bit PCs for their own nodes.