Subject: RE: [Sigtran] document status

From: "Ong, Lyndon" <[email-masked]>
Date: Thu, 16 May 2002 16:31:33 -0700

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Fri, 17 May 2002 10:37:56 -0400

Lyndon,

> From: Ong, Lyndon [mailto:[email-masked]]
> Sent: Thursday, May 16, 2002 7:32 PM
> To: 'Tolga Asveren'; [email-masked]
[TOLGA] The claim is not to define IPSP communication with that draft but I
have to admit it provides a way to let two IP entities to communicate. For
example:

  ******************                ******************
  *                *                *                *
  *   +--------+   *                *   +--------+   *
  *   |        |   *                *   |        |   *
  *   | ASPF   |   *                *   | ASPF   |   *
  *   |        |   *                *   |        |   *
  *   +---+----+   *                *   +---+----+   *
  *       |        *                *       |        *
  *       |        *                *       |        *
  *   +---+----+   *                *   +---+----+   *
  *   |        |   *                *   |        |   *
  *   | SGPF   +---*----------------*---+ SGPF   |   *
  *   |        |   *                *   |        |   *
  *   +--------+   *                *   +--------+   *
  *                *                *                *
  ******************                ******************

or one can even see it as

  ****************          ****************
  *              *          *              *
  * +---------+  *          *  +---------+ *
  * | User    |  *          *  | User    | *
  * | Parts + |  *          *  | Parts + | *
  * |         |  *          *  |         | *
  * | NIF/LM  |  *          *  | NIF/LM  | *
  * +---------+  *          *  +---------+ *
  * |         |  *          *  |         | *
  * |         |  *          *  |         | *
  * |  SGPF   +--*----------*--+  SGPF   | *
  * |         |  *          *  |         | *
  * +---------+  *          *  +---------+ *
  *              *          *              *
  ****************          ****************

The key point is, whether it practically makes sense to base the
communication of two IP domain M3UA entities in a granularity on less than
PC. My personal opinion is it is less likely that this will be needed. For
example, let's say we have n nodes. Then we will have n*(n-1) M3UA
realtionships, if we go with a pure peer-to-peer approach. Any change in the
configuration of one of them will have impact on all of the other n-1 nodes.
This applies also on status changes (AS state changes etc...) during
operation. Especially if one considers that those n nodes might belong to
different operators, from configuration point of view, the idea of
concentration nodes makes sense to me (for example otherwise when operator A
changes CIC ranges in some nodes, also other operators will need to do some
configuration changes). And again in my opinion to base the communciation
between those concentration nodes on a granularity less than PC will be
against the purpose, why we have them. Those are the reasons, why I think
Figure 1 in SG-SG draft is a practical solution.
I think, for SCCP traffic, there is even less need for sub-PC granularity.
It is obvious that M3UA is not suitable to distribute based on SSN.

> over an IP network clear to people?  Are there any concerns with
[TOLGA] Now, for a moment, let's forget about communciation of IP entities
and focus on SS7 backhauling over IP (Figure 2 in SG-SG draft). This would
be possible with M2PA, but I don't see any reason, why M3UA shouldn't be
able to provide such a service and to be honest it makes more sense to me
than the M2PA approach, why should I try to simulate links in IP domain?
> the addition of new messages and parameters?
[TOLGA] There are just 3 messages added. If one changes the behavior after
association establishment -announcing available PCs instead of restricted
and unavailable- one might get rid of TAL. But given the fact that most of
the PCs will be available most of the cases, this will increase number of
messages. For Changeover related messages, I think if one wants to support
the case in Figure 3 in SG-SG draft, one has to have them.