Re: M3UA notify message

"Brian F. G. Bidulock" <[email protected]>
Newsgroups gmane.ietf.sigtran
Organization http://www.openss7.org/
Message-ID <[email protected]>
Tolga,

Obviously the RFC is not so clear or we would not be discussing it.

Where the RFC is unclear or contradictatory, it is normal to look
back to the consensus on the mailing list at the time that a specific
issue such as this was resolved.

The agreement was as in section 1.4.1 that AS state (not just SPMC view)
SHOULD be coordinated across the SGP making up an SG.  An on that point
the RFC is clear in section 1.4.1.

The later statement that the AS state is maintained in the M3UA layer
at the SGP is just an error resulting from the s/SG/SGP/g that Greg
did on the document about M3UA 07.  It should, of course, say that
the AS state is maintained in the M3UA layer at the SG.

And it is this to which you agreed in the mail thread from years ago.

--brian

Tolga Asveren wrote:                                                 (Wed, 22 Feb 2006 15:11:16)
> Brian,
> 
> I think RFC is the consensus, not the mailing threads from several years ago
> and I believe RFc is pretty clear about this issue.
> 
>    Thanks,
>    Tolga
> 
> > -----Original Message-----
> > From: Brian F. G. Bidulock [mailto:[email protected]]
> > Sent: Wednesday, February 22, 2006 3:11 PM
> > To: Tolga Asveren
> > Cc: [email protected]
> > Subject: Re: [Sigtran] M3UA notify message
> >
> >
> > Tolga,
> >
> > I think you need to look at that mail thread, where you agreed
> > to the opposite when the RFC was formed.
> >
> > --brian
> >
> > Tolga Asveren wrote:
> >    (Wed, 22 Feb 2006 14:44:56)
> > > Brian,
> > >
> > > > -----Original Message-----
> > > > From: Brian F. G. Bidulock [mailto:[email protected]]
> > > > Sent: Wednesday, February 22, 2006 2:20 PM
> > > > To: Tolga Asveren
> > > > Cc: [email protected]
> > > > Subject: Re: [Sigtran] M3UA notify message
> > > >
> > > >
> > > > Tolga,
> > > >
> > > > The concensus, to which you agreed, was that each SGP maintains
> > > > its own ASP state, but that AS state is shared across the SGP
> > > > making up an SG.  That is, when notification of AS state is given,
> > > > it is consistent for all SGP in the SG.
> > > [TOLGA]I agree with the first part but disagree with the second
> > part. Notify
> > > procedures seem to be between ASP/SGP based on what it stands
> > in the RFC. It
> > > is true that SG needs to form a uniqie view of SPMC for the AS but I
> > > wouldn't think this corresponds to following SGP/ASP procedures
> > on a SG-wide
> > > basis. I consider Notify procedures as part of the SGP/ASP relationship
> > > based on 4.3.4.5.
> > > >
> > > > If this were not the case, each SGP would form its own SG.  Part
> > > > of the fundamental purpose of an SG is to coordinate AS state,
> > > > both towards the SS7 network and towards the ASPs serving an AS.
> > > [TOLGA]I don't agree exactly with the last statement about SG
> > coordinating
> > > AS state towards ASPs. SG just aggregates the SPMC state towards SS7
> > > network. Each SGP maintains its own relationship with ASPs. It
> > is true that
> > > SGPs, which are  part of the same SG probably would be aware of
> > each others
> > > ASP states and would have an internal mechanism to route
> > messages between
> > > themselves but this kind of state sharing is not maintaining a single AS
> > > state in terms of following ASP/SGP procedures described in the
> > > specification.
> > > >
> > > > This is, indeed, as Nitin indicates, reflected in section 1.4.1.
> > > >
> > > > See the thread "[M3UA] AS state maching sharing between SGPs" from
> > > > May of 2001 for reference.
> > > >
> > > > Therefore, when the AS state changes (on this SG-wide basis), all
> > > > ASPs attached to all SGP in the SG are notified.  This is why I
> > > > say that ASP2 is notified by SGP2 in the original question.
> > > [TOLGA]I think different. 4.3.4.5 Notify procedures speaks of
> > ASP/ASP states
> > > which is kept on SGPs. It also makes sense, because it is the ASP state
> > > which is kept in SGP, is changing and is affecting whether
> > traffic could be
> > > sent/received via that SGP. that NTFY are advisory makes the
> > situation less
> > > drastic, but IMO changing NTFY for the state change on another
> > SGP is less
> > > than perfect.
> > > >
> > > > --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/
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.