Subject: RE: [Sigtran] IPSP: SE vs DE

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Mon, 3 Jun 2002 18:08:33 +0200

Hi Tolga, 

IPSP can work in PC granularity and providing a direct communication between ASes. People can also define lower of bigger granularities. The final decission will be the operator's. SI seems to work also well. 

Cheers // Javier.

> -----Original Message-----
> From: Tolga Asveren [mailto:[email-masked]]
> Sent: Monday, June 03, 2002 6:08 PM
> To: [email-masked]
> Subject: RE: [Sigtran] IPSP: SE vs DE
> 
> 
> Javier,
> 
> In my opinion, for granularity at PC, SG-SG is handling 
> direct communication
> in a very clean and easy way. Below PC maybe just SI 
> granularity(?) seems
> usefull to me.
> 
>     Tolga
> 
> > -----Original Message-----
> > From: Javier Pastor-Balbas (ECE)
> > [mailto:[email-masked]]
> > Sent: Monday, June 03, 2002 11:50 AM
> > To: 'Tolga Asveren'; [email-masked]
> > Subject: RE: [Sigtran] IPSP: SE vs DE
> >
> >
> > Hi Tolga,
> >
> > As your IP network is growing it makes sense that two ASes can
> > talk to each other directly. PC granularity can be defined. It
> > depends on the operator if they want to use M3UA with sub-PC
> > granularity or not. We just give them the means they can work with.
> >
> > Cheers // Javier.
> >
> > > -----Original Message-----
> > > From: Tolga Asveren [mailto:[email-masked]]
> > > Sent: Monday, June 03, 2002 5:33 PM
> > > To: [email-masked]
> > > Subject: RE: [Sigtran] IPSP: SE vs DE
> > >
> > >
> > > If I think on real-life cases, an IPSP also does not seem too
> > > usefull to me.
> > > Especially having peers working in sub-PC granularity and 
> which are
> > > symmetric, won't be something very easy to configure and
> > > maintain. For me,
> > > always Figure-1 in SG-SG draft looks very elegant and
> > > realistic. What are
> > > other opinions?
> > >
> > >    Tolga
> > >
> > > > -----Original Message-----
> > > > From: [email-masked]
> > > [mailto:[email-masked]]On Behalf Of
> > > > Brian F. G. Bidulock
> > > > Sent: Monday, June 03, 2002 11:14 AM
> > > > To: Javier Pastor-Balbas (ECE)
> > > > Cc: [email-masked]'
> > > > Subject: Re: [Sigtran] IPSP: SE vs DE
> > > >
> > > >
> > > > Javier,
> > > >
> > > > Your IPSP will not work with an SG and therefore
> > > > makes no sense.
> > > >
> > > > I still propose that IPSP be removed altogether as SG-SG
> > > > communication is an better, easier and obvious replacement.
> > > >
> > > > --brian
> > > >
> > > > Javier Pastor-Balbas (ECE) wrote:                          (Mon,
> > > > 03 Jun 2002 16:58:54)
> > > > > Hi Brian,
> > > > >
> > > > > IPSP will avoid the use of SG and therefore it makes sense.
> > > > >
> > > > > Cheers // Javier.
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > > > > Sent: Monday, June 03, 2002 4:48 PM
> > > > > > To: Javier Pastor-Balbas (ECE)
> > > > > > Cc: [email-masked]'
> > > > > > Subject: Re: [Sigtran] IPSP: SE vs DE
> > > > > >
> > > > > >
> > > > > > Javier,
> > > > > >
> > > > > > As SE was clearly agreed as possible using an SG to 
> transfer and
> > > > > > not requiring any new protocol or state machine 
> description, I
> > > > > > propose that IPSP be removed from the RFC 
> altogether.  I also
> > > > > > propose that the SG-SG be used to properly address 
> peer-to-peer
> > > > > > communication.
> > > > > >
> > > > > > --brian
> > > > > >
> > > > > > Javier Pastor-Balbas (ECE) wrote:
> > > > > > (Mon, 03 Jun 2002 16:24:07)
> > > > > > > Hi guys,
> > > > > > >
> > > > > > > I propose to move forward. Most of the folks that are now
> > > > > > > active seem to prefer the SE. Then, I propose to 
> remove the DE
> > > > > > > exchange from the current RFC and leave only SE. Anyone
> > > > > > > against?
> > > > > > >
> > > > > > >
> > > > > > > Cheers // Javier.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > > 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
> > > >
> > > > --
> > > > 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

