Subject: RE: [Sigtran] SE-IPSP definition

From: "Prasad, Shashank S (Shashank)" <[email-masked]>
Date: Wed, 9 Nov 2005 20:37:43 +0530

Ken,
There is a serious issue in understanding the differences in IPSP and what
it means.
I am sure that u would have gone thru the mails where serious issues of IPSP
understanding is evident.

I feel that it should be resolved in the next draft before anything else.
An extention draft must include IPSP considerations.

shashank

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Ken A Morneault (kmorneau)
Sent: Wednesday, November 09, 2005 8:12 PM
To: Tolga Asveren; [email-masked]
Subject: RE: [Sigtran] SE-IPSP definition

Hi Tolga,

Sorry for the delayed response.  I took some time off.

Regarding the IPSP text, that is an area that Javier
updated.  At this point, I'm not sure if we will be
able to change the text.  The document is supposed to
be heading to the Editor's queue to be published. 

Regards,

Ken

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Tolga Asveren
Sent: Tuesday, November 08, 2005 9:13 AM
To: [email-masked]
Subject: RE: [Sigtran] SE-IPSP definition

A few typo scorrected below.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Tolga Asveren
> Sent: Tuesday, November 08, 2005 8:35 AM
> To: [email-masked]
> 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-masked] [mailto:[email-masked]]On
> > Behalf Of Brian F. G. Bidulock
> > Sent: Monday, November 07, 2005 7:52 PM
> > To: Tolga Asveren
> > Cc: [email-masked]
> > 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-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

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Wed, 9 Nov 2005 09:56:29 -0500

Shashank,

I don't think there is as significant issue as you mention. As far as I can
see, some text cleanup is the only thing we need-to get rid of C/SE-IPSP ,
S/SE-IPSP distinction-.

The original problem you mentioned -having traffic mode bothways- is
something useful IMO as well. That can be added to the document but it does
not change anything architecturally in terms of IPSP as defined in the
document.

What other issues do you consider as problems associated with IPSP?

   Tolga

> From: Prasad, Shashank S (Shashank) [mailto:[email-masked]]
> Sent: Wednesday, November 09, 2005 10:08 AM
> To: 'Ken A Morneault (kmorneau)'; Tolga Asveren; [email-masked]