Subject: IPSP text - poll

From: "Ong, Lyndon" <[email-masked]>
Date: Thu, 8 Nov 2001 18:37:39 -0800

Folks,

Boy, we've gone in a lot of directions on this one.  Can I take a poll
to see where we are?  I'd like reactions to the following:

1) How does an IPSP talk to an IPSP?
   (a) sends like an SG, receives like an ASP (multiple RCs)
   (b) sends like an SG, receives like an SG
   (c) either one

2) What needs to be done to the protocol?
  (a) nothing
  (b) something (specify what)

3) What needs to be done to the specification?
  (a) take out IPSP
  (b) add model and examples of IPSP to IPSP
  (c) add model and examples of SG to SG
  (d) other (specify what)

Thanks,

Lyndon

---
You are currently subscribed to sigtran as: [email-masked]
To unsubscribe send a blank email to [email-masked]

---

From: Verwimp Gery <[email-masked]>
Date: Fri, 9 Nov 2001 09:48:56 +0100

Hello Lyndon,

It looks like the WG is at a turning point. Question 0) should be answered
first :

0) Does the WG want to explore an IPSP concept based on ASPSM/TM (IPSPSM/TM)
?

If not, then the answers to the questions below are straightforward :

1) IPSP-IPSP communication is a copy of SS7 over SCTP (DATA+SNMM), RK/RC
doesn't enter into it.

2) Nothing, except no ASPSM/TM messages are needed between IPSPs

3) (d) the IPSP is modelled as SS7 node, with internal use of ASP-SG
concepts.

Regards,

____________________________

Gery Verwimp
> SIEMENS ATEA
> ICN D CS D5
> Tel. : +32 14 25 3424
Fax : +32 14 25 3212
mailto:[email-masked]
____________________________________

-----Original Message-----
From: Ong, Lyndon [mailto:[email-masked]]
Sent: vrijdag 9 november 2001 3:38
To: sigtran
Subject: IPSP text - poll

Folks,

Thanks,

Lyndon

---
You are currently subscribed to sigtran as: [email-masked]
To unsubscribe send a blank email to
[email-masked]

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 9 Nov 2001 03:20:20 -0600

Gery,

Verwimp Gery wrote:                (Fri, 09 Nov 2001 09:48:56)
> first:

That's a little drastic.  SGs can still use override, loadshare and
broadcast between them (SGP are allowed to do this).  ASPSM/TM can be
left alone (single-ended).  ASPTM does not require RC (but it is optional
anyway) because RC (or lack thereof) is implicit to the association.

So, maybe suprising to some, no changes to ASPTM/SM would be needed.

All that would be required is a clarification of the state machines
and procedures: which is what was asked for in the M3UA/SUA issue in
the first place.

--brian

> Fax: +32 14 25 3212
> You are currently subscribed to sigtran as: [email-masked]

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

---

---

From: [email-masked]
Date: Fri, 9 Nov 2001 15:26:43 +0200

Hi Lyndon,

I've been stuck in meetings all week, so I need to catch up
on some mails (or maybe I'd be better of not ready any ...)

>    (b) sends like an SG, receives like an SG

c - I think if we model as client-server, where either
end could take on either role, that would be suffiecient.
 
>   (b) something (specify what)

I agree with Brian:

 "All that would be required is a clarification of the state 
  machines and procedures: which is what was asked for in the 
  M3UA/SUA issue in the first place."

I think Javier's text goes a long way towards this, but
there is some room for improvement.
 
>   (c) add model and examples of SG to SG

d - see Brian's comment above.

best regards,
John

---

---

From: [email-masked]
Date: Fri, 9 Nov 2001 06:21:20 -0800

Hi,

Please see my comments/votes   below.

   Tolga

> From:   "Ong, Lyndon" <[email-masked]>
> Sent:   Thursday, November 08, 2001 9:43 PM
> To:     "sigtran" <[email-masked]>
> Cc:
[TOLGA] In my opinion, it is a good sign that during discussions the
initial ideas are evolving to other ideas, this just shows that we are
making progress.
>    (b) sends like an SG, receives like an SG
[TOLGA] (d) :-)  In the proposed IPSP model it was sending like an ASP and
receiving like an SG. And only one RC is used.
>   (b) something (specify what)
[TOLGA] For the proposed IPSP model by Javier, not needs to be done the
protocol , so (a). Because it is just a way of configuring the the regular
SG/ASP case in a specific way.
>   (c) add model and examples of SG to SG
[TOLGA] (a) + (c).   And because of (a), the first two questions are not
important anymore.
> Thanks,
> Lyndon
> ---
> You are currently subscribed to sigtran as: [email-masked]

