RE: M3UA notify message

Prabind,

First let me express that I am not insisting that my view was right -anymore
;-)-. It seems that the majority thinks the oter way, and that is fine -For
now, I still believe not using global-AS for ASPTM opertaions is
architecturally more clean-. Still let me explain how it would work, if no
global-AS state was used for traffic mode related ASPTM operations -so
please keep in mind that all comments below are from that interpretation
point of view-.

    Tolga

> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
> Sent: Friday, February 24, 2006 12:48 AM
> To: [email protected]; [email protected]
> Subject: RE: [Sigtran] M3UA notify message
>
>
> Tolga,
> Well let me express in detail:
> "A combined view of the AS is maintained across all SGPs serving that
> AS. This means the state of AS would be maintained at SG. The sate of
> ASPs serving the (above) AS should be coordinated/shared across all SGPs
> serving the AS. Shared should not be taken as maintained. What I mean is
> the SGPs are just aware of the state of a particular ASP at a particular
> SGP in an AS. Only then they can have a combined view of AS"
>
> Now, if you don't agree with the above, let's consider the redundancy
> model n+k for AS. Here for simplicity I consider the value of n=2 and
> k=0. Guess you would agree that as per this model the AS would be
> considered active only when the number of active ASPs is 2.
> Let's also consider 2 ASPs (ASP1 and ASP2) and two SGPs (SGP1 and SGP2)
> for the above model.
>
> ASP1 ------------- SGP1 (sctp association established and ASP1 inactive)
>
>
> ASP2 ------------- SGP2 (sctp association established and ASP2 inactive)
[TOLGA]One would need associations between ASP1/SGP2 and ASP2/SGP1. I don't
think this is something horrible, on the contrary, I believe this is a good
thing to provide host redundancy. Otherwise, during host failures, there
would be internal traffic routing unnecessarily, e.g. consider
n=1/loadsharing traffic mode with your diagram, if ASP1 fails, all SS7
traffic from SGP1 first needs to be routed to SGP2, so that it can reach
ASP2, if there were an assocaition from ASP2 to SGP1, this wouldn't be
necessary-.
>
> Now if we take your view into consideration, then even if the ASPs
> become active at there respective SGPs (i.e. ASP1 at SGP1 and ASP2 at
> SGP2), the AS will still not be active. Why? For your view the ASPs
> states would not be shared across SGPs serving a common AS! And the
> minimum required ASPs are 2 for AS to become active!! Do you think,
> that's okay?? Isn't the redundancy model n+k takes the overall view of
> AS at SG to support failover? I guess with your view into consideration,
> the interoperability would be broken here as the AS would never become
> active.
>
> Alternatively, let's change the values. N=2 (still!) and K=1 and
> introduce another ASP3 having association with SGP2 but currently
> inactive. Now if SGP1 fails or ASP1 goes down, who do think would notify
> to ASP3 of insufficient ASPs?(assuming ASPs in AS are not able to share
> state information). Only SGP2 can do it and without the knowledge of the
> combined AS view, can it?? And combined AS view at SGP2 can only be
> arrived at with the ASP state sharing!!
[TOLGA]If both sides honor the same interpretation, I don't see any issues,
all ASPs would have associations to all SGPs and there won't be any problem
at all.
>
> Brian, your views?
>
> Regards,
>
> Prabind
>
>
> -----Original Message-----
> From: Tolga Asveren [mailto:[email protected]]
> Sent: Thursday, February 23, 2006 6:47 PM
> To: [email protected]
> Subject: RE: [Sigtran] M3UA notify message
>
> Prabind,
>
> > -----Original Message-----
> > From: [email protected] [mailto:[email protected]]
> > Sent: Wednesday, February 22, 2006 11:20 PM
> > To: [email protected]
> > Subject: RE: [Sigtran] M3UA notify message
> >
> >
> >
> > I am still concerned about this statement from Tolga:
> >
> > " In any case, it is good that there is finally consensus regarding
> that
> > ASPSM/ASPTM procedures and associated state machines being independent
> > on
> > each SGP."
> >
> > If multiple SGPs are serving a single AS, then shouldn't the ASP
> states
> > also be shared across the related SGPs?
> > Else if I am wrong then the following statement in section 1.4.1
> should
> > be amended to share the AS states only.
> > " Where an SG contains more than one SGP, the MTP3 routeset, SPMC and
> >    remote AS/ASP states of each SGP SHOULD be coordinated across all
> the
> >    SGPs."
> >
> > Tolga, further considering the sahring of ASP states then, in the case
> > of the interoperability issue (as you depicted), the rfc says that if
> an
> > ASP is already inactive the ASP-UP message would still be respnded by
> an
> > ack.
> [TOLGA]So are you claiming that there won't be an interoperability issue
> according to the message flow I sent? Please look to steps marked with
> (1)
> and (2). If one uses a global AS/ASP state which is SG-wide for
> ASPSM/ASPTM
> procedures, interoperability issues will arise. OTOH, with NTFY, there
> is no
> such danger, afterall it is just advisory.
> >
> > I think the things become simpler if we consider sharing of ASP states
> > of a particular AS across all SGPs serving that AS.
> >
> >
> > Regards,
> >
> > Prabind
> >
> >
> > -----Original Message-----
> > From: Tolga Asveren [mailto:[email protected]]
> > Sent: Thursday, February 23, 2006 6:53 AM
> > To: [email protected]
> > Subject: RE: [Sigtran] M3UA notify message
> >
> > Brian,
> >
> > As long as it is not an ASPSM/ASPTM procedure, it is fine. I probably
> > was
> > not careful when using the term "M3UA procedures" because it includes
> > pretty
> > much everything.
> >
> > BTW, I still wouldn't call it "M3UA procedure on each SGP", because
> SSNM
> > is
> > not sent independently by each SGP when status of a destination in SS7
> > network changes. It is supposed to be sent only once, but this is
> > besides
> > the point for this thread.
> >
> > In any case, it is good that there is finally consensus regarding that
> > ASPSM/ASPTM procedures and associated state machines being independent
> > on
> > each SGP.
> >
> >   Tolga
> >
> > > -----Original Message-----
> > > From: Brian F. G. Bidulock [mailto:[email protected]]
> > > Sent: Wednesday, February 22, 2006 8:34 PM
> > > To: Tolga Asveren
> > > Cc: [email protected]
> > > Subject: Re: [Sigtran] M3UA notify message
> > >
> > >
> > > Tolga,
> > >
> > > By an SGP, making it an "M3UA procedure on each SGP".
> > >
> > > --brian
> > >
> > > Tolga Asveren wrote:
> > >    (Wed, 22 Feb 2006 18:10:02)
> > > > Yes, SSNM will be sent per SG.
> > > >
> > > > BTW, my messages from a few hours ago started just to arrive, not
> in
> > the
> > > > order I sent them.
> > > >
> > > >    Tolga
> > > >
> > > > > -----Original Message-----
> > > > > From: Brian F. G. Bidulock [mailto:[email protected]]
> > > > > Sent: Wednesday, February 22, 2006 6:26 PM
> > > > > To: Tolga Asveren
> > > > > Cc: [email protected]
> > > > > Subject: Re: [Sigtran] M3UA notify message
> > > > >
> > > > >
> > > > > Tolga,
> > > > >
> > > > > BTW it is used for sending SNMM from an SGP: another M3UA
> > > > > procedure at an SGP.
> > > > >
> > > > > --brian
> > > > >
> > > > > Tolga Asveren wrote:
> > > > >    (Wed, 22 Feb 2006 15:36:22)
> > > > > > Brian,
> > > > > >
> > > > > > Please show where in the specification it says that
> ASPTM/ASPSM
> > > > > relationship
> > > > > > is between ASP and SG?
> > > > > >
> > > > > >    Thanks,
> > > > > >    Tolga
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Brian F. G. Bidulock [mailto:[email protected]]
> > > > > > > Sent: Wednesday, February 22, 2006 3:50 PM
> > > > > > > To: Tolga Asveren
> > > > > > > Cc: [email protected]
> > > > > > > Subject: Re: [Sigtran] M3UA notify message
> > > > > > >
> > > > > > >
> > > > > > > Tolga,
> > > > > > >
> > > > > > > Tolga Asveren wrote:
> > > > > > >    (Wed, 22 Feb 2006 15:28:21)
> > > > > > > > Barry,
> > > > > > > >
> > > > > > > > Let me retry to explain my position:
> > > > > > > >
> > > > > > > > Coordination of AS/ASP is necessary to create the unique
> > > > > SPMC view. This
> > > > > > > > does not mean that the coordinated state should be used
> for
> > > > > > > M3UA procedures
> > > > > > > > on each SGP. Each SGP should maintain its own staet
> machine
> > > > > from ASP/SGP
> > > > > > > > procedures point of view.
> > > > > > > >
> > > > > > >
> > > > > > > Your statements conflict with the consensus that went into
> > > > > > > the RFC as upheld by the mailing list discussion on the
> > matter.
> > > > > > >
> > > > > > > --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
> > > > >
> > > > > --
> > > > > 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
> >
> > _______________________________________________
> > 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
>