Subject: RE: [Sigtran] IPSP vs AS (was RE: sg-sg communication)

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

Hi Brian, 

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Monday, June 03, 2002 3:46 PM
> To: Javier Pastor-Balbas (ECE)
> Cc: Tolga Asveren; [email-masked]
> Subject: Re: [Sigtran] IPSP vs AS (was RE: sg-sg communication)
> 
> 
> Javier,
> 
> Javier Pastor-Balbas (ECE) wrote:                          
> (Mon, 03 Jun 2002 14:45:13)
> > Hi Brian, 
> > 
> > Please, see below...
> > 
> > > -----Original Message-----
> > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > Sent: Monday, June 03, 2002 11:26 AM
> > > To: Tolga Asveren
> > > Cc: [email-masked]
> > > Subject: Re: [Sigtran] IPSP vs AS (was RE: sg-sg communication)
> > > 
> > > 
> > > Tolga,
> > > 
> > > Yes, the criss-cross is clear in the data flow described:
> > > 
> > > > - Send data msg to the other IPSP in the way an SGP sends a
> > > > message to an ASP
> > > 
> > >    _________                 _________
> > >   | _______ |               | _______ |
> > >   ||       || DATA     DATA ||       ||
> > >   || ASPF  ||<----\   /---->||  ASPF ||
> > >   ||_______||      \ /      ||_______||
> > >   | _______ |       X       | _______ |
> > >   ||       ||      / \      ||       ||
> > >   || SGPF  |+-----/   \-----+|  SGPF ||
> > >   ||_______||               ||_______||
> > >   |_________|               |_________|
> > >      IPSP                       IPSP
> > > 
> > 
> > Brian , this is the modeling you have created for that. I don't
> > think this is a good option taking into account the problems it
> > creates. Even you showed those problems when trying to apply this
> > model to the IPSP draft.  Therefore I would say, this model is NOT
> > valid. Use instead the IPSP model as a whole and combine it with
> > the ASP to get the AS-SG scenario working at the same time.
> 
> This is a diagram of exactly what you said in your statement:
> 

If you go the sphinx example, you'll see that your deduction is not that logical... 

Also take into acount that we are not modeling node architectures but making protocols... Node architecture is implementation dependent.

> > > > - Send data msg to the other IPSP in the way an SGP sends a
> > > > message to an ASP
> 
> Nothing more, nothing less.  If IPSP is something different please
> describe it in a coherent fashion.
> 
> As you and other have had over 6 months to do so, I don't think it
> is possible.

What is the point you miss in the definition? I think that the IPSP draft is clear about the basis, although I know that some points are still to include. If you understand what is an ASP, IPSP is almost the same concept of functionality.

Cheers // Javier. 

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

_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 3 Jun 2002 09:42:32 -0500

Javier,

Javier Pastor-Balbas (ECE) wrote:                          (Mon, 03 Jun 2002 16:17:41)
> If you go the sphinx example, you'll see that your deduction is not

The diagram is not a deduction: it is merely a representation of your

> > > > > - Send data msg to the other IPSP in the way an SGP sends a

If this is not what you meant, what did you mean?

> 
> Also take into acount that we are not modeling node architectures but making
> protocols... Node architecture is implementation dependent.

I disagree.  We model node architectures from a functional view and
even provide examples of realizations in the RFCs.  A state machine is
a specification of a functional architecture.  Don't be ridiculous: an
ASP, SGP, even an IPSP is a component in a function architecture.

I'm sorry but you will have to specify how you expect the thing to work
and interact with other devices.

> What is the point you miss in the definition? I think that the IPSP draft is
> clear about the basis, although I know that some points are still to
> include. If you understand what is an ASP, IPSP is almost the same concept
> of functionality.

Please address the comments on the draft and provide description of how
you expect the IPSP to operate.  I suggest that rather than collecting
the vague descriptions from the inadequate text in the RFC which says that
an IPSP "acts like an SGP" here and "acts like an ASP" there, that you
actually describe the messages used, the state machines and the procedures
used between IPSP and any other component (ASP or SGP).  Painting a
description with the broad brush of "acts like an ASP and an SGP but isn't"
is no basis for interoperability.

--brian

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