---

---

From: Dennis Niermann <[email-masked]>
Date: Fri, 09 Nov 2001 08:17:09 -0600

My IPSP votes are
1 (a)
2 (a)
3 (b)

Extra comment: I think that the call for improvements in the 
document related to state machines, etc. are a good idea, but
are more of a general issue and are not specific to IPSP.

/Dennis  

"Ong, Lyndon" wrote:
> You are currently subscribed to sigtran as: [email-masked]

-- 
---------------------------------------------------------------
 Dennis Niermann              [email-masked]
 Ericsson Network Systems   
 Richardson, Tx 75081

---

---

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Mon, 12 Nov 2001 18:37:28 +0100

Resend...

-----Original Message-----
From: Javier Pastor-Balbas (ECE) 
Sent: Monday, November 12, 2001 9:42 AM
To: [email-masked]'
Subject: RE: IPSP text - poll

Hi Lyndon, 

Here are my votes...

> Sent: Friday, November 09, 2001 3:38 AM
> To: sigtran
(a)
Although there is a RC in each direction only one of them is used in DATA when required.

>   (b) something (specify what)
(a)
No changes are needed. In fact, we should be able of use all the already defined concepts and procedures

>   (c) add model and examples of SG to SG
(b)
SG to SG can be included in an extension draft. What is required for 3G is IP-node to IP-node communication.

Cheers // Javier.

> Thanks,
> 
> Lyndon
> 
> 
> 
> 
> ---
> You are currently subscribed to sigtran as: 
> [email-masked]

---

---

From: [email-masked]
Date: Mon, 12 Nov 2001 10:29:07 -0800

Hi Javier,

Although the discussions about how to implement IPSP were long, only very
little time is spent recently about whether IPSP concept is usefull or not.
I think most of the people are agreeing that an IPSP as defined by your
proposal will work fine. But the question here is, whether it is something
new. It is just a way of configuring a system, which is consisting of 1 ASP
and 1 SG. Why should we put it as a new concept to the draft? It is already
allowed with the conventional SG/ASP model.
Rather then putting it as a new concept, maybe we can give it as a sample
configuration of regular ASP/SG case. Wouldn't this reflect the situation
better?

    Tolga

> From:   "Javier Pastor-Balbas (ECE)"
> <[email-masked]>
> Sent:   Monday, November 12, 2001 12:52 PM
> Subject:     FW: IPSP text - poll
>
>  Resend...
> No changes are needed. In fact, we should be able of use all
> the already defined concepts and procedures
> SG to SG can be included in an extension draft. What is
> required for 3G is IP-node to IP-node communication.
> Cheers // Javier.
> > Thanks,
> >
> > Lyndon
> >
> >
> >
> >
> > ---

---

---

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Mon, 12 Nov 2001 20:00:56 +0100

Tolga, 

It was not something new indeed. But people were complaining that there was not explanation at all of how all these stuff works. And we agreed on that. That's the reason why we decided to explain it a little bit longer. 

From my point of view IPSP is not a way of configuring a system. In fact I don't like to see the word SG in it since we don't have SS7 links in an IP node. I can see it as mixing all the procedures and concepts that we already have in the current draft to make it possible to communicate two SS7 applications located in the middle of an IP cloud amongst themselves. Hence I would say IPSP has a mixture of ASP and SGP functionality. Evenmore, you could easily develop a node that implements both functionalities. Take a look to the change it is performed in the network adding this capability in the next drawings...

Current scenario:
                                     (ASP)  
          ***** SG ---------------- SS7Applic 
           SS7            IP             

           SS7            IP            
          ***** SG ---------------- SS7Applic
                                      (ASP)

Current scenario + IPSP communication:

                                   (ASP/IPSP)              (IPSP)              (IPSP)
          ***** SG ---------------- SS7Applic =========== SS7Aplic =========== SS7Aplic
           SS7           IP             ||         IP                  IP         ||
                                        ||                                        ||
                                        ||IP                                    IP||           
           SS7           IP             ||         IP                  IP         ||
          ***** SG ---------------- SS7Applic=========== SS7Aplic =========== SS7Aplic                           
                                  (ASP/IPSP)              (IPSP)              (IPSP)

