Re: SE-IPSP definition

Tolga,

Tolga Asveren wrote:                                                                 (Thu, 10 Nov 2005 09:43:23)
> Brian,
> 
> > -----Original Message-----
> > From: Brian F. G. Bidulock [mailto:[email protected]]
> > Sent: Thursday, November 10, 2005 9:34 AM
> > To: Tolga Asveren
> > Cc: [email protected]
> > Subject: Re: [Sigtran] SE-IPSP definition
> >
> >
> > Tolga,
> >
> > Tolga Asveren wrote:
> >                    (Thu, 10 Nov 2005 08:46:34)
> > > >
> > > > This message exchange is not required to be supported.
> > > [TOLGA]Sorry but you are totally wrong. This is very well supported by
> > > SE-IPSP state machine.
> >
> > It is not required by it.
> [TOLGA]Sorry to break my promise of not replying for this subtopic, but it
> *is* required by it. You can't strip certain pieces of a state machine and
> claim that you support it because certain pieces are not required. The state
> machine allows it, so it is requried if you want to claim that your product
> is fully complaint with it.

Huh? Compliance?  Where does it say that I must follow the state machine
illustrated in the RFC?  Also understand that the state machine is only
maintained at an SGP (or an IPSP that is acting like an SGP).  Also, the
transitions in brackets [] are not for SE-IPSP, only for DE-IPSP with
optional single-ended exchange, whatever that is.

> >
> > Although we permitted either SE-IPSP to initiate the exchange, there is
> > no requirement to support switching of roles once an AS has been
> > activated.
> [TOLGA]Take a look to the state machine, you re totally wrong. There are no
> SGP/ASP roles assigned to IPSPs for the whole message exchange, that is the
> reason why there an IPSP state machine.

The state machine is only defined for an SGP to track the state of a remote AS
and MAY be used by an IPSP to track the state of an AS at a remote IPSP.  I
repeat MAY.  This is not a requirement.


> > Permitting switching of roles in the fashion that you originally indicated
> > is problematic as follows:
> >
> >     SE-IPSP1                    SE-IPSP2
> >         |                          |
> >         |-------ASPAC------------->|
> >         |                          |
> >         |<-------ASPIA-------------|
> >         |                          |
> >         |-------ASPIA------------->|
> >         |                          |
> >         |<-------ASPAC-------------|
> >
> > 	   ....  What now?  Is it active?  Inactive?
> >
> > This is why, although either side may initiate the exchange, it
> > should stick
> > with one role.
> [TOLGA]Two points:
> a)If there are open points -and I would think there may be some- in the IPSP
> state machine, they can be fixed, this does not mean changing the whole
> architecture.
> b)For your example:
> I assume initially AS in INACTIVE.
> Because ASPAC from IPSP1 is not acknowledged with ASPAC-ACK AS states
> INACTIVE.
> With ASPIA from IPSPS2 AS state is INACTIVE
> With ASPIA from IPSP1 AS state is INACTIVE
> With ASPAC from IPSP2 AS is still INACTIVE. If IPSP1 replies with ASPAC-ACK,
> AS will become ACTIVE.
> 
> For the above, we may need to clarify things in the IPSP state
> machine -maybe introducing transitionary states-, but as said above this is
> nowhere near to be a showstopper and does not require an architectural
> change.

We intentionally did not make changes over ASP/SGP communication.

> 
> >
> > > >
> > > > The following two other possibilities are just as valid:
> > > >
> > > >    SE-IPSP1                    SE-IPSP2
> > > >        |                          |
> > > >        |-------ASPAC------------->|
> > > >        |                          |
> > > >        |<-----ASPAC-ACK-----------|
> > > >        |                          |
> > > >        |    AS is active at both  |
> > > >        |        sides             |
> > > >        |                          |
> > > >        |<-------ASPIA-------------|
> > > >        |                          |
> > > >        |-ERR[Unexpected Message]->|
> > > >        |                          |
> > > [TOLGA] This is supported from M3UA point of view but means that your
> > > SE-IPSP1 is either not an SE-IPSP or a broken one, because it does not
> > > support IPSP state machine as defined by the specifications.
> >
> > If the IPSP is by definition just an ASP, then the exchange is perfectly
> > valid.  The IPSP actually has to act like an SGP to to respond to such
> > messages.
> [TOLGA]If IPSP were nothing else than ASP in terms of M3UA processing, we
> wouldn't mention anything about it except the definition. The similarity
> between IPSP and ASP is that they both host application logic, that is it.

Neither require application logic to be present.

> >From M3UA state machine processing point of view, they are different
> entities.

For SE-IPSP the same state machine as that for the SGP is used.  The ASP
has no state machine.

> >
> > Also, to avoid the "glare" not handled by the RFC state machines, this is
> > a way to tell the other side not to change roles, or that its role is
> > unexpected.
> [TOLGA]Now, you try to change the SE-IPSP model in the specification? ;-) To
> support the model you want, you don't need to define anything new, just put
> ASPF and SGPF together and there you are. If you don't want to use IPSP that
> is fine.

No.  It has always been this way.

--brian


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