Subject: RE: [Sigtran] IPSP issues

From: "Ong, Lyndon" <[email-masked]>
Date: Wed, 24 Apr 2002 10:11:51 -0700

Folks,

I think given the long trail of email that Brian is right -
it would be best to have this out on "paper" in a draft and
let people have a look at it, otherwise we're going round
and round.  Given the level of discussion we should probably
make it an individual draft at this point and see if we can
get consensus (and A-D approval) to make it WG after some
review.

Cheers,

Lyndon

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: Wednesday, April 24, 2002 10:05 AM
To: Tolga Asveren
Cc: [email-masked]
Subject: Re: [Sigtran] IPSP issues

Tolga,

I propose that we go forward with your draft and present it to the
draft-editor so that we can have a basis for discussion.  The only
dissent seems to be based on a motherhood, naming or ideological
basis, and derive I believe from the lack of understanding of the
proposal at hand.  Let's see the first draft so that we can discuss
the specifics.

--brian

Tolga Asveren wrote:                                        (Wed, 24 Apr
2002 08:33:46)
> Javier,
> 
> I still stick with the decision from recent IPSP discussions:
> 
>      -----              -----
>    //     \\          //     \\
>   |  ASP    |        |  ASP    |
>   |  Cloud 1|        |  Cloud 2|
>    \\     //          \\     //
>      --+--              --+--
>        |                  |
>        |                  |
>     +--+--+            +--+--+
>     | SG1 +------------+ SG2 |
>     +--+--+            +--+--+
>        |                  |
>        |                  |
>        |                  |
>        |     +-----+      |
>        +-----+ SG3 +------+
>              +--+--+
>                 |
>                 |
>               --+--
>             //     \\
>            |  ASP    |
>            |  Cloud 3|
>             \\     //
>               -----
> 
> The communication inside ASP clouds is based on existing ASP/SGP
> functionalities. How big or how small one ASP cloud is configuration
> dependent.
> I still don't think, we should try to create a new process type "IPSP",
> because it is not necessary.
> If people feel the need that some sample configurationsa are put to the
> draft, that is fine. But in my opinion, all of those "IPSP considerations"
> sections are not needed.
> 
>     Tolga
> 
> > -----Original Message-----
> > From: Javier Pastor-Balbas (ECE)
> > [mailto:[email-masked]]
> > Sent: Wednesday, April 24, 2002 4:24 AM
> > To: 'Tolga Asveren'; [email-masked]
> > Subject: RE: [Sigtran] IPSP issues
> >
> >
> > Hi Tolga,
> >
> > This drawing is being more and more similar to what I think. But
> > I still don't need all the SGP functionality in my pure IPSP. The
> > same applies to the ASP funcitionality. If I only implements IPSP
> > communication I just need some parts that are common with the pure ASP.
> >
> > I would prefer to draw the IPSP as a box. Including all the ASP
> > or all the SGP functionality in there is not necessary and it
> > becomes a design decission.
> >
> > More comments below...
> >
> > > -----Original Message-----
> > > From: Tolga Asveren [mailto:[email-masked]]
> > > Sent: Tuesday, April 23, 2002 7:24 PM
> > > To: [email-masked]
> > > Subject: RE: [Sigtran] IPSP issues
> > >
> > >
> > > Hi Javier,
> > >
> > > I didn't say a third node is necessary. I just want to point
> > > out, already
> > > defined functionalities are enough to handle communciation
> > > both to SS7 and
> > > to IP nodes.
> >
> > Agreed and that's what IPSP philosophy is based on.
> >
> > > For example your MSC most probably should look like:
> > >
> > >  +------------+
> > >  |            |
> > >  |            |
> > >  |   X        |
> > >  |            |
> > >  |    +-------+
> > >  |    |ASP    |
> > >  |    +-------+
> > >  |    |SGP    |
> > >  +----+-------+
> > >
> > > What you put inside your node is an internal decision. The
> > > protocol just
> > > defines the relationship between endpoints, and with already defined
> > > endpoints, it works.
> > >
> >
> > It works, but including all the ASP and SGP functionality inside
> > an IPSP, it's more than you really need.
> >
> > > If you agree that a simple configuration is better, I think
> > > it is better
> > > that you also consider all of the necessary details, to draw
> > > the ========
> > > between ASs. I think it is more complicated than it appears first.
> > >
> >
> > Well, let's study this complexity and solve the open points taken
> > the current RFC as the base...  :-D
> >
> >
> > Cheers // Javier.
> >
> >
> >
> > >
> > >
> > >     Tolga
> > >
> > >
> > > > -----Original Message-----
> > > > From: Javier Pastor-Balbas (ECE)
> > > > [mailto:[email-masked]]
> > > > Sent: Tuesday, April 23, 2002 12:28 PM
> > > > To: 'Tolga Asveren'; [email-masked]
> > > > Subject: RE: [Sigtran] IPSP issues
> > > >
> > > >
> > > >
> > > > Hi Tolga,
> > > >
> > > > I agree that your configuration can work. But what I'm also
> > > > looking for is simplicity. If I want an MSC to communicate with
> > > > an HLR, I want the underlying protocols of that particular nodes
> > > > do all the work for me. I don't want to include a third node.
> > > >
> > > > In your drawing using the IPSP communication it will go thru the
> > > > direct path. This means easiest configuration and faster
> > > transmission.
> > > >
> > > >
> > > >
> > > >   RK1: DPC=1-1-1       RK2: DPC=2-2-2
> > > >   +------+            +------+
> > > >   | AS 1 |============| AS 2 |
> > > >   +--+---+            +--+---+
> > > >      |                   |
> > > >      |                   |
> > > >      |                   |
> > > >      |                   |
> > > >      |                   |
> > > >      |     +------+      |
> > > >      +-----+ SG 1 +------+
> > > >            +------+
> > > >          RK1: DPC=1-1-1
> > > >          RK2: DPC=2-2-2
> > > >
> > > >
> > > > I don't really understand why you want to include a third node
> > > > there... What it is already defined works fine. Include the SG 1
> > > > you can also have a redundancy path but the primary will be the
> > > > "====" one. AS1 will select the shortest path (association) among
> > > > the available ones.
> > > >
> > > > I don't see any benefits from your scenario for an AS-AS
> > > > communication point of view. The good point of including a  SG is
> > > > having connection to an SS7 network as well. BUt for those cases
> > > > you can use my configuration above what is optimized.
> > > >
> > > >
> > > > Cheers // Javier.
> > > >
> > > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Tolga Asveren [mailto:[email-masked]]
> > > > > Sent: Tuesday, April 23, 2002 6:05 PM
> > > > > To: [email-masked]
> > > > > Subject: RE: [Sigtran] IPSP issues
> > > > >
> > > > >
> > > > > Hi Javier,
> > > > >
> > > > > Again I think, we are saying the same thing with you.
> > > > > Probably the only
> > > > > difference is, in my opinion, it is not important whether the
> > > > > remote peer
> > > > > you are sending messages to (for example 1-1-1) is in IP
> > > > > domain or in SS7
> > > > > domain. I think, the important point is (in the context of
> > > > > this discussion)
> > > > > the behavior of the peer (not the remote endpoint, your
> > > > > adjacent node) you
> > > > > are sending the messages. Regardless of where the remote
> > > > > endpoint is (IP
> > > > > domain or SS7) , the messages and procedures are the same.
> > > > > For example, just as a very simple example, let's consider
> > > > > the following
> > > > > configuration:
> > > > >
> > > > >  RK1: DPC=1-1-1       RK2: DPC=2-2-2
> > > > >  +------+            +------+
> > > > >  | ASP1 |            | ASP2 |
> > > > >  +--+---+            +--+---+
> > > > >     |                   |
> > > > >     |                   |
> > > > >     |                   |
> > > > >     |                   |
> > > > >     |                   |
> > > > >     |     +------+      |
> > > > >     +-----+ SGP1 +------+
> > > > >           +------+
> > > > >         RK1: DPC=1-1-1
> > > > >         RK2: DPC=2-2-2
> > > > >
> > > > > This is possible with existing m3ua draft, nd two
> > > > > applications in IP domain
> > > > > can communicate in such a way. They can also communicate with
> > > > > nodes in SS7
> > > > > domain. When there are different operators involved and
> > > > > configurations are
> > > > > more complex, then one probably will want to have a
> > > > > configuration with SG-SG
> > > > > communication.
> > > > >
> > > > >    Tolga
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Javier Pastor-Balbas (ECE)
> > > > > > [mailto:[email-masked]]
> > > > > > Sent: Tuesday, April 23, 2002 11:35 AM
> > > > > > To: 'Tolga Asveren'; [email-masked]
> > > > > > Subject: RE: [Sigtran] IPSP issues
> > > > > >
> > > > > >
> > > > > > Tolga, see below..
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Tolga Asveren [mailto:[email-masked]]
> > > > > > > Sent: Tuesday, April 23, 2002 5:41 PM
> > > > > > > To: [email-masked]
> > > > > > > Subject: RE: [Sigtran] IPSP issues
> > > > > > >
> > > > > > >
> > > > > > > Hi Javier,
> > > > > > >
> > > > > > > Personally I disagree that IPSP is described in the current
> > > > > > > draft. It is
> > > > > > > just a group of sentences, which were put there without
> > > > > > > consensus and deep
> > > > > > > thinking, because of time limitations.
> > > > > > > The fact, that people could let their nodes communicate in IP
> > > > > > > domain in the
> > > > > > > lastinteroperability event just shows me, that this is
> > > > > > > achievable with the
> > > > > > > well defined SGP/ASP functionalities.
> > > > > > >
> > > > > >
> > > > > > It is achievable indeed, and it is based in the SGP/ASP
> > > > > > functionalities that were define in advance. But the good thing
> > > > > > is that you have and IP-node that can talk to an SG or
> > > to another
> > > > > > IP-node at the end .... :-D
> > > > > >
> > > > > > Cheers // Javier.
> > > > > >
> > > > > > > (I sent all of the messages of the recent IPSP discussions as
> > > > > > > a text file
> > > > > > > attachment to the list, it waits approval from moderator
> > > > > > > because its size is
> > > > > > > bigger than 40K)
> > > > > > >
> > > > > > >    Tolga
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: [email-masked]
> > > > > > > [mailto:[email-masked]]On Behalf Of
> > > > > > > > Javier Pastor-Balbas (ECE)
> > > > > > > > Sent: Tuesday, April 23, 2002 11:22 AM
> > > > > > > > To: [email-masked]'
> > > > > > > > Cc: [email-masked]'
> > > > > > > > Subject: RE: [Sigtran] IPSP issues
> > > > > > > >
> > > > > > > >
> > > > > > > > Hi Brian,
> > > > > > > >
> > > > > > > > I'm aware of some of your discussions but I just see your
> > > > > > > > proposal as another configuration different from
> > > what IPSP is.
> > > > > > > > IPSP communication is already included in the RFC
> > > as I explained
> > > > > > > > below and has been successfully tested in the last
> > > interop...
> > > > > > > > It's just a matter of solving the concerns that
> > > came up there.
> > > > > > > >
> > > > > > > > Cheers // Javier.
> > > > > > > >
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > > > > > > > Sent: Tuesday, April 23, 2002 4:32 PM
> > > > > > > > > To: Javier Pastor-Balbas (ECE)
> > > > > > > > > Cc: 'Tolga Asveren'; [email-masked]
> > > > > > > > > Subject: Re: [Sigtran] IPSP issues
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Javier,
> > > > > > > > >
> > > > > > > > > I encourage you too look back in the archives of the IPSP
> > > > > > > mail list
> > > > > > > > > where we have already discussed these issues.
> > > > > Perhaps Tolga could
> > > > > > > > > point to where those are.  As a group we arrived at the
> > > > > > > simpler model
> > > > > > > > > of SG-SG communication (without backhaul) using the
> > > > > > > existing messages.
> > > > > > > > >
> > > > > > > > > --brian
> > > > > > > > >
> > > > > > > > > Javier Pastor-Balbas (ECE) wrote:
> > > > > > > > > (Tue, 23 Apr 2002 15:30:07)
> > > > > > > > > > Hi Tolga,
> > > > > > > > > >
> > > > > > > > > > See below....
> > > > > > > > > >
> > > > > > > > > > Cheers / Javier.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > > -----Original Message-----
> > > > > > > > > > > From: Tolga Asveren [mailto:[email-masked]]
> > > > > > > > > > > Sent: Tuesday, April 23, 2002 3:16 PM
> > > > > > > > > > > To: [email-masked]
> > > > > > > > > > > Subject: RE: [Sigtran] IPSP issues
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > Hi Javier,
> > > > > > > > > > >
> > > > > > > > > > > To make this thread more productive let me list
> > > > > my concerns:
> > > > > > > > > > >
> > > > > > > > > > > 1) The fact, that "IPSP" is described in a few
> > > > > lines in M3UA
> > > > > > > > > > > draft is in my
> > > > > > > > > > > view enough evidence, that it just reuses already
> > > > > > > defined ASP/SGP
> > > > > > > > > > > functionalities. I don't think there is a
> > > need to give a
> > > > > > > > > > > special name to
> > > > > > > > > > > this, because it is just a special configuration of
> > > > > > > the existing
> > > > > > > > > > > functionalities. Of course, different people
> > > might have
> > > > > > > > > > > different opinions
> > > > > > > > > > > on that issue.
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > About the special name I agree with you that no
> > > new names
> > > > > > > > > were needed. I prefer to call it ASP-ASP
> > > > > > > > > > Note about the RFC names:
> > > > > > > > > > AS
> > > > > > > > > > IPSP: node that communicates with another IPSP
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > > 2) I don't necessarily agree with your sentence
> > > > > "IPSP is an
> > > > > > > > > > > IP-only node".
> > > > > > > > > > > In the recent IPSP discussions, the question
> > > > > which everybody
> > > > > > > > > > > was asking was
> > > > > > > > > > > "Can I have an aasociation between IPSP and SGP,
> > > > > what about
> > > > > > > > > > > IPSP and ASP?".
> > > > > > > > > > > That is also one of the reasons, why I like to see it
> > > > > > > as a special
> > > > > > > > > > > configuration of ASP/SGP, because, in such a case the
> > > > > > > > > > > relationship between
> > > > > > > > > > > endpoints is well defined.
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > In fact you may be right. I'll try to remake my
> > > > > point better:
> > > > > > > > > >
> > > > > > > > > > IPSP is not and IP-node itself. "IPSP
> > > communication" is the
> > > > > > > > > "procedure" (using M3UA messages) that two AS
> > > (i.e IP nodes)
> > > > > > > > > need to use to talk among them.
> > > > > > > > > > And AS-SG procedures are the ones that an AS
> > > has to use to
> > > > > > > > > talk to an SG.
> > > > > > > > > >
> > > > > > > > > > We can think of ASP and IPSP as roles.The
> > > implementation of
> > > > > > > > > an AS in processes is as follows:
> > > > > > > > > > 	- An AS implementation is called ASP if it
> > > > > > > talks with and SGP
> > > > > > > > > > 	- An AS implementation is called IPSP
> > > if it talks to
> > > > > > > > > another AS implementation (also called IPSP)
> > > > > > > > > >
> > > > > > > > > > It can be possible that an AS can talk to both kind of
> > > > > > > > > nodes at the same time: an SG and another AS. In that case
> > > > > > > > > the implementation of that AS (what we call process) will
> > > > > > > > > take the roles of ASP and IPSP at the same time.
> > > > > > > > > >
> > > > > > > > > > I know this nomenclature is not very clear. In
> > > fact I tried
> > > > > > > > > to change the term "IPSP communication" for "ASP-ASP
> > > > > > > > > Communication" but some folks preferred to have different
> > > > > > > > > names to differenciate both situations. But anyway in the
> > > > > > > > > draft it is said that "an IPSP serves an AS" in
> > > the same way
> > > > > > > > > that it is said that "an ASP serves an AS".
> > > > > > > > > >
> > > > > > > > > > Therefore we can conclude that it is not possible to
> > > > > > > > > connect an ASP with an IPSP, since this are roles
> > > that the AS
> > > > > > > > > implementation can have. The AS is the one that
> > > can be called
> > > > > > > > > IP-node.  :-D
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Hope this clarifies a little more...  :-/
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > > Your main concern is -as far as I understand- that SGP
> > > > > > > > > > > functionality has
> > > > > > > > > > > some components, which are not necessary for
> > > > > "IPSP" case. For
> > > > > > > > > > > which parts
> > > > > > > > > > > are you concerned?
> > > > > > > > > >
> > > > > > > > > > I hope the discussion above clarifies my point... :-D
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > > See it as the following:
> > > > > > > > > > > > If you add to an AS the functionality needed for an
> > > > > > > SG to send
> > > > > > > > > > > > messages to an AS, and you mix it according with
> > > > > > > the M3UA RFC,
> > > > > > > > > > > > you'll have an IP node that can talk to an SG but
> > > > > > > also DIRECTLY
> > > > > > > > > > > > to another IP-node. It is what is already defined
> > > > > > > and it works
> > > > > > > > > > > > fine. It worked fine in the last interop. The open
> > > > > > > issue we have
> > > > > > > > > > > > is to decide the start-up of the connection, but the
> > > > > > > > > rest doesn't
> > > > > > > > > > > > need any urgent modification...
> > > > > > > > > > > That is also exactly what I am saying. More and
> > > > > more I have
> > > > > > > > > > > the feeling, the
> > > > > > > > > > > main difference is, you want to give this
> > > thing a new name
> > > > > > > > > > > and I don't.
> > > > > > > > > > > Well, this is not a big issue :-)
> > > > > > > > > > >
> > > > > > > > > > >     Tolga
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > _______________________________________________
> > > > > > > > > > > Sigtran mailing list
> > > > > > > > > > > [email-masked]
> > > > > > > > > > > https://www1.ietf.org/mailman/listinfo/sigtran
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > _______________________________________________
> > > > > > > > > > Sigtran mailing list
> > > > > > > > > > [email-masked]
> > > > > > > > > > https://www1.ietf.org/mailman/listinfo/sigtran
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Brian F. G. Bidulock
> > > > > > > > > [email-masked]
> > > > > > > > > http://www.openss7.org/
> > > > > > > > >
> > > > > > > >
> > > > > > > > _______________________________________________
> > > > > > > > Sigtran mailing list
> > > > > > > > [email-masked]
> > > > > > > > https://www1.ietf.org/mailman/listinfo/sigtran
> > > > > > >
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > > Sigtran mailing list
> > > > > > > [email-masked]
> > > > > > > https://www1.ietf.org/mailman/listinfo/sigtran
> > > > > > >
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > Sigtran mailing list
> > > > > [email-masked]
> > > > > https://www1.ietf.org/mailman/listinfo/sigtran
> > > > >
> > >
> > >
> > > _______________________________________________
> > > Sigtran mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/sigtran
> > >
> 
> 
> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sigtran

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

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

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