With the latter, we can start thinking of a Signaling network over IP. (IPSP communication is depicted with double lines)

What do we need to make communication between two SS7 application inside an IP cloud possible? Route messages from one application to the other. How do we achieve this in M3UAv09 draft? With the help of RK. So let's do it in the same way then.

I would agree on what you say if I would see that an IPSP has a SS7 connectivity. But I don't go along with that. 

If we need or not this text is another matter. As I told you before, it was an important issue that was decided to deal with. My personal opinion is yes, since it clarifies how the IPSP communication is performed with specific adaptations to IPSP and examples. It is always good to explain things a little bit more... Don't you think it could be helpful to other people?

Cheers // Javier.

> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, November 12, 2001 7:29 PM
> To: Javier Pastor-Balbas (ECE); sigtran
> Subject: RE: FW: IPSP text - poll
> 
> 
> Hi Javier,
> 

---

---

From: "Schantz, John" <[email-masked]>
Date: Mon, 12 Nov 2001 11:25:48 -0800

Here-here!  I agree with you, Javier.

I see AS-SG only as the initial step.  Not for the ability of a node to
have SS7 access via an IP connection BUT to allow IP ready nodes the
immediate use of the increased capacities/throughput available via IP
connectivity.

The next step would be to extend the reach of M3UA between SGs so that
the IP/SS7 network can grow and allow end-to-end M3UA communication
AS-SG-SG-AS.  It doesn't make sense to change transport protocols in
mid-stream and then convert back again.

The final step, when there are many IP enable nodes, is to go point to
point via M3UA:  AS - AS (IPSP - IPSP).  For some networks, this will be
a realistic goal since the traffic between some of these nodes could
easily be in the hundreds to thousands of messages per second, hence
justifying the direct communication.

I fully plan on supporting both an SG and an IPSP connections.  I think
the IPSP-IPSP step is coming sooner that most people think it is
(probable before the SG-SG step).

John

> [mailto:[email-masked]]
> Sent: Monday, November 12, 2001 1:01 PM
> To: sigtran
> It was not something new indeed. But people were complaining 
> that there was not explanation at all of how all these stuff 
> works. And we agreed on that. That's the reason why we 
> decided to explain it a little bit longer. 
> 
> From my point of view IPSP is not a way of configuring a 
> system. In fact I don't like to see the word SG in it since 
> we don't have SS7 links in an IP node. I can see it as mixing 
> all the procedures and concepts that we already have in the 
> current draft to make it possible to communicate two SS7 
> applications located in the middle of an IP cloud amongst 
> themselves. Hence I would say IPSP has a mixture of ASP and 
> SGP functionality. Evenmore, you could easily develop a node 
> that implements both functionalities. Take a look to the 
> change it is performed in the network adding this capability 
> in the next drawings...
> 
> 
> Current scenario:
>                                      (ASP)  
>                                    (ASP/IPSP)              
> (IPSP)              (IPSP)
>            SS7           IP             ||         IP         
>          IP         ||
>                                         ||                    
>                     ||
>                                         ||IP                  
>                   IP||           
>            SS7           IP             ||         IP         
>          IP         ||
>                                   (ASP/IPSP)              
> (IPSP)              (IPSP)
> With the latter, we can start thinking of a Signaling network 
> over IP. (IPSP communication is depicted with double lines)
> 
> What do we need to make communication between two SS7 
> application inside an IP cloud possible? Route messages from 
> one application to the other. How do we achieve this in 
> M3UAv09 draft? With the help of RK. So let's do it in the 
> same way then.
> 
> I would agree on what you say if I would see that an IPSP has 
> a SS7 connectivity. But I don't go along with that. 
> 
> If we need or not this text is another matter. As I told you 
> before, it was an important issue that was decided to deal 
> with. My personal opinion is yes, since it clarifies how the 
> IPSP communication is performed with specific adaptations to 
> IPSP and examples. It is always good to explain things a 
> little bit more... Don't you think it could be helpful to 
> other people?
> 
> 
> Cheers // Javier.
> 
> 
> You are currently subscribed to sigtran as: [email-masked]

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 12 Nov 2001 15:00:51 -0600

Tolga,

If it were only the conventional ASP/SG model: but Javier/Dennis'
appoach splits the SG and places only half in each IPSP and
requires the ASP components to register with both halves.

