RE: M3UA: 1IPSP - multiple IPSPs traffic flow

Brian,

> -----Original Message-----
> From: [email protected] [mailto:[email protected]]On
> Behalf Of Brian F. G. Bidulock
> Sent: Monday, November 07, 2005 1:56 PM
> To: Tolga Asveren
> Cc: [email protected]
> Subject: Re: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow
>
>
> Tolga,
>
> The SE model of RFC 3332 is SGPF/ASPF.
>
> Look back at "M3UA-v02 Last Call Comment: ASP States and SE or DE IPSP".
> You did not receive any support for your IPSPF model, even for rfc3332bis.
[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?

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.

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 .
>
> --brian
>
>
> Tolga Asveren wrote:                           (Mon, 07 Nov 2005 09:01:40)
> > Brian,
> >
> > > -----Original Message-----
> > > From: Brian F. G. Bidulock [mailto:[email protected]]
> > > Sent: Monday, November 07, 2005 8:22 AM
> > > To: Tolga Asveren
> > > Cc: [email protected]
> > > Subject: Re: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow
> > >
> > >
> > > Tolga,
> > >
> > > The problem is that an SGP (intentionally) neither has an AS, nor does
> > > it have a traffic mode.  This is the same for the SGPF in the
> SE model.
> > > If you want to change the model, call it something different:
> how about
> > > SG-SG? ;)
> > [TOLGA]I belive the main reason why we have different opinions
> about this
> > issue is because you think the logic in SE-IPSP as a SGPF
> whereas I would
> > call it IPSPF -OTOH I totally would agree with you that it
> makes sense to
> > speak of SGPF and ASPF in IPSP for DE-model-. It is true that
> the messages
> > exchanged to bring the entities up and ready for message
> exchange are the
> > same for SE-IPSP and SGP/ASP cases -mainly for the sake of
> reusing existing
> > message codes- but there is a fundamental difference between two models:
> > with SE-IPSP model, we have two different application logic processing
> > entities on each end, which may have different traffic mode
> attributes. It
> > sounds reasonable to me to have a mechanism to set both of
> those values with
> > Traffic Mode parameter.
> >
> > For SG-SG, yes it could be nice indeed ;-)
> > >
> > > --brian
> > >
> > > Tolga Asveren wrote:                       (Mon, 07 Nov 2005 07:54:58)
> > >
> > > --X--snip--X--
> > >
> > > > [TOLGA]I agree with Shashanks point here. IMO, we have an
> unnecessary
> > > > costraint in -SE-IPSP mode. I don't see any problem why using
> > > Traffic Mode
> > > > in both directions should create a problem. Forcing people to
> > > use DE-IPSP
> > > > mode -which is both optional and IMO more importantt han that
> > > not a really
> > > > peer-to-peer model- to set traffic modes in both directions
> is anot a
> > > > solution.
> > >
> > > --X--snip--X--
> > >
> > > --
> > > Brian F. G. Bidulock
> > > [email protected]
> > > http://www.openss7.org/
> > >
> >
> >
> >
> > _______________________________________________
> > Sigtran mailing list
> > [email protected]
> > https://www1.ietf.org/mailman/listinfo/sigtran
>
> --
> Brian F. G. Bidulock
> [email protected]
> http://www.openss7.org/
>
> _______________________________________________
> Sigtran mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/sigtran
>