RE: M3UA notify message

Brian,

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email protected]]
> Sent: Thursday, February 23, 2006 3:32 PM
> To: Tolga Asveren
> Cc: [email protected]
> Subject: Re: [Sigtran] M3UA notify message
>
>
> Tolga,
>
> Tolga Asveren wrote:
>    (Thu, 23 Feb 2006 14:34:22)
> > Brian,
> >
> > Yes, obviously there is no issue for the single SGP case.
> >
> > I still think relying on the the private AS state of SGP for the traffic
> > mode operation is a more elegant solution. It allows the
> ASPTM/ASPSM logic
> > of SGPs run independently in a simplex way and requires some
> coordination
> > only to generate SPMC, which is a MTP3 construct anyhow. I
> really interprete
> > Greg's e-mail a bit different than you as well. To me, it seems
> that global
> > AS-state issue was more to accomodate my complain about NTFYs, and to be
> > honest I think he made the wrong decision. I think it is a
> better idea to
> > keep ASP/SGP interface totally clean, where the concept of SG
> is not visible
> > unless it is really required, i.e. for SSNM related issues,
> where SG is a
> > single entity. This basically means to run ASPSM/ASPTM procedures
> > independently on each SGP. Afterall, the concept of AS is a
> M3UA construct,
> > and there we have the freedom to decide for its scope.
>
> Then there would be no difference (other then SSNM) between an SG and an
> SGP.  We agreed years ago that there was a difference between an SG and
> an SGP.  An SG coordinates SPMC and AS/ASP state across all the SGP
> serving an AS.
[TOLGA]Concepts/Requirements shouldn't be created just for the sake of
creating them.There should be a reason for them. For example for single SPMC
view there is a good reason: It is a requirement put by SS7 specifications,
we can't change it, so we need to comply with it.
>
> > I believe passages similar to below are describing use of the
> indpendent AS
> > state for traffic mode related procedures:  -from 4.3.4.3 ASP Active
> > Procedures-
> >    In the case of an Override mode AS, reception of an ASP Active
> >    message at an SGP causes the (re)direction of all traffic for the AS
> >    to the ASP that sent the ASP Active message.  Any previously active
> >    ASP in the AS is now considered to be in state ASP-INACTIVE and
> >    SHOULD no longer receive traffic from the SGP within the AS.  The SGP
> >    or IPSP then MUST send a Notify message ("Alternate ASP_Active") to
> >    the previously active ASP in the AS, and SHOULD stop traffic to/from
> >    that ASP.  The ASP receiving this Notify MUST consider itself now in
> >    the ASP-INACTIVE state, if it is not already aware of this via
> >    inter-ASP communication with the Overriding ASP.
>
> No, no, no.  See Ken's note on override mode from the old mail thread.
> Ken describes the following scenario (his is more complicated):
>
>     ASP1/AS1         ASP2/AS1        SGP1/SG1         SGP2/SG1
>        |                 |               |                |
>        |----ASPUP----------------------->|                |
>        |<---ASPUP Ack--------------------|                |
>        |<---NTFY(AS Inactive)(AS1)-------|                |
>        |<---NTFY(Insuff ASPs)(AS1)-------|                |
>        |                 |               |                |
>        |                 |----ASPUP---------------------->|
>        |                 |<---ASPUP Ack-------------------|
>        |                 |<---NTFY(AS Inactive)(AS1)------|
>        |                 |<---NTFY(Insuff ASPs)(AS1)------|
>        |                 |               |                |
>        |----ASPAC-(AS1)----------------->|                |
>        |<---ASPAC Ack-(AS1)--------------|                |
>        |<---NTFY(AS Active)(AS1)---------|                |
>        |<---NTFY(Alt ASP Act)(AS1)(ASP1)-|                |
>        |                 |<--NTFY(AS Active)(AS1)---------|
>        |                 |<--NFTY(Alt ASP Act)(AS1)(ASP1)-|
>        |                 |               |                |
>        |<---DATA-------------------------|                |
>        |<---DATA-------------------------|<--DATA---------|
>        |<---DATA-------------------------|                |
>        |<---DATA-------------------------|<--DATA---------|
>        |                 |               |                |
>        |                 |---ASPAC (AS1)----------------->|
>        |                 |<--ASPAC Ack (AS1)--------------|
>        |                 |<--NTFY(Alt ASP Act)(AS1)(ASP2)-|
>        |<---NTFY(Alt ASP Act)(AS1)(ASP2)-|                |
>        |                 |               |                |
>        |                 |               |---DATA--------\|
>        |                 |<--DATA-------------------------|
>        |                 |               |---DATA--------\|
>        |                 |<--DATA-------------------------|
>        |                 |               |---DATA--------\|
>        |                 |<--DATA-------------------------|
>        |                 |               |                |
>        |                 |               |                |
>
> Above, SGP2 follows the text in 4.3.4.3 to the letter; however, AS/ASP
> state is coordinated across the SGPs serving the AS in accordance with
> 1.4.1.
>
> When SGP2 receives the ASP Active it redirects traffic to ASP2.  Note
> that it must also redirect traffic from SGP1.  ASP1 is now considered
> ASP-INACTIVE in the AS.  This is also true on SGP1.
>
> Ken mentioned that the way to resolve problems with override mode was
> to act only on the last ASP Active received by the SG.  Which means
> that the procedures are executed by the SGP with knowledge of the
> overall (SG-wide) state of an ASP within an AS.
[TOLGA]I don't recall the details of the problem (IETF mail-archive starts
somewhere in 2002), so if you just tell about the problem statement, it
could be good to refresh the memory.
When I think about the scenario, I guess it could be something like that:
ASP2 wants to override ASP1. If no global-AS view is used, with the
ASPAC/ASPAC-ACK exchange with SGP1, SGP1 will start using ASP2 but SGP2 will
wait till the ASPAC/ASPAC-ACK exchange is performed with it as well.
I don't know whether this will be practically a big issue considering that
ASP2 can send ASPAC to SGP1 and SGP2 simultaneously -yes, they still won't
arrive simultaneously at SGP1 and SGP2-.
If one considers the scenarios where an ASP overrides another one, e.g.
ASP1 will be put down for maintainenece-, similar timing issues will arise
with multiple SGs as well. Obviosly, we can't say that ASPs using multiple
SGs, shouldn't be replaced. Based on that, I would expect ASPs to be clever
enough to deal with such situations.
>
> > Now, before we start exchanging thousands of e-mails, let me tell that I
> > don't think any of the choices is "wrong". Both of them will
> work as long as
> > both ASP and SGP have the same interpretation. Obviously the
> first priority
> > is to document the consensus clearly in the RFC/IG. I don't
> think the text
> > is clear enough. My and other peoples confusion is a good
> evidence for that.
> > My personal opinion is that there is contradicting stataments
> in the RFC/IG
> > and I don't necessarily aggree with you that everything is put there
> > actually with a unified view of how things are supposed to work.
>
> There are not contradicting statements.
[TOLGA]Let me try to summarize what I find as weak explanation in the
specification:
>From the passage I quoted before:
The SGP
   or IPSP then MUST send a Notify message ("Alternate ASP_Active") to
   the previously active ASP in the AS, and SHOULD stop traffic to/from
   that ASP.

