Subject: RE: [Sigtran] document status

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Fri, 17 May 2002 15:06:44 +0200

Hi Lyndon/Tolga, 

I didn't answer before because I thought my view was clear enough, but anyway I'll do it now. :-)

I agree on having this SG-SG communication draft. I support it, and I will help to this to become reality. I haven't still had time to read it, but I'll do it during next week and I'll send my comments.

On the other hand, I don't think we need to define a new IPSP communication. IPSP communication is already defined in the RFC and we don't have to change it for the moment. It is true that it has some holes in the design, and those are what we should fix to finish the RFC in a good way. Regarding this, I plan to realise a new draft that collects how IPSP communication works. It's nothing new but I see the need to have it to work from a clear baseline.

I don't think either that focusing on new works ,without finishing the ones that are going on, is the best option. I would propose:
	1- finish the M3UA as it is first. This means finish the implementor's guide with the hole the current v12 has.
	2- work in SG-SG
	3- More improvements if needed 

Focusing on other issues will delay the end of the current ones...  :-/

Cheers // Javier. 

> -----Original Message-----
> From: Ong, Lyndon [mailto:[email-masked]]
> Sent: Friday, May 17, 2002 1:32 AM
> To: 'Tolga Asveren'; [email-masked]
> Subject: RE: [Sigtran] document status
> 
> 
> Hi Tolga,
> 
> If there is no discussion, I guess I will take that as no opposition.
> However, I want to give people a chance to look over the document, 
> especially if they were not part of the small group discussion.
> 
> For example, does this fulfill what people were looking for in 
> IPSP-to-IPSP transport?  Is the model of SG-to-SG communication
> over an IP network clear to people?  Are there any concerns with
> the addition of new messages and parameters?
> 
> I agree, if people have issues these should be put on the table.
> 
> Cheers,
> 
> Lyndon  
> 
> -----Original Message-----
> From: Tolga Asveren [mailto:[email-masked]]
> Sent: Thursday, May 16, 2002 6:17 AM
> To: [email-masked]
> Subject: RE: [Sigtran] document status
> 
> 
> Lyndon,
> 
> Considering the low amount of interest during the last few 
> months on the WG,
> I  think it might be a little bit too optimistic to get a lot 
> of feedback on
> this issue (till now one person has stated support and nobody 
> objected).
> 
> My goal is not to try to impose some ideas but trying to get 
> a solution for
> a missing piece in the protocol (as most of the people can 
> remember, before
> starting to work on the draft, I asked interested people for 
> help, we formed
> a 10-12 people group and the draft shows the result of those 
> discussions).
> If there are people objecting, I very much would like to get 
> their arguments
> and their proposed solutions so that we can see how to proceed.
> 
>     Cheers,
>     Tolga
> 
> > Finally, Tolga has asked that we make the SG-SG document a 
> working group
> > document,
> > I would like to get comments on this.
> >
> 
> 
> _______________________________________________
> 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

---

From: "Tolga Asveren" <[email-masked]>
Date: Fri, 17 May 2002 09:38:30 -0400

Javier,

> From: Javier Pastor-Balbas (ECE)
> [mailto:[email-masked]]
> Sent: Friday, May 17, 2002 9:07 AM
> To: 'Ong, Lyndon'; 'Tolga Asveren'; [email-masked]
[TOLGA] I know, so my provocative message was just to make you answer :)
>
> I agree on having this SG-SG communication draft. I support it,
> and I will help to this to become reality. I haven't still had
> time to read it, but I'll do it during next week and I'll send my
> comments.
>
> On the other hand, I don't think we need to define a new IPSP
> communication. IPSP communication is already defined in the RFC
> and we don't have to change it for the moment. It is true that it
> has some holes in the design, and those are what we should fix to
> finish the RFC in a good way. Regarding this, I plan to realise a
> new draft that collects how IPSP communication works. It's
> nothing new but I see the need to have it to work from a clear baseline.
[TOLGA] I am also against to change things as much as possible. But still
there are more strategical questions how to proceed with that issue (at
least in my mind). I will try to summarize them in a nother message (as an
answer to Lyndon's questions, because those are really good ones)
>
> I don't think either that focusing on new works ,without
> finishing the ones that are going on, is the best option. I would propose:
> 	1- finish the M3UA as it is first. This means finish the
> implementor's guide with the hole the current v12 has.
> 	2- work in SG-SG

---

From: "Tolga Asveren" <[email-masked]>
Date: Fri, 17 May 2002 12:05:45 -0400

Javier,

> nothing new but I see the need to have it to work from a clear baseline.
[TOLGA] I hope you finish it soon so that we can continue with the new stuff
;) I assume you will continue with the approach, which is making use of ASPF
and SGPF. And just my 2 cents for the double-ended approach, single-ended
approach debate. If the strategy is to see IPSP as a logically combined
ASP/SGP, then I think it is obvious that it should be double-ended approach.
Otherwise state machines should be changed and it won't be anymore reusing
existing functionalities.