This approach is inherently flawed because it splits that SG
state.  This causes many problem scenarios in attempting to
manage this split state.

I say (b)-(b)-(c).

--brian

[email-masked] wrote:                        (Mon, 12 Nov 2001 10:29:07)
> You are currently subscribed to sigtran as: [email-masked]

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

---

---

From: [email-masked]
Date: Mon, 12 Nov 2001 13:42:46 -0800

Brian,

Please see comments below.

  Tolga

> From:   "Brian F. G. Bidulock" <[email-masked]>
> Sent:   Monday, November 12, 2001 4:09 PM
> Cc:     [email-masked]
> Subject:     Re: FW: IPSP text - poll
>
>  Tolga,
[TOLGA] My interpretation of the model proposed by Javier/Dennis is that
there are two different SGs. One per IPSP. In fact it is not very correct
to call them SGs. Maybe M3UA routers? When we see their model with boxes
consisting of ASP+SG functionality - SS7 functionality, I think it should
work. Because it mimics ASP/SG  situation quite well.

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 12 Nov 2001 15:54:47 -0600

Tolga,

[email-masked] wrote:                        (Mon, 12 Nov 2001 13:42:46)
> work. Because it mimics ASP/SG  situation quite well.

Unfortunately each ASP half-registers with each of two SGs.  That's
were the problems start.

--brian

> You are currently subscribed to sigtran as: [email-masked]

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

---

---

From: "Ong, Lyndon" <[email-masked]>
Date: Mon, 12 Nov 2001 14:00:15 -0800

Hi Folks,

What I found interesting about the discussion was 
the fact that

a) there seem to be a variety of views about what an "IPSP" is and
how it functions and

b) people largely believe that no protocol changes are required
(albeit some clarifications - we should pin down further
what clarifications are required).

I think we should keep in mind that M3UA and SUA are protocols, 
and not specifications for node design.  We should avoid putting
in a lot of material on how a particular node type functions,
especially if as in (a) we don't agree on this.

My suggestion is that we focus on any necessary clarifications or
clean-ups in the main text to allow both ASP-SG and SG-SG communication
and put any IPSP material into an appendix that can describe multiple
models for an IPSP, using the same core protocol.

Cheers,

L. Ong

---

---

From: Tolga Asveren <[email-masked]>
Date: Mon, 12 Nov 2001 16:11:49 -0800 (PST)

Brian, Javier and all,

Please see questions/commnets below.

   Tolga

--- "Brian F. G. Bidulock" <[email-masked]>
> Unfortunately each ASP half-registers with each of
[TOLGA] In fact if the interface between ASP and
SG-like functionalities is done internal to the IPSP
box, then it should work. In such a case, ASP will
send everything it wants to send to its peer via its
internal interface to SG module of the same IPSP box,
instead of deciding for a SGP, based on activeness of
the RK. Of course, this means, it is no more the same
like an ASP in the regular ASP/SG case.But maybe this
can also justify to have IPSP boxes, it won't be
anymore just a configuration of regular SG/ASP case.
Currently I see three different ways for communication
between M3UA entities in IP domain:
1) IPSP approach as described by Javiers proposal. I
assume that ht einterface between local SG/ASP
functionalities will be internal. Will this entity be
able to communicate also with regular SGs?
 
2) Using SG as a M3UA router (and maybe if it does not
have SS7 interface, calling it also M3UA router)

    +----+  +----+           +----+
    |ASP1|  |ASP2|           |ASPn|
    +---++  +---++ . . . .   +-+--+
        |       |              |
        |       |              |
      +-+-------+--------------+-+
      |      SG                  |
      |  (M3UA Router)           |
      +--------------------------+

This has the advantage of easier configuration
(instead of n*(n-1) route key entries , 2*n route key
entries) over IPSP approach, but could be slower
because in IPSP approach interface between local
ASP/SG functionalities will be internal , while here
it is over IP. This configuration is already allowed
with regular SG/ASP concept.

3) Defining the communciation between SGs(M3UA
Routers)

    //-----\\            //-----\\
  || ASP     ||        ||ASP      ||
   |cloud1   |          |cloud2   |
    \\--+--//            \\--+--//
        |                    |
        |                    |
   +----+---+          +-----+---+
   |SG(M3UA |          |SG(M3UA  |
   |Router)1+----------+Router)2 |
   +--------+          +---------+