I would expect here "SG SHOULD stop traffic to/from that ASP" not "The SGP".
Similar not-so-clear statements are all over 4.3

Actually if we are so fond of using that global-AS state for traffic mode
related ASPTM procedures, why don't we use it for all ASPTM? Why is ASPAC
sent both to SGP1 and SGP2 from ASP1? SGP2 will identify ASP1 with
ASPUP/ASPUP-ACK exchange and can know from the global-AS view that it is
already in ACTIVE state. -Just to be clear, I am not proposing this ;-) -
>
> > I think the two options are clearly explained in this thread in
> terms of how
> > they are supposed to work. My personal choice is to have all ASPSM/ASPTM
> > independent on SGPs, without using any global AS state for that purpose.
>
> Cannot work.  And is contrary to the existing RFC and the design
> approach agreed by concensus leading to wide ranging changes between
> M3UA Draft 7 and M3UA Draft 8.
[TOLGA]Just out of curiosity, why can't it work, if both ASP and SGP have
the same interpretation?
>
> > AFAICS, you are in the opinion that using global-AS state on SGPs for
> > certain ASPTM procedures is a better idea. I think Barry and
> Lincoln think
> > similar to you(?). For other people, I don't have a clear guesstimate. I
> > also would think that it would be useful to have opinions from
> more people.
> > In any case, let's decide what needs to be done and do it.
>
> Nothing needs to be done, except a few examples.  If you have another
> proposal, please, craft some text and propose it.
[TOLGA]Examples are important too. For the unnecessity of the text changes,
I will remind you on that, when this issue comes up again ;-)
>
> --brian
>
> --
> Brian F. G. Bidulock
> [email protected]
> http://www.openss7.org/
>