RE: SE-IPSP definition

Tolga,
Concerning text clean up I see a couple of references to 
C-IPSP/D-IPSP that I assume should be removed.
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.

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.

Thanks
Pete

> -----Original Message-----
> From: [email protected] [mailto:[email protected]]On
> Behalf Of Tolga Asveren
> Sent: 09 November 2005 14:56
> To: [email protected]
> Subject: RE: [Sigtran] SE-IPSP definition
> 
> 
> 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
> 
> > -----Original Message-----
> > From: Prasad, Shashank S (Shashank) [mailto:[email protected]]
> > Sent: Wednesday, November 09, 2005 10:08 AM
> > To: 'Ken A Morneault (kmorneau)'; Tolga Asveren; [email protected]
> > Subject: RE: [Sigtran] SE-IPSP definition
> >
> >
> > 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 protected] [mailto:[email protected]]On
> > Behalf Of Ken A Morneault (kmorneau)
> > Sent: Wednesday, November 09, 2005 8:12 PM
> > To: Tolga Asveren; [email protected]
> > 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 protected] [mailto:[email protected]] On
> > Behalf Of Tolga Asveren
> > Sent: Tuesday, November 08, 2005 9:13 AM
> > To: [email protected]
> > Subject: RE: [Sigtran] 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
> > >
> >
> >
> >
> > _______________________________________________
> > Sigtran mailing list
> > [email protected]
> > https://www1.ietf.org/mailman/listinfo/sigtran
> >
> > _______________________________________________
> > Sigtran mailing list
> > [email protected]
> > https://www1.ietf.org/mailman/listinfo/sigtran
> >
> 
> 
> 
> _______________________________________________
> Sigtran mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/sigtran
>