Subject: Re: [Sigtran] m3ua- IG

From: "TOLGA ASVEREN" <[email-masked]>
Date: Fri, 10 Jan 2003 11:59:56 +0200

Brian,
--- "Brian F. G. Bidulock" <[email-masked]> wrote:
> TOLGA,
>
> TOLGA ASVEREN wrote:
>                                 (Fri, 10 Jan 2003
> 11:29:14)
> > >
> > > That would not be using the SSN in the messaage
> > > (which is SSN=0), that
> > > would be using the ASSN.  Also, you would need
> to
> > > use the APC rather than
> > > the DPC in the message.  These things are not
> even
> > > mentioned for M3UA.
> > [TOLGA] This is precisely what I mean with
> implementation dependent: how RK
> > analysis is done.
> > >
> > > Also, where does it say that the ASP registered
> with
> > > SSN=5 is the "rignt"
> > > place to send SCCP management messages?
> > [TOLGA] Each AS should receive management messages
> sent for the SSN it
> > serves. Only management messages sent for the
> whole SCCP need to be
> > replicated.
>
> Where does it say that?  Valerie thinks that SSN=0
> should be
> registered for as a separate broadcast AS.  Your
> diverging
> view are an excellent example of why
> interoperability will not
> result.
[TOLGA]All of the things I mentioned, how SSN based routing might be done
is based on the SCCP protocol itself. IMO, this is how it should work, if
one wants to support a RK type, one takes the relevant specification and
thinks whether/how the management functionality needs to be implemented.
The benchmark to decide whether a solution brings interoperability problems
or not is IMO, to see whether the solution requires any change on the peer.
One can even support the same RK type with different ımplementation
dependent on SG, I think the key point is not to require any change on the
peer. For example as long as a SG supporting SSN based RKs works with yours
and Valeries ASPs (assuming they are M3UA complinat :-) ) there is no
problem IMO.

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 10 Jan 2003 03:57:55 -0700

TOLGA,

TOLGA ASVEREN wrote:                                                                 (Fri, 10 Jan 2003 11:59:56)
> One can even support the same RK type with different ýmplementation

In a short period of time we have two approaches: yours and Valerie's.  How
many more approaches must both the SG and ASP support to be interoperable?
That is what is missing from the M3UA spec: a basis for interoperability.  As
an IETF document, M3UA RFC as it stands does not support SSN, because there is
no basis for this interoperability (because it is completely unspecified).

So, tommorrow, Joe comes up with a new approach for SCCP management.  He reads
the M3UA spec and it says that any messages that do not match a routing key
are sent to a default ASP.  So he builds his ASP to receive these messages
only when it is configured in the SG as the default ASP.  His ASP does not
work with your or Valerie's SGs, but he has not violated any requirement in
the M3UA RFC.

So all that results is a bunch of non-interoperable solutions.  That is not
the objective of an IETF RFC.  In fact, an RFC should remove the possibility
of interoperability through specification.  Therefore, the M3UA RFC should go
so far as to say that SSN Routing Keys MUST NOT be supported, because
non-interoperable solutions will result.

--brian

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