RE: SE-IPSP definition

Pete,

> -----Original Message-----
> From: Holland, Peter Michael (Peter) [mailto:[email protected]]
> Sent: Wednesday, November 09, 2005 11:30 AM
> To: 'Tolga Asveren'; [email protected]
> Subject: RE: [Sigtran] 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.
[TOLGA]Ken/Javier are the authors, i.e. the text is not under my control.
OTOH based on Ken's last message, I have the impression that we can't have
non-editorial changes anymore(?) Otherwise I would like to see C-IPSP/D-IPSP
to be cleaned up as well.
>
> 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.
[TOLGA]No, this is not true, one can use SE-IPSP for any scenario. IMO, that
traffic mode can't be specified bothways is something we need to add to the
specification.
>
> 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.
[TOLGA]Ken, is it possible to have the following modification:
In 3.1.2 Message Classes and Types:
  SS7 Signalling Network Management (SSNM) Messages (See Section
      3.4)(Note: SSNM is not used for IPSP communication)

I believe the above change could be considered as "editorial". ;-)

It could be better to a a few sentectes why they are not used and how
availability etc.. is to be handled for IPSP case but I don't know whether
we are already too late for that. If not, I can provide text.
>
> 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
> >
>