RE: SE-IPSP definition

A few typo scorrected below.

> -----Original Message-----
> From: [email protected] [mailto:[email protected]]On
> Behalf Of Tolga Asveren
> Sent: Tuesday, November 08, 2005 8:35 AM
> To: [email protected]
> Subject: [Sigtran] SE-IPSP definition
>
>
> Brian,
>
> -changed the subject of the thread-
>
> Ken, I re-checked and current bis document seems to be updated partially
> (4.3 has the definition I copy/pasted below -which is fine-, OTOH still
> there is text mentioning about C-IPSP, D-IPSP for SE-model. The idea
> probably was to assign roles to IPSPS per "transaction", i.e. a
> message pair
> like ASPAC/ASPAC-ACK, ASPIA/ASPIA-ACK, but I believe the concept
> of "client"
> and "server" can be misleading because it can be considered as one IPSP
> always playing client or server role while communicating with a
> certain peer
> IPSP. IMHO, the terms C-IPSP/D-IPSP confuse rather than clarify.
>
> Brian, more comments below.
>
>    Tolga
>
> > -----Original Message-----
> > From: [email protected] [mailto:[email protected]]On
> > Behalf Of Brian F. G. Bidulock
> > Sent: Monday, November 07, 2005 7:52 PM
> > To: Tolga Asveren
> > Cc: [email protected]
> > Subject: Re: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow
> >
> >
> > Tolga,
> >
> > Tolga Asveren wrote:
> >                    (Mon, 07 Nov 2005 14:36:07)
> >
> > --X--snip--X--
> >
> > > [TOLGA]If you look to " M3UAbis - consensus on comment
> resolution - Part
> > > 1&2" thread -which has happened later than the thread you
> > mentioned ;-) -,
> > > you will see that everybody involved in the discussion
> > "Valerie, you, myself
> > > and Javier" agreed to return to the original SE-IPSP model. The
> > conclusion
> > > was to use the text proposed by Valerie. It seems the bis
> > document is not
> > > updated accordingly. Ken, was there a technical objection for that
> > > change -actually I would call it reverting back to the original
> > model- or is
> > > this just an oversight?
> >
> > Really?  Did you mean in "M3UAbis - consensus on comment
> > resolution" 23 Aug 2004
> > where Valerie says:
> >
> >  IPSP-SE behaviour:
> >  The IPSP acting as the SGP must sends ASPAC-ack only when its
> > side of the RK is
> >  ready.  The IPSP acting as the ASP is responsible to retry the
> > ASPAC until the
> >  remote peer is ready.
> >  When the IPSP acting as the SGP wants to stop application
> > traffic from its side,
> >  it must send ASPIA-ack.
> [TOLGA] No, what I mean is  the message on 08/30/2004 "M3UAbis - consensus
> on comment resoluti on-Part 1&2"
>
> 1- IPSP Single Exchange (SE) model. Only a single exchange of ASPTM
>       or ASPSM messages is needed to change the IPSP state. This means
>       that a set of request from one end and acknowledge from the other
>       will be enough. The RK must define both sides of the traffic flow.
>       Each exchange of ASPTM or ASPSM messages can be initiated by either
>       IPSP. For this exchange, the initiating IPSP follows the procedures
>       described in section 4.3.1.
>
> The above is the original concept we defined for SE-IPSP mode.
> There are no
> predefined client/server relationship, a pure peer-to-peer relationship.
> >
> > Or did you mean where we agreed to back out of the v03 changes
> > (which is what
> > I think you are referring to with the IPSPF) and go back to the
> > v02 description
> > (which is the same as RFC 3332 and the SGPF/ASPF approach).
> [TOLGA]No, what I mean as "IPSPF approach is v02 definition. As
> long as the
> problem is how you and I name it, there is no problem from specification
> point of view but I would call it IPSPF because it has a different machine

^^^^^^^^^
                                                                  state
machine
> than SGPF and ASPF and does not send/receive messages. I believe
                                               ^^^^^^^^^
                                         certain messages, e.g. SSNM
> you use the
> term SGPF in the context of a "transaction" not inthe context of
> the overall
> realtionship between two peer IPSPs.
> >
> > --brian
> >
> > >
> > > Considering the way it is supposed to work, i.e. according to
> > the text we
> > > had concensus on, we can't speak of exact SGPF semantics for
> > SE-IPSP even
> > > from basic message exchange point of view, e.g. SGPF does not
> > send ASPAC,
> > > can't receive ASPAC-ACK, sends SSNM etc...With SE-IPSP both
> > sides can send
> > > ASPAC/ASPAC-ACK and they don't send SSNM and they have a peer-to-peer
> > > relationship, not a client/server relationship.
> >
> > See Valerie's description above.  As I have mantained, it is
> > clear that one IPSP
> > acts in an SGP role and the other in an ASP role.
> >
> > >
> > > Regarding the issue we are discussing in this thread -being
> > able to support
> > > traffic mode in both directions-I think it is a nice thing to
> > have, because
> > > we have application logic at both sides, which may want to
> use different
> > > traffic .
> >
> > Again, the IPSP acting as an SGP in SE mode is not required to
> > have a traffic
> > mode.
> >
> > In the normal ASP/SGP exchange, the SGP does not have a traffic
> > mode to place in
> > the ASPAC Ack.  Any traffic distribution towards the SGP is an
> > SG-wide attribute
> > and does not differ from AS to AS, nor ASP to ASP.
> >
> > --brian
> >
> > --
> > Brian F. G. Bidulock
> > [email protected]
> > http://www.openss7.org/
> >
> > _______________________________________________
> > Sigtran mailing list
> > [email protected]
> > https://www1.ietf.org/mailman/listinfo/sigtran
> >
>
>
>
> _______________________________________________
> Sigtran mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/sigtran
>