---

From: "Tolga Asveren" <[email-masked]>
Date: Fri, 17 May 2002 14:18:13 -0400

Hi Javier,

> nothing new but I see the need to have it to work from a clear baseline.
[TOLGA] If there is nothing to be defined new and just some more
clarifications, then why is "Implementors Guide" not enough for this? It was
said that the only open issue is this double-ended" "single-ended" approach
debate. What else is missing?

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 17 May 2002 14:38:22 -0500

Tolga, Javier,

Continuing along the IPSP approach laid out in the RFC is futile.
Our IPSP discussions yielded the current SG-SG draft.  There is no
need to consider IPSP separate from SG-SG.  I agree that the SG-SG
draft should be made a WG work item to address peer-to-peer operation
for SUA as well as M3UA.

I don't agree with the need for additional messages in the draft.
TRA can be handled with ASPAC and DAUD and changeover (as you aptly
pointed out in previous discussions) can be performed using the
methods described in draft-bidulock-sigtran-corid-00.txt (essentially
always adopting time-controlled changeover).  But, I would rather have
that discussion with the draft as a work item.

IMO the interop demonstrated nothing with regard to the usability of
IPSP in the current RFC.  The interop did not demonstrate actual MTP3
Users interworking over either single- or double-ended approaches, it
only tried exchanging a few M3UA messages.  Certainly the existing
arrangement can no better support lossless changeover than can the
RFC itself which is still missing the chanover and changeback capabilities.

The implementor's guilde should be more than just an interop issues
list.  It was meant to address the defficiencies in the RFC that were
left open by the working group in the spirit of moving the RFC forward.
It would be better to focus on resolution to those defficiencies.  Last
I checked, an ETSI interop was not an official IETF event; however, it
appears to have carried more weight with the authors of the implementors
guide that WG comments.  There has not been an SIGTRAN session at an
IETF plenary in some time.

I will address in detail the concerns and comments that I have on the
Implementor's Guide:  I was just waiting for a few more people to lose
their jobs in this field so that there will be less opposition.

--brian

Tolga Asveren wrote:                                        (Fri, 17 May 2002 14:18:13)

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

---

From: "reshma" <[email-masked]>
Date: Mon, 20 May 2002 13:39:27 +0530

Hi Brian,

    The draft  "draft-bidas-sigtran-sgsg-00.txt" does'nt say anything
specific about IPSP.
I thought it was decided that whatever is there on IPSP in the m3ua draft
needs no
change.Only some more clarifications will be added if needed.Please do
clarify.

Thanks,
Reshma

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 20 May 2002 06:44:45 -0500

Reshma,

What gave you that impression?

--brian

reshma wrote:                                  (Mon, 20 May 2002 13:39:27)
> specific about IPSP.  I thought it was decided that whatever is there on
> IPSP in the m3ua draft needs no change.  Only some more clarifications will
> be added if needed.  Please do clarify.
> 
> Thanks,
> Reshma
> 

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

---

From: "reshma" <[email-masked]>
Date: Mon, 20 May 2002 17:50:09 +0530

Hi Brian,

    As per my understanding IPSP has both SGP and ASP functionality.But
i dont understand how IPSP-IPSP communication relates to SG-SG
communication.Am i missing something?Can u please explain ?

Thanks,
Reshma

----- Original Message -----
From: "Brian F. G. Bidulock" <[email-masked]>
To: "reshma" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, May 20, 2002 5:14 PM
Subject: Re: [Sigtran] document status

> > > Tolga Asveren wrote:                                        (Fri, 17
May
> > 2002 14:18:13)
> > > > clarifications, then why is "Implementors Guide" not enough for
this? It
> > was

