Subject: RE: [Sigtran] SE-IPSP definition

From: "Ken A Morneault \(kmorneau\)" <[email-masked]>
Date: Wed, 9 Nov 2005 09:41:32 -0500

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

---

From: "Prasad, Shashank S (Shashank)" <[email-masked]>
Date: Thu, 10 Nov 2005 00:21:19 +0530

Brian,

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Brian F. G. Bidulock
Sent: Thursday, November 10, 2005 12:12 AM
To: Holland, Peter Michael (Peter)
Cc: [email-masked]; 'Tolga Asveren'
Subject: Re: [Sigtran] SE-IPSP definition

Holland,,

Holland, Peter Michael (Peter) wrote:
(Wed, 09 Nov 2005 16:29:33)
> Tolga,
> Concerning text clean up I see a couple of references to 
> C-IPSP/D-IPSP that I assume should be removed.

It was agreed at WGLC that the terms C-IPSP and D-IPSP would be removed.
If it is still possible to do so, it is an editorial change.

> I also noticed several English problems with the numbered 
> items at the start of 4.3. I can send updated text if you 
> would like.
> 
> Reading this thread the problem I see with SE procedures was
> identified in a mail where Brian said:
> >If you want both IPSPs to each have an AS an traffic mode, use DE instead
> of SE.
> Thus I understand there are situations where SE mode cannot be
> used. This is not clear in RFC.

No, there are not situations where SE mode cannot be used.  What I was
saying was that if one pedantically requies that both peers have and
exchange a traffic mode (which they don't need in the first place) that
one should use the DE mode.

SE can work quite fine in all situations with one side not having an ASP
traffic mode.  No change is required.

> 
> Concerning the inapplicability of SSNM message in IPSP mode, I definately
> think it would help if this was explicitly stated - this has been a
> subject on significant discussion in some fora.

All SSNM messages are applicable to IPSPs.  No change is required.

[SHASHANK] Are DUNA, DAVA, DAUD also applicable to IPSPs ?

--brian

> Thanks
> Pete

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