Subject: RE: [Sigtran] m3ua:IPSP

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Thu, 6 Jun 2002 09:24:16 +0200

Hi Reshma, 

I would participate in discussions focused on solving any problem found in the current SE IPSP model therefore. I think a text could be a good basis to find out what is missing and work no that. 

But I would not like starting again all the comparison between the two models and circular discussions without end. Simply they are two different points to work on.  

Cheers// Javier.

> -----Original Message-----
> From: reshma [mailto:[email-masked]]
> Sent: Thursday, June 06, 2002 9:19 AM
> To: Javier Pastor-Balbas (ECE); 'Tolga Asveren'; [email-masked]
> Subject: Re: [Sigtran] m3ua:IPSP
> 
> 
> Hi Javier ,
> 
>     As per previous discussions all agreed for SE IPSP approach
> and leave out DE approach .It will be better if we have more
> discussion on SE approach .
> 
> Thanks,
> Reshma
> ----- Original Message -----
> From: "Javier Pastor-Balbas (ECE)" 
> <[email-masked]>
> To: "'Tolga Asveren'" <[email-masked]>; <[email-masked]>
> Sent: Thursday, June 06, 2002 12:30 PM
> Subject: RE: [Sigtran] m3ua:IPSP
> 
> 
> > Hi Tolga,
> >
> > Thanks a lot for your constructive efforts. :-)
> >
> > But we need to forget about comparisons and just finish IPSP to make
> current RFC interoperable, as Lyndon said. I'm sending the 
> proposed text to
> the mailing list in a few days.
> >
> > Hopefully this issue will be finished before the Yokohama meeting...
> >
> >
> > Cheers // Javier.
> >
> >
> >
> > > -----Original Message-----
> > > From: Tolga Asveren [mailto:[email-masked]]
> > > Sent: Thursday, June 06, 2002 2:30 AM
> > > To: [email-masked]
> > > Subject: [Sigtran] m3ua:IPSP
> > >
> > >
> > > With the hope to move forward, please see some questions/comments
> > > (constructive ones ;-) ) and what I understood till now from
> > > our discussions
> > > below (please comment especially on different 
> configurations below)
> > >
> > > I agree with Brian that SG-SG also could be considered as IPSP
> > > communication. To me, the important point is, whether it defines a
> > > point-to-point M3UA relationship or not, and it really
> > > defines one between
> > > M3UA-SGPFs. Communication is based on SPMC(PC) and management
> > > of traffic on
> > > SSNM. On the other hand, by selecting SE over DE and with
> > > symmetric RKs (for
> > > this we have decided right? ) we had a good step to a 
> point-to-point
> > > relationship . Still it won't be M3UA-ASP-to-M3UA-ASP,
> > > because still we will
> > > need routing functionality, but this is not so terrible. Here
> > > communication
> > > is based on RKs (which are symmetric and are defining traffic
> > > at both ends)
> > > and traffic management is based on ASPTM. This model will
> > > bring a different
> > > state machine and in my opinion this is not very elegant,
> > > because this will
> > > make additional state machines/logic necessary, if we want
> > > the same node to
> > > communicte with ASPs and SGPs, not impossible but also 
> not nice in my
> > > opinion:
> > >
> > >  ************
> > >  *          *
> > >  * +------+ *
> > >  * |U.P/  | *
> > >  * |NIF   | *
> > >  * +------+ *
> > >  * |ASPF  | *
> > >  * |      | *
> > >  * +--+---+ *
> > >  ************  ************************      ***********
> > >       |        *+-------------------+ *      * +------+*
> > >       |        *|  U.P/ NIF         | *      * |U.P/  |*
> > >       |        *|                   | *      * |NIF   |*
> > >       |        *+------+------+-----+ *      * +------+*
> > >       +--------*+SGPF  |ASPF  |IPSPF| *      * |IPSPF |*
> > >                *|      |      |     +-*------*-+      |*
> > >                *+------+---+--+-----+ *      * +------+*
> > >                *           |          *      *         *
> > >                ************************      ***********
> > >                            |
> > >                       ************
> > >                       * +--+---+ *
> > >                       * |SGPF  | *
> > >                       * |      | *
> > >                       * +--+---+ *
> > >                       ************
> > >                            |
> > >                            |
> > >                            |
> > >                            |
> > >                            |
> > >                           -+--
> > >                         //    \\
> > >                        |        |
> > >                       |  SS7     |
> > >                        |        |
> > >                         \\    //
> > >                           ----
> > > To be honest, in such a mixed configuration, I would prefer
> > > SG-SG solution:
> > >
> > >   ************       ************        ************
> > >   * +------+ *       * +------+ *        * +------+ *
> > >   * |U.P/  | *       * |U.P/  | *        * |U.P/  | *
> > >   * |NIF   | *       * |NIF   | *        * |NIF   | *
> > >   * +------+ *       * +------+ *        * +------+ *
> > >   * |ASPF  | *       * |SGPF  | *        * |ASPF  | *
> > >   * |      +-*-------*-+      +-*--------*-+      | *
> > >   * +------+ *       * +--+---+ *        * +------+ *
> > >   ************       ************        ************
> > >                           |
> > >                           |
> > >                           |
> > >                      ************
> > >                      * +--+---+ *
> > >                      * |SGPF  | *
> > >                      * |      | *
> > >                      * +--+---+ *
> > >                      ************
> > >                           |
> > >                           |
> > >                           |
> > >                           |
> > >                          -+---
> > >                        //     \\
> > >                       | SS7     |
> > >                       |         |
> > >                        \\     //
> > >                          -----
> > >
> > > Now if we consider different cases:
> > > 1- PC granularity
> > > Because of the reason explained above, for this granularity I
> > > would prefer
> > > SG-SG approach. Also for PC granularity, we need to have DUPU for
> > > M3UA-IPSPF-to-M3UA-IPSPF approach, not the end of the 
> world, but in my
> > > opinion a small hint showing that  for PC granularity, 
> thinking the
> > > endpoints as PCs is a better modelling.
> > >
> > > 2- Sub-PC granularity
> > > IMHO, it is not very realistic to have a fully-mesh 
> network in sub-PC
> > > granularity, especially when the RKs are symmetric. For SI
> > > granularity this
> > > seems a little bit more manageable (but probbaly still not a
> > > fully-mesh
> > > network), but for CIC ranges only between a few nodes. So, even if
> > > distribution of user parts is desireable, I would think such
> > > a network:
> > >
> > >      1-1-1     1-1-1/2-2-2    2-2-2/1-1-1  2-2-2
> > >    CIC:0-100   CIC:0-100      CIC:0-100    CIC:0-100
> > >        +-----+-----+               +-----+-----+
> > >        |ASPF |IPSPF|               |IPSPF|ASPF |
> > >        |     |     +---------------+     |     |
> > >        +--+--+-----+               +-----+-+---+
> > >           |                                |
> > >           |                                |
> > >           |                                |
> > >           |               +-----------------
> > >           |               |
> > >           |            +--+--+           +-----+          ----
> > >           |            |SGPF |           |SGPF |        //    \\
> > >           +------------+     +-----------+     +-------+ ASPs   |
> > >                        ++--+-+           +-----+      |          |
> > >                         |  |                           |        |
> > >                         |  |                            \\    //
> > >                +--------+  +----+                         ----
> > >                |                |
> > >              +-+---+        +---+-+
> > >              |ASPF |        |ASPF |
> > >              |     |        |     |
> > >              +-----+        +-----+
> > >             3-3-3           3-3-3
> > >            CIC:0-50        CIC:51-100
> > >
> > >
> > >
> > > _______________________________________________
> > > 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: "reshma" <[email-masked]>
Date: Thu, 6 Jun 2002 13:52:04 +0530

Hi Javier,

    Okay i have following questions in SE IPSP approach.

1. Do we need to have RK granularity lower than PC? Why?

2. Should IPSP be able to communicate with SGP/ASP ?

3. How can the present ASP/AS state machine work for IPSP?

4. Do we need traffic mode loadshare in IPSP?Why?

Thanks,
Reshma
----- Original Message -----
From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
To: "'reshma'" <[email-masked]>; "Javier Pastor-Balbas (ECE)"
<[email-masked]>; "'Tolga Asveren'"
<[email-masked]>; <[email-masked]>
Sent: Thursday, June 06, 2002 12:54 PM
Subject: RE: [Sigtran] m3ua:IPSP

> Hi Reshma,
>
> I would participate in discussions focused on solving any problem found in
the current SE IPSP model therefore. I think a text could be a good basis to
find out what is missing and work no that.
>
> But I would not like starting again all the comparison between the two
models and circular discussions without end. Simply they are two different
points to work on.