Subject: FW: [Sigtran] IPSP issues

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Wed, 24 Apr 2002 18:30:32 +0200

Hi Tolga 

More comments..

> -----Original Message-----
> From: Tolga Asveren [mailto:[email-masked]]
> Sent: Wednesday, April 24, 2002 5:00 PM
> To: [email-masked]
> Subject: RE: [Sigtran] IPSP issues
> 
> 
> Javier,
> 
> Then where is the disagreement? Based on your figure, what I 
> can say is
> that, you also agree that your node will see a remote 
> endpoint always as a
> ASP or SGP. 

My nodes will see the remote node as an AS or a SG, but not ASP or SGP or IPSP. My remote IP-nodes (running M3UA as an SCTP endpoint) could implement ASP, ASP&IPSP or just IPSP communication. A "process" can also be at the same time ASP and IPSP. ASP or IPSP are different behaviors that you have to use depending on who are you talking to.

> So, do you need a new endpoint type? 

IPSP is not new, it is already defined. Take a look to the RFC. ;-)

> To clarify 
> what you mean,
> it is better if you draw both nodes in your figure and also 
> the types of
> endpoints 
> 

Neither X nor Y are ASP alone and Z is not SGP. So there is no reason to change the names. And I insist, you can put inside the IP-node the whole SG implementation if you want (and also add a car stereo system ;-D) but it is not needed. As this is a design option I'd suggest to leave it out of the discussion. 

> (I insist that ASP and SGP are endpoint types from 
> M3UA point of
> view :-) )

In the RFC it is clearly stated that an ASP includes a SCTP endpoint. Therefore ASP is not an endpoint itself. This SCTP endpoint can be used at the same time to talk to another AS using the IPSP behaviour.

Or maybe you have another view of what it's an endpoint  :-/

Cheers // Javier.

