Subject: Re: [Sigtran] Re: M3UA Notify message

From: "TOLGA ASVEREN" <[email-masked]>
Date: Tue, 25 Feb 2003 13:20:59 +0200

Brian,

TOLGA,

TOLGA ASVEREN wrote:
(Tue, 25 Feb 2003 08:39:11)
>
> Not necessarily because I disagree with some change, but just to clarify
> where the changes might take us:

If we cannot agree, we let the RFC stand.

> NTFY was used till now only as an advisory message, this will be changed.

No it will not.  An ASP is not forbidden from acting on any Notify message.
All Notify messages are still advisory.  The ASP can take into
consideration
Notify messages, information that it has about other ASPs, the time of day,
direction of the wind, etc.
[TOLGA]IMO important is, what ASP SHOULD do after receiving NTFY, if we
want to avoid interoperability problems. So I think to change handling of
NTFY is necessary.

> Starting/stopping(till now we focused more on starting but why not
stopping
> also? So SG can decide based on load/other dynamic conditions when to
stop
> traffic to/from AS) traffic will be controlled by SGP with NTFY.

The SG has always been permitted to start or stop traffic when it considers
it necessary and has always been permitted to perform its necessary
functions
with the SS7 network.  The SGP can send ASPIA Ack or drop associations any
time it wishes to stop traffic.
[TOLGA]If ASP is not ACTIVE for the AS, SGP should better not send traffic
to it. For stopping I agree that SGP can decide for this. My point is, this
better be reflected as a state change of AS and notified to ASP with NTFY,
which afterwards should stop traffic.

> IMO, this requires still a change to the original AS state machine for
> transitions from INACTIVE to ACTIVE and possibly from ACTIVE to PENDING.

It does not.  The SG is only withholding a Notify message as proscribed
by the RFC.
[TOLGA]Without state change, this is really ugly. Why do we have the state
machine then? In fact, another thing which is needed is probably the satet
machine from ASP point of view.

> In general all this will change the meaning of ASPAC/ASPAC-ACK exchange,
it
> will mean that ASP is ready to be triggered to send/receive traffic for a
> specific AS (something to be determined just by ASP, when the triggering
> will happen will be decided by SGP)rather than ASP can start to
> send/receive traffic for a specific AS(something to be determined by both
> ASP and SGP). I believe this migth require some other changes throughout
> the document. For example instead of unsolicited ASPIA-ACK, I would think
> SGP should send NTFY(INACTIVE). My opinion is, if we are changing
> something, let's do it clean and correct.

No nothing changes here because withholding NTFY(ACTIVE) is already part
of the RFC.  Nothing in the RFC changes.
[TOLGA]It is clear that it is not mandatory to take any action after
receiving NTFY. The only thing related with starting traffic from ASP is
that ASPAC/ASPAC-ACK exchange should be done and that ASP should wait till
number of ACTIVE ASPs reaches n.

>
> IMO, overall this is more than just a clarification, let's decide
carefully
> to prevent rollbacks (as much as possible).

Not even clarification is required.  The RFC details the necessary actions.
[TOLGA]IMO it doesn't. For example it says that ASPs should wait for n
ACTIVE ASPs (n interpreted as mandatory) and SGP may decide not to start
traffic and withhold NTFY (n not interpreted as mandatory)

The only thing that needs to be done is strike section 3.15 from the IG
because it conflicts with the RFC (which is fine as it is).
--brian

--
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 25 Feb 2003 06:52:22 -0700

TOLGA,

TOLGA ASVEREN wrote:                                                                 (Tue, 25 Feb 2003 13:20:59)
> want to avoid interoperability problems. So I think to change handling of

As the RFC says, the ASP SHOULD wait for "n" ASPs to become active.  How
it does that is its own business.  Nowhere does it say that the ASP should
wait for NTFY.  But the ASP is welcome to act on this information.  There
is no change to the advisory nature of NTFY.

There is no change to the RFC needed here.

> which afterwards should stop traffic.

If the SGP drops the association it will not be sending any NTFY messages until
it reestablishes it.  If the SGP sends ASPIA Ack and considers the AS in the
AS-INACTIVE state, it is already required by the RFC to send NTFY(AS_Inactive)
to all ASPs in the ASP-INACTIVE state for the AS.

Again, there is no change to the RFC needed here.

> machine from ASP point of view.

It is not ugly.  It is an optional procedure.

> number of ACTIVE ASPs reaches n.

Yes, nothing needs to change in the RFC.

> traffic and withhold NTFY (n not interpreted as mandatory)

That's right: there is no clarfication required.  The reasons behind the
MAY and the SHOULD have already been explained.

It does not change the fact that IG section 3.15 is in error and must be
struck.

--brian