---

From: "Tolga Asveren" <[email-masked]>
Date: Mon, 20 May 2002 08:54:28 -0400

Brian,

> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Friday, May 17, 2002 3:38 PM
> To: Tolga Asveren
> Cc: [email-masked]
[TOLGA] So, it seems we will need to redo all of those discussions again.
Well, then it is O.K. for me. I hope this will be the last cycle of this
loop and finally we can reach a consensus.
> that discussion with the draft as a work item.
[TOLGA] Those points were still under discussion but to be able to submit
the draft before it is too late, I went with my approach, so they are still
to be discussed. But i agree with you, it is better to discuss them after
SG-SG is made a WG item.
> RFC itself which is still missing the chanover and changeback
[TOLGA] I want to add something more. Personally I believe that the current
text in m3ua draft is not result of a consensus and unfortunately was put
there just before the draft was frozen to become RFC. Now, this brings a lot
of confusion to the people.
> IETF plenary in some time.
[TOLGA] I hope we will see a new version of Implementor's Guide soon. Or are
we going to wait long enough, so people forget what was discussed and what
the conclusions were, so that we can create some more endless loops? :-)
> this? It was

---

From: "Tolga Asveren" <[email-masked]>
Date: Mon, 20 May 2002 09:06:57 -0400

Reshma,

In my opinion, the current text in M3UA draft was put there prematurely and
unfortunately just before work on it was stopped so that it can become RFC.
Different people have still different opinions. For example, if you are
using just SGPF and ASPF, then why do you need to define it as it was
something new? Everybody is clever enough to combine the provided building
blocks based on the needs of their products. Also please note, rather than
providing a real peer-to-peer realtionship, this approach simulates it with
two client-server relationships.
If you think, that what is needed is a way of letting two nodes in IP domain
to communicate to each other (whether you call it IPSP or not is up to you),
you will see that SG-SG communication also provides a way of doing this. You
can think it as

   **********        ***********
   *+-----+ *        * +-----+ *
   *|ASP1 | *        * |ASP2 | *
   *+--+--+ *        * +--+--+ *
   *   |    *        *    |    *
   *+--+--+ *        * +--+--+ *
   *|SGP1 +-*--------*-+SGP2 | *
   *+-----+ *        * +-----+ *
   **********        ***********

or

 ***********        ***********
 * +-----+ *        * +-----+ *
 * |U.P  | *        * |U.P  | *
 * +-----+ *        * +-----+ *
 * |SGP1 +-*--------*-+SGP2 | *
 * +-----+ *        * +-----+ *
 ***********        ***********

SG-SG is also needed for a reasonable way of configuration and to transfer
between two SS7 entities, because it provides relaying functionality.

As I said , different people have different opinions, those are just my
personal opinions.

   Tolga

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> reshma
> Sent: Monday, May 20, 2002 8:20 AM
> To: [email-masked]
> Cc: [email-masked]
> > > > > > finishing the ones that are going on, is the best
> option. I would
> > > propose:
> > > > > > Focusing on other issues will delay the end of the
> current ones...
> > > :-/
> > > > > >
> > > > > > Cheers // Javier.
> > > > > >
> > > >
> > > > --
> > > > Brian F. G. Bidulock
> > > > [email-masked]
> > > > http://www.openss7.org/
> > > >

---

From: "reshma" <[email-masked]>
Date: Mon, 20 May 2002 19:28:42 +0530

Hi Tolga,

    Some more doubts below.
----- Original Message -----
From: "Tolga Asveren" <[email-masked]>
To: <[email-masked]>
Sent: Monday, May 20, 2002 6:36 PM
Subject: RE: [Sigtran] document status

> unfortunately just before work on it was stopped so that it can become
RFC.

[Reshma] Does this mean IPSP section in the draft is no more valid?

> you will see that SG-SG communication also provides a way of doing this.
You

[Reshma] Just to clarify . What I call IPSP-IPSP communication ,
is what you call SG-SG  communication?

[Reshma] Again Just to clarify here ASP and SGPs are ASPF and SGPFs  right?
Or am i wrong..?

> or

[Reshma]I Am not clear about this.Can u please explain me what do u
mean by relaying functionality here.?