>     Tolga
> 
> > -----Original Message-----
> > From: Javier Pastor-Balbas (ECE)
> > [mailto:[email-masked]]
> > Sent: Wednesday, April 24, 2002 10:30 AM
> > To: 'Tolga Asveren'
> > Cc: [email-masked]'
> > Subject: RE: [Sigtran] IPSP issues
> >
> >
> >
> > Hi Tolga,
> >
> > Here I go again !!  :-)
> >
> >
> > I'll try to draw an example or possible implementation of 
> an IP-node (AS)
> >
> >
> >
> >
> >       IP-node
> >   +------------+
> >   |Application |
> >   |            |
> >   |    +-----+ |
> >   |    |  X  | |    AS-SG comm
> >   |    +-----+ |<=================>[SG]
> >   |    |  Y  | |         IPSP comm
> >   |    +-----+ |<======================================> [IP-node]
> >   |    |  Z  | |
> >   |    +-----+ |
> >   +------------+
> >
> > where:
> >
> >  X+Y: ASP logic to implement the communication with an SGP
> >  Y: logic included in pure ASPs and used when receiving 
> data from an SGP
> >  Z: The part of the logic that the SGP uses when sending 
> data to an ASP
> >
> > Examples:
> > - A SGP will be composed of Z + more specific SG logic.
> > - An AS implementation only capable to talk to a SG will only
> > implement X+Y
> > - An AS implementation that only talks to another AS will 
> include Y+Z
> > - An AS implementation that can talk to a SG or to another SG
> > will implement X+Y+Z
> >
> > What I understand by endpoint is an SCTP endpoint. One SCTP
> > endpoint can perfectly play the role of IPSP and ASP within 
> an IP node.
> >
> > You don't need to use the whole SGP or ASP functionality always,
> > but the part that you need. But again, this  what is explained is
> > nothing new.
> >
> > See more comments below...
> >
> >
> > > -----Original Message-----
> > > From: Tolga Asveren [mailto:[email-masked]]
> > > Sent: Wednesday, April 24, 2002 4:14 PM
> > > To: [email-masked]
> > > Subject: RE: [Sigtran] IPSP issues
> > >
> > >
> > > Javier,
> > >
> > > Please see comments below. Also if you draw a figure of what
> > > you propose, it
> > > could be better to proceed. Because I think I didn't
> > > understand 100% what
> > > you mean.
> > >
> > >   Tolga
> > >
> > > > -----Original Message-----
> > > > From: Javier Pastor-Balbas (ECE)
> > > > [mailto:[email-masked]]
> > > > Sent: Wednesday, April 24, 2002 9:38 AM
> > > > To: 'Tolga Asveren'
> > > > Cc: [email-masked]'
> > > > Subject: RE: [Sigtran] IPSP issues
> > > >
> > > >
> > > >
> > > > Hi Tolga,
> > > >
> > > > See below...
> > > >
> > > > > -----Original Message-----
> > > > > From: Tolga Asveren [mailto:[email-masked]]
> > > > > Sent: Wednesday, April 24, 2002 3:23 PM
> > > > > To: [email-masked]
> > > > > Subject: RE: [Sigtran] IPSP issues
> > > > >
> > > > >
> > > > > Hi Javier,
> > > > >
> > > > > 1) It is really still not clear to me, whether you want to
> > > > > define a new
> > > > > functionality or not. If you want ASP-ASP communication, then
> > > > > there is some
> > > > > work to do. Currently this is not defined.
> > > > >
> > > > We don't need to define nothing new about that. I just use to
> > > > call IPSP communication as AS-AS (sorry, not ASP-ASP)
> > > > communication. That's all. You can keep IPSP name.
> > > [TOLGA] If you don't define anything new, then you are using
> > > just ASP and
> > > SGP functionalities or not? This is really not clear to me.
> > > >
> > > > > 2) In my opinion, the reason for interoperability problems
> > > > > is, people tried
> > > > > to combine their SGP/ASP functionalities in different
> > > ways to let them
> > > > > communciate with nodes in IP domain.
> > > >
> > > > Tolga, I don't know where this experience comes from, but at the
> > > > plugtest it seemed that the only problem was the initialization
> > > > process... The rest worked as far as I know... (correct 
> me if I'm
> > > > wrong) :-)
> > > [TOLGA] Well, that's what I am saying. If both sides have matching
> > > configurations, of course it will successfully work. And if those
> > > configurations are not matching, of course you first phase a
> > > problem during
> > > initialization.
> >
> > The problem didn't appear at initialization. Initialization was
> > the problem itself. But it was because we have defined two
> > methods of initializing that are not compatible. When you agree
> > on this first step , everything works fine.
> >
> >
> > > >
> > > > > This just like I have
> > > > > two SGPs and I
> > > > > try to send messages from one of them to the other one,
> > > of course this
> > > > > configuration won't work (referring to M3UA draft not to the
> > > > > proposed SG-SG
> > > > > communciation)
> > > >
> > > > Having two SGPs in not the same as having two IPSP. IPSP is
> > > not an SGP...
> > > [TOLGA] This is just an example to show that two nodes, 
> which are not
> > > supposed to communicate, cannot communicate.
> > > >
> > > > > As I said, if sample configurations are
> > > > > needed, that is fine.
> > > > > It can be said, if you have two nodes in IP domain, then one
> > > > > node should
> > > > > have this and that endpoint and the other those endpoint and
> > > > > we can put some
> > > > > nice figures there.
> > > >
> > > > But you don't need to have two endpoints into the same node to
> > > > implement the ASP and IPSP functionality into an AS!!. Only one
> > > > endpoint is needed. It will behave as an ASP when 
> talking to a SG
> > > > and as an IPSP when talking to another IP-node (AS).
> > > [TOLGA] I think what you call endpoint and what I call
> > > endpoint are totally
> > > different things. The protocol cannot mandate what I put
> > > inside my node and
> > > how I implement it. As long as I say, I have an endpoint
> > > behaving as ASP or
> > > SGP that's fine.
> > > >
> > > >
> > > > > The rest is already defined as ASP/SGP
> > > > > functionality. In
> > > > > my opinion, using just ASP and SGP as endpoint types 
> is enough.
> > > > >
> > > >
> > > > Wrong !! ASP and SGP are NOT endpoint types. SG and AS 
> are. An AS
> > > > can implement both IPSP-IPSP and ASP-SGP communication when
> > > > talking to another AS or SG respectively. As I said before, you
> > > > can consider IPSP or ASP as roles, or communication 
> capabilities,
> > > > but not endpoints...
> > > [TOLGA] I totally diasagree with you. From M3UA point of view
> > > the endpoints
> > > are ASPs and SGPs. Especailly AS, is just an abstraction.
> >
> > Take into account that I said endpoint types, but not just
> > endpoints. The implementation of an enpoint type can be an SGP,
> > an ASP, an IPSP or an ASP/IPSP.
> >
> >
> > Cheers // Javier.
> >
> >
> > > >
> > > > Hope this helps  :-/  :-)
> > > >
> > > > Cheers // Javier.
> > > >
> > > >
> > > >
> > > > >     Tolga
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Javier Pastor-Balbas (ECE)
> > > > > > [mailto:[email-masked]]
> > > > > > Sent: Wednesday, April 24, 2002 8:50 AM
> > > > > > To: 'Tolga Asveren'; [email-masked]
> > > > > > Subject: RE: [Sigtran] IPSP issues
> > > > > >
> > > > > >
> > > > > > Hi Tolga,
> > > > > >
> > > > > > See comments below...
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Tolga Asveren [mailto:[email-masked]]
> > > > > > > Sent: Wednesday, April 24, 2002 2:34 PM
> > > > > > > To: [email-masked]
> > > > > > > Subject: RE: [Sigtran] IPSP issues
> > > > > > >
> > > > > > >
> > > > > > > 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.
> > > > > >
> > > > > > Everything fits with me including ASP-ASP 
> communication (or IPSP
> > > > > > communication) inside of those ASP clouds.
> > > > > >
> > > > > > > I still don't think, we should try to create a new process
> > > > > > > type "IPSP",
> > > > > > > because it is not necessary.
> > > > > >
> > > > > > We don't need to create a new IPSP process since 
> the concept is
> > > > > > already included in the RFC. We just need to solve the open
> > > > > > issues that came up in the Plugtest at ETSI facilities.
> > > > > >
> > > > > > > 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.
> > > > > > >
> > > > > >
> > > > > > That is a choice everyone has to do. We'll 
> implement it since it
> > > > > > is a very important point for the 3rd generation networks.
> > > > > >
> > > > > >
> > > > > > Cheers // Javier.
> > > > > >
> > > > > >
> > > > > >
> > > > > > >     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
> > > > >
> > >
> > >
> > > _______________________________________________
> > > 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