Subject: Re: [Sigtran] m3ua- IG

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

Brian,
--- "Brian F. G. Bidulock" <[email-masked]> wrote:
> TOLGA,
>
> TOLGA ASVEREN wrote:
>                                 (Fri, 10 Jan 2003
> 11:59:56)
> >
> > 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.
>
> 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.

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

---

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

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

You cannot acheive interoperability in
this regard without both the SG and the
ASP knowing which procedures are used.

Therefore, you cannot (as you said
previously) just implement SSN RK on the
SG without the ASP knowing how it is done.

Is there anyone else on the list that
thinks this is basis for interoperability?

--brian

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