Subject: RE: [Sigtran] Sigtran Plugtest - DAY 2-5: M3UA IPSP

From: "J.Javier Pastor (KI/EEM)" <[email-masked]>
Date: Fri, 5 Sep 2003 18:16:17 +0200

Hi Tolga, 

Thanks for your comments. Pls, see below...

> -----Original Message-----
> From: Tolga Asveren [mailto:[email-masked]]
> Sent: viernes, 05 de septiembre de 2003 18:04
> To: [email-masked]
> Subject: RE: [Sigtran] Sigtran Plugtest - DAY 2-5: M3UA IPSP 
> 
> 
> Hi Javier/Brian,
> > -----Original Message-----
> > From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of
> > J.Javier Pastor (KI/EEM)
> > Sent: Friday, September 05, 2003 11:42 AM
> > To: [email-masked]'
> > Cc: Ken Morneault; [email-masked]
> > Subject: RE: [Sigtran] Sigtran Plugtest - DAY 2-5: M3UA IPSP
> >
> >
> > Hi Brian,
> >
> > Pls, see below...
> >
> > > -----Original Message-----
> > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > Sent: viernes, 05 de septiembre de 2003 16:10
> > > To: J.Javier Pastor (KI/EEM)
> > > Cc: Ken Morneault; [email-masked]
> > > Subject: Re: [Sigtran] Sigtran Plugtest - DAY 2-5
> > >
> > >
> > > J.Javier,
> > >
> > > J.Javier Pastor (KI/EEM) wrote:
> > >                     (Fri, 05 Sep 2003 15:11:24)
> > >
> >
> >
> >
> > [snip]
> >
> >
> > > >
> > > > > >
> > > > > > 8)  In IPSP SE, should the ASP receiving ASP Up/Active Ack
> > > > > > also send Notify messages?  General though is that 
> it should.
> > > > >
> > > > > No, the IPSP sending ASP Up/Active Ack sends Notify.
> > > >
> > > >
> > > > I agree with the general thought. Once the communication is
> > > established they
> > > > should work in a peer-to-peer basis. Then both could send NTFY.-
> > >
> > > Both sending notify would be both acting like SG.  Which is SG-SG
> > > communication.  Which is something different that SE and 
> DE.  SE is
> > > inherently ASP-SG communication.  Only one side behaves 
> like an SG.
> > > Only one side sends notify.
> > >
> > > Don't try to make SE, DE again... ;)
> > >
> >
> >
> > After doublechecking, I would recommend not to send the NTFY
> > because those IPSP are the one who are acting as a client.
> > Sending NTFY from the SG was due to SG is the server and they can
> > not react upon a state change. So they have to inform the client
> > part of the current status.
> >
> > In this case the IPSP receiving ASP receiving ASP Up/Active Ack
> > acts as a client. They don't need to inform the others, they can
> > themselves take the action of sending ASPAC or ASPIA.
> [TOLGA]I respectfully disagree that IPSP-SE is a client/server model
> (IPSP-DE is). ASPAC/ASPAC-ACK has different semantic for 
> IPSP-SE than for
> regular ASP/SGP case. It has meaning for both directions, and 
> means "My AS
> wants to communicate with your AS -where those AS are defined 
> by the RK-,
> rather than "My AS wants to get a service from you". IMO, 
> none of the IPSP
> is acting as a client(or as a server) in IPSP-SE, it is really kind of
> peer-to-peer. So, I still would think sending NTFY in both 
> directions might
> be usefull, to inform other IPSPs serving the same AS, about 
> the state of
> AS.
> 

I agree with you in some extend. It can be seen as a peer-to-peer model. But once we decide that one end takes the initiative (what I called "client" :-/), upon a peer IPSP node failing it may send ASPAC or ASPIA directly tot he others IPSPs serving that AS, instead of NTFY. Otherwise, sending NTFY, is the peer who is requested to take the initiative.

What we should avoid here is that we reach a DE. If we decide that after sending NTFY, the other end is the only one who can send ASPAC/IA , it will also work.

I mean, I think both approaches could work somehow. But setting some rules: after sending NTFY, wait for the peer nodes to send ASP*M messages.

Cheers // Javier.

> 
> _______________________________________________
> 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: "Tolga Asveren" <[email-masked]>
Date: Fri, 5 Sep 2003 13:16:21 -0400

Hi Javier,
> From: J.Javier Pastor (KI/EEM) [mailto:[email-masked]]
> Sent: Friday, September 05, 2003 12:16 PM
> To: 'Tolga Asveren'; [email-masked]
> I agree with you in some extend. It can be seen as a peer-to-peer
> model. But once we decide that one end takes the initiative (what
> I called "client" :-/), upon a peer IPSP node failing it may send
> ASPAC or ASPIA directly tot he others IPSPs serving that AS,
> instead of NTFY. Otherwise, sending NTFY, is the peer who is
> requested to take the initiative.
>
> What we should avoid here is that we reach a DE. If we decide
> that after sending NTFY, the other end is the only one who can
> send ASPAC/IA , it will also work.
[TOLGA]I believe, what makes IPSP-SE a peer-to-peer like model is not the
number of ASPAC/ASPAC-ACKs received, but that it opens data path in both
directions simultaneously. So, for the failure case you described, I
wouldn't think it is necessary to have the restriction that sending ASPAC
should be restricted to one side. IMO, for IPSP-SE, NTFY is usefull to
inform INACTIVE IPSPs when AS switched to ACTIVE, so that they don't try to
send ASPAC for such an AS. If they send ASPAC, it is still not bad, just not
desireable.
>
> I mean, I think both approaches could work somehow. But setting
> some rules: after sending NTFY, wait for the peer nodes to send
> ASP*M messages.
[TOLGA]Do we really need this restriction? Now one might think of some race
conditions among ASPACs sent by different peers, but IMO this shouldn't be a
problem from AS state machine point of view. Just both sides acknowledge
with ASPAC-ACK.