Re: Re: [M3UA] AS state machine sharing between SGPs
"Brian F. G. Bidulock" <[email protected]>
| Newsgroups | gmane.ietf.sigtran |
|---|---|
| Organization | http://www.openss7.org/ |
| Message-ID | <[email protected]> |
Tolga, Read the rest of the threads, or at least the note I quoted from Greg that I sent a moment ago. Tolga Asveren wrote: (Wed, 22 Feb 2006 16:58:56) > Brian, > > > I am fine with 1), it basically tells that ASPTM/ASPSM is between ASP/SGP > and for corresponding procedures ASP state is kept separate at each SGP. > Actually, this is the most important point in thread IMO from > interoperability point of view. > > I agree with 2) too, it is necessary to create the unique SPMC view -and > maybe for NTFY depending on interpretation (please see below)- but this > state shouldn't be used for ASPSM/ASPTM procedures. Read the other clip I sent from Greg. We agreed that Notify reflects the overall AS status. > > I agree with 3) as well. > > I assume 4) is mainly concerning NTFYs(?) Acutally, it refers to you note at the bottom: that as long as there is a concept of an SGP, that AS state needs to be shared between them. > > IMHO, two questions still need to be answered: > 1)Is advertising global AS state with NTFY, what we really want? It is what we agreed. > It seems like my argument of 5 years ago was not non-sense. OTOH, one could also > argue that if ASP state is kept per SGP and if NTFYs are going to be used to > possibly trigger some activity on ASPs, isn't it logical to expect that this > trigger is originating from the SGP, which wants a certain ASP do perform > some action? > 2)Regardless of the answer to 1), do we need text changes? I don't think so. Look at the other note that I sent from Greg to understand why the text says what it says today. The AS state is mantained at the SGP. This is because it is not always necessary to aggregate AS state (when there is only one SGP, or when only one SGP in the SG serves each AS). But the AS state SHOULD be coordinated over the SGP in an SG per 1.4.1. --brian -- Brian F. G. Bidulock [email protected] http://www.openss7.org/