Re: 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.

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).

--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/