RE: M3UA notify message

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.


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.


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.

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

    Thanks,
    Tolga

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email protected]]
> Sent: Thursday, February 23, 2006 2:01 PM
> To: Tolga Asveren
> Cc: [email protected]
> Subject: Re: [Sigtran] M3UA notify message
>
>
> Tolga,
>
> As Greg noted 5 years ago, global AS state is not necessary when:
> there is only one SGP in the SG; or, only one SGP in the SG serves
> any AS.  That is why changes were not made to section 4.3.
> Nevertheless, section 1.4.1 is clearly stated.  I still think that
> the original text is adequate.  What the document needs is several
> examples that include multiple SGPs in an SG serving an AS, say,
> one for each traffic mode.
>
> --brian
>
> Tolga Asveren wrote:
>    (Thu, 23 Feb 2006 10:28:27)
> > If there is consensus about using global-AS state for traffic
> mode related
> > procedures, we better have some explanation about it. IMHO, the
> way it is
> > stated right now in the RFC/IG does hardly lead to that
> interpretation -I am
> > speaking of section 4.3 -.
> >
> >    Thanks,
> >    Tolga
> >
>
> --
> Brian F. G. Bidulock
> [email protected]
> http://www.openss7.org/
>