Subject: Re: [Sigtran] m3ua- IG

From: "TOLGA ASVEREN" <[email-masked]>
Date: Fri, 10 Jan 2003 14:16:02 +0200

Brian,
--- "Brian F. G. Bidulock" <[email-masked]> wrote:
> TOLGA,
>
> TOLGA ASVEREN wrote:
>                                 (Fri, 10 Jan 2003
> 13:27:19)
> >
> > Brian,
> > --- "Brian F. G. Bidulock" <[email-masked]>
> wrote:
> > > TOLGA,
> > >
> > > TOLGA ASVEREN wrote:
> > >                                 (Fri, 10 Jan
> 2003
> > > 13:10:15)
> > > > > 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.
> > > > [TOLGA] I totally disagree. You present
> > > > some solutions, which bring some
> > > > interoperability problems, and use this
> > > > as an evidence of inappropriateness of a
> > > > solution, which does not have
> > > > interoperability problems. As I said
> > > > several times, as long as a SG
> > > > supporting SSN based routing works with
> > > > a standard M3UA based ASP, I don´t see
> > > > any problem.
> > >
> > > Which standard M3UA ASP?  Yours?
> > > Valeries?  Joes?  Several? All?
> > [TOLGA] Any ASP compliant with M3UA RFC.
> Any and all?  How do you ensure that
> your SG works with Jim's ASP? (Jim hasn't
> told the world his method yet.)
[TOLGA]If Jim´s ASP is M3UA compliant, there is no problem. But if his
method requires some changes on the ASP -and if he had implemented them
there- and if those changes require any change to the protocol, then I
don´t think it is a problem that SG can´t interwork with it. So, pleae
don´t blame me, if Jim does not want to copmly with M3UA.
>
> > >
> > > You cannot acheive interoperability in
> > > this regard without both the SG and the
> > > ASP knowing which procedures are used.
> > [TOLGA] I don´t propose this. What I
> > propose is, an implementation
> > dependent management funtionality on
> > SG, which does not require any change
> > on the peer, i.e. which won´t prevent
> > SG to work with a M3UA compliant ASP.
> But ASP needs to know what SG is doing.
> This requires some kind of change on the
> ASP.  Otherwise, and OBVIOUSLY,
> interoperability will not result.
[TOLGA] ASP does not need to know anything special.
>
> > >
> > > Therefore, you cannot (as you said
> > > previously) just implement SSN RK on the
> > > SG without the ASP knowing how it is done.
> > [TOLGA]Why? What requirement will it
> > put to ASP or to the M3UA protocol?
>
> It puts requirements on the ASP as to
> where (which AS) and in what manner (when
> configured how) it can expect to recieve
> SCCP management messages.
[TOLGA] Each AS serving a SSN will receive each message, which needs to be
routed to this SSN. The answer to the question, which ones those messages
is in the relevant SCCP specification and will be decided on SG. No
interaction is necessary from ASP.
>
> > > Is there anyone else on the list that
> > > thinks this is basis for interoperability?
> > [TOLGA} Or which thinks that
> > ımplementing a functionality on SG
> > which does not put any requirement to
> > M3UA protocol or to the peer, is a
> > violation of the protocol?
> All three methods mentioned put
> requirements on the peer.  That's
> why they don't interoperate.
[TOLGA] It is no suprise that a non-interoperable solution does not
interoperate with a interoprable solution.

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 10 Jan 2003 05:32:16 -0700

TOLGA,

TOLGA ASVEREN wrote:                                                                 (Fri, 10 Jan 2003 14:16:02)
> don´t blame me, if Jim does not want to copmly with M3UA.

Jim's is as compliant as yours, Valerie's and Joe's.  But
it still doesn't interwork because the SG designer could
not anticipate his solution.

> [TOLGA] ASP does not need to know anything special.

It needs to know where it will receive SCCP management
messages.  This is special.

> interaction is necessary from ASP.

SCCP specifications say nothing about ASPs, or to which
AS SCCP management messages need to be routed.

> > > ýmplementing a functionality on SG

None of these solutions are interoperable.

--brian

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