Subject: RE: [Sigtran] M3UA IG v04

From: "Zannin, Francois" <[email-masked]>
Date: Thu, 10 Jul 2003 22:22:57 +0200

OK, now, is the DUPU received on a SG or an IPSP considered as a protocol error?
This has to be clearly stated in the RFC (or IG)
Same remark for the SCON received from an IPSP, is it possible to receive a SCON
or must the IPSP use the SCTP congestion to handle the congestion on a remote IPSP.

Francois.

> -----Original Message-----
> From: Tolga Asveren [mailto:[email-masked]]
> Sent: Thursday, July 10, 2003 10:13 PM
> To: [email-masked]
> Subject: RE: [Sigtran] M3UA IG v04
> 
> 
> Francois,
> 
> IMO, for the scenario you describe, sending ASPIA is
> the correct behaviour. Yes, you won't be able to use
> healthy user parts in such a case, but if you have
> that level of granularity, I would think, RKs should
> be defined accordingly(for example for your example
> PC/SI RKs)
> The same applies to ASP/SGP case. There is no DUPU
> from ASP to SGP direction.
> So, IMO, DUPU for IPSP case is not necessary.
> 
>      Tolga
> --- "Zannin, Francois" <[email-masked]> wrote:
> > tolga,
> > 
> > see inline,
> > 
> > Regards,
> > 
> > Francois.
> > 
> > > -----Original Message-----
> > > From: Tolga Asveren
> > [mailto:[email-masked]]
> > > Sent: Thursday, July 10, 2003 9:47 PM
> > > To: [email-masked]
> > > Subject: Re: [Sigtran] M3UA IG v04
> > > 
> > > 
> > > Brian,
> > > [..snip..]
> > > > > [TOLGA] Yes, SGPs send DUPU to ASPs but to my
> > > > > understanding, Francois's case would
> > correspond
> > > > > sending DUPU from ASP to SGP.
> > > > > As I said, my interpretation of DE IPSP in the
> > IG
> > > > is a
> > > > > combined SGP/ASP. On ASP part of IPSP, the
> > user
> > > > part
> > > > > goes down, then I would expect inactivating
> > the
> > > > > corresponding AS.
> > > > 
> > > > Yes, that's what we understood and agreed,
> > however,
> > > > that is
> > > > not what is presented in the IG: Read the IG
> > again:
> > > > New text in section 3.11.2:
> > > > 
> > > >    In section 4.3.1: ASP/IPSP States, only the
> > > > SGP-ASP and the IPSP SE
> > > >    scenarios are described. For the IPSP DE
> > model,
> > > > both IPSPs MUST
> > > >    follow the SGP side of the SGP-ASP
> > procedures.
> > > > 
> > > > That looks pretty plain to me.  According to the
> > IG,
> > > > DE IPSPs can
> > > > send DUPU (they are actually required above to
> > do so
> > > > when the SGP
> > > > procedure dictates).
> > > [TOLGA]IMO, the sentence you refer might really be
> > > mislaeading, but I don't think it should make the
> > SGP
> > > send DUPU for the case we are describing. Let's
> > say we
> > > have IPSP1 and IPSP2. If one user part is down on
> > > IPSP2, then it should be ASP part of IPSP2 taking
> > some
> > > action and sending ASPIA, not SGP part of IPSP2.
> > 
> > The case I was refering first, was a platform
> > hosting only one AS but
> > internally made of several services (SI), not always
> > available at the same
> > time.
> > If one SI is not available but the others are still
> > "usable", if the AS
> > is "Inactivated", all SI will be prohibited! In that
> > case the "IPSP" MAY
> > (that's my question) send a DUPU for the concerned
> > SI but the traffic 
> > for the others SI is still possible.
> > If IPSP cannot send a DUPU (or an UPU encoded), this
> > mean that an AS
> > identified by a PC only CANNOT corretly play several
> > SI.
> > 
> > So my question, is the DUPU allowed between two IPSP
> > ? 
> >    (or for a same reason between an AS and a SG(p) ?
> > )
> > 
> > > > --brian
> > > > 
> > > > -- 
> > > > Brian F. G. Bidulock
> > > > [email-masked]
> > > > http://www.openss7.org/
> > > > 
> > > > _______________________________________________
> > > > Sigtran mailing list
> > > > [email-masked]
> > > > https://www1.ietf.org/mailman/listinfo/sigtran
> > > 
> > > 
> > > __________________________________
> > > Do you Yahoo!?
> > > The New Yahoo! Search - Faster. Easier. Bingo.
> > > http://search.yahoo.com
> > > 
> > > _______________________________________________
> > > Sigtran mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/sigtran
> > > 
> > 
> > _______________________________________________
> > Sigtran mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/sigtran
> 
> 
> __________________________________
> Do you Yahoo!?
> SBC Yahoo! DSL - Now only $29.95 per month!
> http://sbc.yahoo.com
> 
> _______________________________________________
> 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: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 10 Jul 2003 14:34:26 -0600

Francois,

I don't think IPSP is that well defined yet.  We were supposed to address
it in an extension draft.  Some corrections have been made in the IG, but
a lot of work remains to be done.  We spent some time defining SG-SG
operation which makes more sense that the SE or DE models, but there wasn't
enough interest to advance the work.

--brian

Zannin, Francois wrote:                                                            (Thu, 10 Jul 2003 22:22:57)

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

---

From: Tolga Asveren <[email-masked]>
Date: Thu, 10 Jul 2003 13:40:22 -0700 (PDT)

Francois,
> the congestion on a remote IPSP.
[TOLGA] Again I would think, SCON is not necessary for
IPSP communication. 
In fact I think, it could be nice to have an ASPTM to
inform about congestion between peers, because IMO it
is more elegant than waiting the congestion to
propogate to the remote SCTP -maybe using ECN might
help- but I am representing the minority on this issue
(a minority of 1 person :) )