This again enables easier configuration, by possibly
decreasing number of route keys entries to be defined
in the whole system.

> 
> > 
> > > I say (b)-(b)-(c).
> > > --brian
> > > [email-masked] wrote:                    
>    (Mon, 12
> > > Nov 2001 10:29:07)
> > > > Hi Javier,
> > > >
> > > > Although the discussions about how to
> implement IPSP were
> > > long, only very
> > > > little time is spent recently about whether
> IPSP concept is
> > > usefull or not.
> > > > I think most of the people are agreeing that
> an IPSP as
> > > defined by your
> > > > proposal will work fine. But the question here
> is, whether
> > > it is something
> > > > new. It is just a way of configuring a system,
> which is
> > > consisting of 1 ASP
> > > > and 1 SG. Why should we put it as a new
> concept to the
> > > draft? It is already
> > > > Rather then putting it as a new concept, maybe
> we can give
> > > it as a sample
> > > > configuration of regular ASP/SG case. Wouldn't
> this reflect
> > > the situation
> > > > better?
> > > >
> > > >     Tolga
> > > >
> > > > > > Boy, we've gone in a lot of directions on
> this one.  Can I
> > > > > take a poll
> > > > > Although there is a RC in each direction
> only one of them is
> > > > > used in DATA when required.
> [email-masked]
> [email-masked]
> [email-masked]
=== message truncated ===

__________________________________________________
Do You Yahoo!?
Find a job, post your resume.
http://careers.yahoo.com

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 12 Nov 2001 18:41:01 -0600

Tolga,

Please see comments below...

Tolga Asveren wrote:                                        (Mon, 12 Nov 2001 16:11:49)
> > (Mon, 12 Nov 2001 13:42:46)
> > > Brian,
> > > 

> able to communicate also with regular SGs?

But Javiers proposal does not describe an internal
interface: it describes a interface between ASPs and
SGs that are half-internal (one traffic direction)
and half-external (the other traffic direction).

This approach cannot work unless heavy restrictions are
placed on IPSP connectivity and the selection of routing
keys.

> have SS7 interface, calling it also M3UA router)

Who owns the SG?  Approach (2) is somewhat limited
to a single operator's network and still focusses
on backhaul.

> 3) Defining the communciation between SGs(M3UA

The ony practical approach.

--brian

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

---

---

From: [email-masked]
Date: Tue, 13 Nov 2001 10:17:20 +0200

Hi Lyndon,

> what clarifications are required).

No protocol changes are needed, some text could/should be added
to chapter 4.  See the current version of SUA as a starting
point. 

Additionally, I think Javier captured some changes to the
state machine that would be supported.

I will try to get time to capture this all in the next day or two.

> especially if as in (a) we don't agree on this.

I agree!
 
> models for an IPSP, using the same core protocol.

I suggest that we more fully address this in an Applicability
Statement document.  In such a document we can discuss the
usage & provisioning of RKs & RCs ...

best regards,
John

---

---

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Tue, 13 Nov 2001 14:56:45 +0100

Hi Tolga and others, 

I answer your question...

> From: Tolga Asveren [mailto:[email-masked]]
> Sent: Tuesday, November 13, 2001 1:12 AM
> To: sigtran
(snip)
[...]
(snip)
> able to communicate also with regular SGs?

First of all, the interface between SG and ASP functionalities is internal. When you send a message you will call to the sending message funcition that will activate the way in which SG send data, and when you receive, you'll use the ASP functions.

An IPSP node can be seen as a role that a node can have. Till now we had the only option of communicating an IP node with a SG. If we want to create another kind of communication (two IP nodes), we will need another description of how things are. This is what is called IPSP communication.  

An node in the IP world with an SS7 application can be able to communicate to another SG and to another SS7 application in the IP world. It depends of how your design your nodes. You can design a node that implements both capabilities or only one. It depends on your company policy. Take a look to the drawing I sent before. I would define a generic node with the SS7 application over IP. This node have two capabilities: it can talk to SG or to other IP-based SS7 applications.

> have SS7 interface, calling it also M3UA router)

The main problem with this approach is the speed, as you say. Take into account that in real networks as we are moving towards all-IP there will be more AS-AS traffic than AS-SG. You delay the message and can overload the SG inneccessarily.