---

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Wed, 5 Jun 2002 09:44:08 +0200

Hi Reshma, 

If everything works as the current RFC, what is intended to happen, receiving an ASPUP when the other peer is considered to be in ASP-UP state is not a big problem. Following the RFC, an ASPUP_Ack would be returned by each end. Both ends are allowed to start the communication: easy configuration.

Cheers // Javier.

> From: reshma [mailto:[email-masked]]
> Sent: Wednesday, June 05, 2002 9:37 AM
> To: Javier Pastor-Balbas (ECE); [email-masked]
> Cc: 'Tolga Asveren'; [email-masked]
> Hi Javier,
>     In SE approach both peers can send ASPUP message.What if 
> both sent ASPUP
> at the same time to the peer? Should the peer reject it/accept it?
> 
> Thanks,
> Reshma
> 
> 
> ----- Original Message -----
> From: "Javier Pastor-Balbas (ECE)" 
> <[email-masked]>
> To: <[email-masked]>
> Cc: "'Tolga Asveren'" <[email-masked]>; <[email-masked]>
> Sent: Wednesday, June 05, 2002 12:57 PM
> > Let's be constructive. No more DE IPSP. Don't go backwards to mess
> everything again.
> >
> > See below...  :-/
> >
> > > Sent: Tuesday, June 04, 2002 8:04 PM
> > > Cc: 'Tolga Asveren'; [email-masked]
> > > It never ceases to amaze me how you accuse other solutions
> > > of the failings of your own.  I don't know how many times
> > > you tried to say that SE required twice the RCs as DE, when
> > > it was quite obvious that the reverse was true.
> > >
> >
> > I don't consider IPSP as my solution. You are the only one 
> considering it.
> I'm just trying to finish the work we started some time ago. It is a
> solution that a WG approved independently that you have made 
> up your mind.
> It is in the current RFC and we have to solve the problems it 
> has. Nothing
> more. Not reinventing the wheel...
> >
> >
> > > Now you claim that SG-SG requires twice the state machines,
> > > twice the delay, and twice the cost of IPSP; and, again
> > > the reverse is true:
> > >
> > I never said that SG-SG requires twice the state machines. You are
> inventing here. :-(
> > I said it has more delay and it is more expensive because 
> you need SG in
> the middle. Read what I write and don't put in my mouth words 
> I didn't say.
> :-(
> >
> >
> > > IPSPs need twice the state machines to communicate with the
> >
> > I think you talk about AS here...
> >
> > > SS7 network: one state machine acting in IPSP mode and another
> > > in ASP mode from your last statements to me.  That is twice
> > > the cost.
> > >
> >
> > Explain why it is twice the cost.
> >
> >
> > > IPSPs communicate in a criss-crossed fasion requiring an SGPF
> > > and an ASPF from your own descriptions of the message exchanges.
> > > To communicated with the SS7 network IPSP would neet to separate
> > > ASPF from SGPF requiring twice the state machines and twice the
> > > delay.
> > >
> >
> > Now you are going backwards again trying to mix everything 
> and confusing
> people. You are using your model (unworkable) with a 
> configuration that we
> left away some mails ago.... It is not worth using your 
> criss-crossed model
> for IPSP. So that don't base your opinions on that.
> >
> > But anyway it would help you don't introduce more DE discussions.
> >
> >
> > > It is the nature of the criss-crossed communication of the IPSP
> > > that it requires double state machines and double delay.
> > >
> >
> > No more DE discussions.
> >
> > > SG-SG communication on the other hand is peer to peer.  Only one
> > > state machine is required and there is half the delay beceause
> > > communication is direct.
> >
> > Are you using the same state machine that you use to talk 
> to an AS ??
> Surprise me !!
> > >
> > > If an implementor wants to combine an ASPF into an SGPF to get
> > > an complete IPSP, the SGPF can still communicate directly using
> > > SG-SG.
> > >
> > DE again...  Any argument for SE?  Please move forward... Make this
> discussion more constructive.
> >
> > > It is time that you understood that SG-SG can be viewed as just
> > > IPSP SE with relay capabilities and the criss-cross removed.
> > >
> >
> > It's time that I understand that you want to impose your 
> SG-SG draft not
> reading or caring what other people 
> arguments/opinions/necesities are...
> Very sad.
> >
> > // Javier.
> >
> >
> >
> >
> > > --brian
> > >
> > >
> > > (Tue, 04 Jun 2002 17:12:54)
> > > > Hi Tolga,
> > > >
> > > > See below....
> > > >
> > > > > Sent: Tuesday, June 04, 2002 5:05 PM
> > > > > To: [email-masked]
> > > > > Hi Javier,
> > > > > > Sent: Tuesday, June 04, 2002 10:40 AM
> > > > > > See below...
> > > > > > > Sent: Tuesday, June 04, 2002 4:26 PM
> > > > > > > To: [email-masked]
> > > > > > > For PC granularity:
> > > > > > >  +------+              +------+
> > > > > > >  |U.P./ |              |U.P./ |
> > > > > > >  |NIF   |              |NIF   |
> > > > > > >  +------+              +------+
> > > > > > >  |      |              |      |
> > > > > > >  |SGPF  +--------------+SGPF  |
> > > > > > >  +------+              +------+
> > > > > > >
> > > > > > > There is again only one M3UA entity, no 
> additional nodes. Why
> > > > > > > is this more
> > > > > > > expensive than IPSP?
> > > > > >
> > > > > > For me it is easier the following configuration. 
> Everything is
> > > > > > already define and working. We do you need to create another
> > > > > > different configuration? Just for fun? What are the real
> > > > > > advantages to throw away what is already there to 
> create another
> > > > > > different thing from the scratch?
> > > > > [TOLGA] I don't think everything is already defined and
> > > > > working for SE IPSP
> > > > > case, we should and discuss about the details.. The advantage
> > > > > of using SGPF
> > > > > is that its relationship with ASPF is already defined. To be
> > > > > able to make
> > > > > IPSP communciate with SGP, one has to keep two different
> > > > > state machines.
> > > >
> > > > A different state machine is mantained for each M3UA
> > > connection, so that this is not a big problem. Communication
> > > between AS and SG is already defined. Also communication
> > > between two ASes is almost defined in the current RFC. No new
> > > protocols needed for that.
> > > >
> > > >
> > > > > >
> > > > > >
> > > > > >   +------+              +------+
> > > > > >   |U.P.  |              |U.P.  |
> > > > > >   |      |              |      |
> > > > > >   +------+              +------+
> > > > > >   |      |              |      |
> > > > > >   |IPSP  +--------------+IPSP  |
> > > > > >   +------+              +------+
> > > > > >
> > > > > > This configuration also works for SI, infra-SPC and 
> supra-SPC
> > > > > > granularity. What is the advantage of what you are 
> proposing.?
> > > > > >
> > > > > >
> > > > > > > As I said, it is better to interprete SGPF as 
> IP-STP/IP-SEP.
> > > > > > For example:
> > > > > > >
> > > > > > >  +------+          +------+
> > > > > > >  |ASP1  |          |ASP2  |
> > > > > > >  |      |          |      |
> > > > > > >  +--+---+          +--+---+
> > > > > > >     |                 |
> > > > > > >     |                 |
> > > > > > >     |                 |
> > > > > > >     |     +------+    |
> > > > > > >     |     | SGP1 |    |
> > > > > > >     +-----+      +----+
> > > > > > >           +------+
> > > > > > >
> > > > > > > Also in the above configuration, SGP1 acts as IP-STP.
> > > If there is
> > > > > > > interaction necessary with SS7 domain, of course 
> IP-STP will
> > > > > > > have a MTP3
> > > > > > > interface and otherwise not.
> > > > > >
> > > > > > For the above configuration I'd use the following 
> configuration,
> > > > > > where the direct path is the default communication 
> used between
> > > > > > both ASes. I don't want to have SG's dependencies
> > > > > >
> > > > > >      AS1                AS2
> > > > > >    +------+   IPSP   +------+
> > > > > >    |IPSP1 |==========|IPSP2 |
> > > > > >    |ASP1  |          | ASP2 |
> > > > > >    +--+---+          +--+---+
> > > > > >       |                 |
> > > > > >       |                 |
> > > > > >       |                 |
> > > > > >       |     +------+    |
> > > > > >       |     | SGP1 |    |
> > > > > >       +-----+      +----+
> > > > > >             +------+
> > > > > >
> > > > > > And therefore SGP is not really needed. Although if 
> you keep it
> > > > > > you can get some redundancy paths...
> > > > > [TOLGA] The real important issue is that one needs to put
> > > > > also ASP state
> > > > > machines and logic there. I am not saying this is impossible,
> > > > > just in my
> > > > > opinion not desireable.
> > > >
> > > > Then you prefer to use a SG... Adding more delays and 
> more money...
> > > > Having two state machines is not an issue.
> > > >
> > > > Cheers // Javier.
> > > >
> > > >
> > > >
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > > The need for CIC routers if there is sub-PC granularity:
> > > > > > > There are n nodes. You change the CIC ranges in 
> one of them.
> > > > > > > But for the
> > > > > > > other ones you don't want to change. Or even worse,those
> > > > > > > nodes are belonging
> > > > > > > to different operators. Operator1 does not want 
> to change its
> > > > > > > CIC ranges
> > > > > > > based on decision of Operator2. In such a case, one needs
> > > > > > > concentration
> > > > > > > nodes.
> > > > > > >
> > > > > > How can you deal with CIC granularity with SG-SG ? 
> I thought it
> > > > > > was just valid for PC granularity...
> > > > > [TOLGA] SG-SG has relaying functionality. So, one SG can
> > > > > concentrate traffic
> > > > > on PC granularity and can relay it to another SG. SGPs
> > > and ASPs are
> > > > > communciating can communciate in sub-PC without problem.
> > > > > >
> > > > > > > I am aware of 3G but what I told was based on what I see
> > > > > > > currently, how
> > > > > > > operators want to deploy initially SIGTRAN.
> > > > > >
> > > > > > Tolga, both main operators and green fielders, are
> > > represented in
> > > > > > 3G standardization fora...
> > > > > >
> > > > > > Cheers // Javier.
> > > > > >
> > > > > >
> > > > > > >
> > > > > > >    Tolga
> > > > > > >
> > > > > > > > Sent: Tuesday, June 04, 2002 9:52 AM
> > > > > > > > See my comments below...
> > > > > > > > > Sent: Tuesday, June 04, 2002 3:16 PM
> > > > > > > > > To: [email-masked]
> > > > > > > > > Hi Javier,
> > > > > > > > > I agree that they are not exactly compareable but
> > > if I have
> > > > > > > > > to choose one,
> > > > > > > > > without hesitation, I would choose SG-SG. Some
> > > more comments
> > > > > > > > > to the items
> > > > > > > > > you added to the list are below.
> > > > > > > > >
> > > > > > > > >   Tolga
> > > > > > > > >
> > > > > > > > > > Sent: Tuesday, June 04, 2002 2:40 AM
> > > > > > > > > > These two methods are not comparable. They simply
> > > > > do different
> > > > > > > > > > things. But for sure that if I have to choose one,
> > > > > I'll go for
> > > > > > > > > > the current RFC with the IPSP. The reasons 
> are in the
> > > > > > > list below.
> > > > > > > > > >
> > > > > > > > > > Let's complete the table... (see below)
> > > > > > > > > >
> > > > > > > > > > > Sent: Monday, June 03, 2002 8:03 PM
> > > > > > > > > > > To: [email-masked]
> > > > > > > > > > > My opinion is:
> > > > > > > > > > > First of all thinking that AS talks to SG is
> > > equivalent to
> > > > > > > > > > > say that a web
> > > > > > > > > > > browser talks to a router, instead of a web
> > > server. It is
> > > > > > > > > > > ASP-M3UA, which
> > > > > > > > > > > talks to SGP-M3UA. I think saying like this
> > > fits more to a
> > > > > > > > > > > layered approach,
> > > > > > > > > > > otherwise for any communication at any level we
> > > > > can say AS is
> > > > > > > > > > > talking to SG.
> > > > > > > > > > > In the context of M3UA stack, ASP corresponds to
> > > > > a physical
> > > > > > > > > > > endpoint whereas
> > > > > > > > > > > AS is only a traffic range. So, for example,
> > > ASPUP is not
> > > > > > > > > > > sent from AS to SG
> > > > > > > > > > > but from ASP-M3UA to SGP-M3UA (for example
> > > > > similarly if INAP
> > > > > > > > > > > logic in a SSP
> > > > > > > > > > > sends an INAP message to a SCP, the corresponding
> > > > > MSUs will
> > > > > > > > > > > possibly pass
> > > > > > > > > > > through some STPs. Does this mean that SSP
> > > talks to those
> > > > > > > > > > > STPs?). An AS is a
> > > > > > > > > > > logical HLR, SCP etc... so its peer will 
> be again a
> > > > > > > > > > > corresponding entity, in
> > > > > > > > > > > IP domain or in SS7 domain.
> > > > > > > > > > >
> > > > > > > > > > > Advantages of using SG-SG communication:
> > > > > > > > > > > ========================================
> > > > > > > > > > > 1- Has relaying functionality
> > > > > > > > > > > 2- Allows smooth interaction with SS7 network
> > > > > > > > > > > 3- For PC granularity, user application might run
> > > > > directly on
> > > > > > > > > > > top of SGPF
> > > > > > > > > > > (of course with NIF)
> > > > > > > > > > > 4- Does not require separate state machines
> > > and separate
> > > > > > > > > > > logics for peers in
> > > > > > > > > > > SS7 domain and in IP domain
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > Advantages of SE IPSP
> > > > > > > > > > > ======================
> > > > > > > > > > >
> > > > > > > > > > > 1- Will provide direct symmetric
> > > communication for sub-PC
> > > > > > > > > granularity.
> > > > > > > > > >
> > > > > > > > > > Let me add a few more:
> > > > > > > > > >
> > > > > > > > > > 2- Will provide direct symmetric 
> communication for PC
> > > > > > > granularity
> > > > > > > > > [TOLGA] SG-SG provides this
> > > > > > > >
> > > > > > > > But you need SG:
> > > > > > > > - More expensive
> > > > > > > > - Processing time increased
> > > > > > > >
> > > > > > > > > > 3- Will provide direct symmetric communication
> > > for supra-PC
> > > > > > > > > granularity
> > > > > > > > > > 4- No more messages needed
> > > > > > > > > [TOLGA] For intra-IP case, also for SG-SG no more
> > > > > messages needed.
> > > > > > > >
> > > > > > > > But you need SG:
> > > > > > > > - More expensive
> > > > > > > > - Processing time increased
> > > > > > > >
> > > > > > > > > > 5- No more working items needed
> > > > > > > > > [TOLGA] We still need to discuss about SE 
> IPSP. Till now,
> > > > > > > all of the
> > > > > > > > > discussion was focused on DE approach.
> > > > > > > > > > 6- No more standard process needed
> > > > > > > > > [TOLGA] ?
> > > > > > > >
> > > > > > > > See RFC 2026
> > > > > > > >
> > > > > > > > > > 7- Use of SG not needed to communicate two SS7
> > > > > applications in
> > > > > > > > > > the IP domain
> > > > > > > > > [TOLGA] For PC granularity also not needed for
> > > SG-SG case. Or
> > > > > > > > > better said,
> > > > > > > > > one just need SG (which I think now we are
> > > interpreting more
> > > > > > > > > as IP-STP)
> > > > > > > >
> > > > > > > > If you use SG:
> > > > > > > > - More expensive
> > > > > > > > - Processing time increased
> > > > > > > > You don't need to introduce this delay. Using IPSP
> > > communication
> > > > > > > > between ASes, is direct and it will avoid
> > > unnecessary delays and
> > > > > > > > intermediate nodes...
> > > > > > > >
> > > > > > > > > > 8- Relaying function not needed in IP domain: we
> > > > > have routers
> > > > > > > > > [TOLGA] It is needed for a reasonable 
> configuration if one
> > > > > > > > > goes to sub-PC
> > > > > > > > > granularity. Do we have routers working based on
> > > CIC ranges?
> > > > > > > >
> > > > > > > > What reasonable configuration needs it?
> > > > > > > >
> > > > > > > > > What about for
> > > > > > > > > multiple operators case? And if sub-PC 
> grabularity is not
> > > > > > > > > needed, then IPSP
> > > > > > > > > also does not have any meaning. Because for 
> PC granularity
> > > > > > > > > SG-SG provides
> > > > > > > > > everything IPSP can provide and more.
> > > > > > > >
> > > > > > > > Using SG-SG you need more nodes
> > > > > > > > - More expensive
> > > > > > > > - Processing time increased
> > > > > > > >
> > > > > > > > Less quality but more expensive
> > > > > > > >
> > > > > > > > > > 9- Allow an step forward moving from MTP2 to IP
> > > protocol to
> > > > > > > > > > transport SS7 signaling
> > > > > > > > > [TOLGA] That is in fact what SG-SG does
> > > > > > > >
> > > > > > > > You don't need to introduce more nodes in addition
> > > to the SS7
> > > > > > > > application talking one to each other using M3UA.
> > > > > > > >
> > > > > > > > > > 10- The future network without SS7 domain
> > > > > > > > > [TOLGA] SG-SG also provides this and additionaly also
> > > > > > > > > provides easy SS7
> > > > > > > > > communciation for the transition period, which
> > > most probably
> > > > > > > > > won't be very
> > > > > > > > > short. In fact, although I don't like it, 
> what I see is,
> > > > > > > > > people want to use
> > > > > > > > > SIGTRAN
> > > > > > > > > a) either to get a remote SS7 interface for 
> their IP-SCPs,
> > > > > > > > > Softswitches
> > > > > > > > > etc...
> > > > > > > > > b) or to backhaul between two SS7 nodes over IP
> > > > > > > >
> > > > > > > > Take a look to standardization fora for the third
> > > generation.
> > > > > > > >
> > > > > > > > > > 11- The first network small operators could 
> make (SS7 is
> > > > > > > > > more expensive)
> > > > > > > > > [TOLGA] Why do you think for SG-SG SS7 is
> > > necessary? We have
> > > > > > > > > said several
> > > > > > > > > times, SG should be interpreted as IP-STP. SS7
> > > interface is
> > > > > > > > > only necessary,
> > > > > > > > > if one want to communicate with nodes in SS7 domain.
> > > > > > > >
> > > > > > > > Read the definition for SG. IP-STP is not an SG in
> > > the same way
> > > > > > > > that SG is not necessary an SS7 STP. IP-STPs are
> > > just IP-STPs.
> > > > > > > > Another different thing is that you want to 
> include IP-STP
> > > > > > > > functionality inside the same node as the SG. SG is not
> > > > > necessary
> > > > > > > > an SS7-STP either. Do I need to substitute IP-STP
> > > in every place
> > > > > > > > you put SG?  :-/
> > > > > > > >
> > > > > > > > Direct communication is always cheaper and faster
> > > when possible.
> > > > > > > >
> > > > > > > > Cheers // Javier.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Cheers // Javier.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > Let's try to complete those two lists. What
> > > else could be
> > > > > > > > > > > added to them?
> > > > > > > > > > >
> > > > > > > > > > >  Tolga
> > > > > > > > > > >
> > > > > > > > > > > > Javier Pastor-Balbas (ECE)
> > > > > > > > > > > > Sent: Monday, June 03, 2002 11:52 AM
> > > > > > > > > > > > To: [email-masked]'; Javier
> > > Pastor-Balbas (ECE)
> > > > > > > > > > > > Cc: [email-masked]'
> > > > > > > > > > > > Brian,
> > > > > > > > > > > > Wrong concept. My AS can talk with a SG and
> > > ALSO with
> > > > > > > > > another AS.
> > > > > > > > > > > > The communication will be faster since the
> > > > > > > processing is half or
> > > > > > > > > > > > even less.
> > > > > > > > > > > >
> > > > > > > > > > > > What is the advantage of AS-SG-(SG)-AS regarding
> > > > > > > AS-AS ?? Please
> > > > > > > > > > > > list them.
> > > > > > > > > > > >
> > > > > > > > > > > > Cheers // Javier.
> > > > > > > > > > > >
> > > > > > > > > > > > > Sent: Monday, June 03, 2002 5:14 PM
> > > > > > > > > > > > > (Mon, 03 Jun 2002 16:58:54)
> > > > > > > > > > > > > > Hi Brian,
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > IPSP will avoid the use of SG and 
> therefore it
> > > > > > > makes sense.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Cheers // Javier.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > I propose to move forward. Most 
> of the folks
> > > > > > > > > that are now

---

From: "Bep Verberk" <[email-masked]>
Date: Wed, 5 Jun 2002 11:23:24 -0400

I agree with Javier.

> Sent: Monday, June 03, 2002 11:33 AM
> To: [email-masked]
> Especially having peers working in sub-PC granularity and which are