> As I said , different people have different opinions, those are just my

Thanks
Reshma

> > > > IPSP in the m3ua draft needs no change.  Only some more
clarifications
> > will
> > > > > > said that the only open issue is this double-ended"
"single-ended"
> > > > approach

---

From: "Tolga Asveren" <[email-masked]>
Date: Mon, 20 May 2002 10:18:48 -0400

Reshma,

> From: reshma [mailto:[email-masked]]
> Sent: Monday, May 20, 2002 9:59 AM
> To: Tolga Asveren
> Cc: [email-masked]
[TOLGA] No, it means in my opinion it is not necessary. But I think nobody
will object that it was put there without consensus. So, I wouldn't think
any changes there as changing something major in the m3ua draft, because it
was never really defined by a group consensus. I think in the following days
we will have more discussions and I hope we will finally reach a consensus.
> is what you call SG-SG  communication?
[TOLGA] Not exactly. In my opinion, there is no need to call something
specifically IPSP. We have building blocks, ASPF, SGPF. SG-SG draft defines
just the communication between SGs, so it is up to you how to combine those
building blocks. I think, the crucial point is, those are not node types but
defined functionalities. So, you can combine them as you want in your
product, as long as you are compliant with the draft.
> [Reshma] Again Just to clarify here ASP and SGPs are ASPF and
[TOLGA] Yes.
> mean by relaying functionality here.?
[TOLGA] It means to act as an IP-STP between IP or SS7 domain entities.
> > > From: [email-masked]
> [mailto:[email-masked]]On Behalf Of
> > > reshma
> > > > > > IMO the interop demonstrated nothing with regard to the
> usability
> of
> > > > > > It would be better to focus on resolution to those
> defficiencies.
> > > Last
> > > > > > guide that WG comments.  There has not been an SIGTRAN
> session at
> an
> > > > > > Tolga Asveren wrote:
>     (Fri,
> 17
> > > > > > > > nothing new but I see the need to have it to work
> from a clear
> > > > > baseline.

---

From: "reshma" <[email-masked]>
Date: Mon, 20 May 2002 20:14:01 +0530

Hi Tolga,
> > > In my opinion, the current text in M3UA draft was put there
prematurely
> > and
> > > you will see that SG-SG communication also provides a way of doing
this.
> product, as long as you are compliant with the draft.

[Reshma] Does this mean that once we implement SG-SG communication ,
Any two nodes can communicate in the IP domain using this functionality?
Is SG-SG communication defined as a result of need for reliability as  in
SS7
network or peer to peer communication ?Please correct me if i am wrong

> > > > > > > > > I agree on having this SG-SG communication draft. I
support
> > it,
> > > > > > > > > communication. IPSP communication is already defined in
the
> > RFC

---

From: "Tolga Asveren" <[email-masked]>
Date: Mon, 20 May 2002 11:02:12 -0400

Reshma,

> network or peer to peer communication ?Please correct me if i am wrong
[TOLGA] If you have SG-SG communication, you can have different
configurations to achieve this. Two of them are like I draw in my previous
messages

         **********        ***********
         *+-----+ *        * +-----+ *
         *|ASP1 | *        * |ASP2 | *
         *+--+--+ *        * +--+--+ *
         *   |    *        *    |    *
         *+--+--+ *        * +--+--+ *

       ***********        ***********
       * +-----+ *        * +-----+ *
       * |U.P  | *        * |U.P  | *
       * +-----+ *        * +-----+ *

The third one is the Figure1 in SG-SG draft:

     -----              -----
   //     \\          //     \\
  |  ASP    |        |  ASP    |
  |  Cloud 1|        |  Cloud 2|
   \\     //          \\     //
     --+--              --+--
       |                  |
       |                  |
    +--+--+            +--+--+
    | SG1 +------------+ SG2 |
    +--+--+            +--+--+
       |                  |
       |                  |
       |                  |
       |     +-----+      |
       +-----+ SG3 +------+
             +--+--+
                |
                |
              --+--
            //     \\
           |  ASP    |
           |  Cloud 3|
            \\     //
              -----

SG-SG communication is not a result of a need of extra reliability. But it
enables a reasonably configurable architecture and transport between SS7
nodes over IP in addition to defining a real peer-to-peer relationship
between two M3UA entities (SGs).