> 3) Defining the communciation between SGs(M3UA
I see here the same problems as before. You again delay the messages and can overload the SGs. Why do you need to use SGs if you can only imply those nodes interested in communication? The SG is getting more and more complicated when it was initially only a point to convert SS7 into IP transport. If you take this configuration you will have to manage RK that belongs to ASs that don't want to receive SS7 traffic from the SS7 network and those that want, but anyway you would have to differenciate both cases; you will need all the knowledge of how your network is deployed, that is, what SG can give the way to the final AS. This means more routing tables. This means that you'll have to pass two routing devices to get your destination. And those routing devices also are working in adapting traffic from IP to SS7 and vice versa.

From my point of view, the right choose would be the direct communication, no intermediaries:

     //-----\\            //-----\\
   || ASP     ||--------||ASP      ||
    |cloud1   |          |cloud2   |
     \\--+--//            \\--+--//

On the other hand I also see interesting the communication between SGs, but as John Schantz mentions, it can come up after       IPSP. I see it as an extension draft that we can produce after sending this IPSP stuff to the IESG. Divide and win.

Cheers // Javier.

---

---

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Tue, 13 Nov 2001 15:15:23 +0100

Hi Lyndon, 

Comments below...

> Sent: Monday, November 12, 2001 11:00 PM
> To: sigtran
Yes, you are right.

> models for an IPSP, using the same core protocol.

Yes, but I think that we are talking about several things that were covered in the previous discussions. I see two points to be solved that come up from Tolga's mail:

- Communication of two IP nodes (with an SS7 application over it). We can call it IPSP communication.
- Communication SG-SG.

My personal view is to solve the former for this draft, and leave the second for an extension draft, since it was only the IPSP cases, what was discussed to be better explained. The other point (SG-SG communication) is something completely new that we have to think from the scratch. 

I reproduce here the drawing I sent before, trying to get a common understanding:

1- Current scenario:

                                     (ASP)  

           SS7            IP            

2- Current scenario + IPSP communication (double line)

                                   (ASP/IPSP)              (IPSP)              (IPSP)

3- Current scenario + IPSP communication + SG-SG communication (++++):

                                   (ASP/IPSP)              (IPSP)              (IPSP)
           SS7   +       IP             ||         IP                  IP         ||
                 + IP                   ||                                        ||
                 +                      ||IP                                    IP||           
           SS7   +       IP             ||         IP                  IP         ||

I'd prefer to get till step two to have the specs ready as soon as possible. But I think the WG has to decide. I think having both (2 and 3) would delay the RFC till second quarter of next year at least... Is that point possible, Lyndon? Do you think we have to get 2 and 3? Only one? Which one?

I've I said before, 3G networks only needs number 2 as compulsory....

Cheers // Javier.

---

---

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Tue, 13 Nov 2001 15:31:03 +0100

Hi John, 

See comments below...

> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, November 13, 2001 9:17 AM
> To: sigtran

Could you please address the technical differences between what SUA has right now and the 2nd proposal I sent out?
Maybe this could be a good start to see how to evolve... 

The proposal I sent out follows completely what was writen in SUA and it was indeed, what we agreed before the last versions were out. The only difference is that M3UA didn't include the text waiting to have a more ellaborated redaction.

> usage & provisioning of RKs & RCs ...

SG-SG communication is completely new. IPSP is not and it is referred all over the draft. 

On the other hand you can not leave inter-operability issues to be included in an Applicability statement. If you don't define these procedures in the protocol itself, two IP nodes trying to communicate using M3UA/SUA, can never know how to talk to each other. I'm afraid IPSP procedures can not be part of an informational document as the RK management for SG-AS is not. If we want to leave these IPSP stuff inside the draft, we should define how it works. If not, we just have to remove all the references to IPSP and leave this scenario for an extension technical draft (not an informational one).

Cheers // Javier.

> [email-masked]

---

---

From: [email-masked]
Date: Wed, 14 Nov 2001 08:58:22 +0200

Hi Javier,

> Could you please address the technical differences between 
> what SUA has right now and the 2nd proposal I sent out?
> The proposal I sent out follows completely what was writen in 
> SUA and it was indeed, what we agreed before the last 
> versions were out. The only difference is that M3UA didn't 
> include the text waiting to have a more ellaborated redaction.

That is correct.  I will re-review your text & send comments
today.  All of the side discussions have distracted me. My
day job has been keeping me fairly busy as well.

John

---