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

From: "TOLGA ASVEREN" <[email-masked]>
Date: Tue, 25 Feb 2003 16:31:24 +0200

Brian,

TOLGA,

TOLGA ASVEREN wrote:
(Tue, 25 Feb 2003 13:20:59)
>
> 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.

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.
[TOLGA]You also agree that RFC does interprete NTFY as an advisory message
but it is mandatory that ASP decides to start traffic based on NTFY(AS
ACTIVE) if we want SG to decide, when traffic flow between SGP/ASP is to be
opened. This needs to be clarified in IG. And IMO this also requires a
chnage in the AS state machine, for transition from INACTIVE to ACTIVE.
This transition won't occure with the first ACTIVE ASP but SG will decide
for it based on number of ACTIVE ASPs.
BTW, RFC says that ASPs coordinate among themselves number of ACTIVE ASPs
to decide to start traffic, again needs to be changed -if there is
consensus for the change-.

There is no change to the RFC needed here.

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

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.
[TOLGA]Yes, one needs to send NTFY(AS Inactive) in such a case, but still
advisory. And I would think, if ASPs rely on NTFY for activation, they
better rely on NTFY also for deactivation.

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

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

It is not ugly.  It is an optional procedure.

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

Yes, nothing needs to change in the RFC.
[TOLGA]Then it won't work like you propose, because ASPs won't care about
NTFY(AS Actıve) but they will coordinate number of ACTIVE ASPs and will
start traffic when this number 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)

That's right: there is no clarfication required.  The reasons behind the
MAY and the SHOULD have already been explained.
[TOLGA]That SGP MAY withhold traffic/Notify is what you propose, this is in
contradiction with the statement that ASPs SHOULD wait for n ACTIVE ASPs.
For example n=5. SG decides to start traffic with the 2nd ACTIVE ASP. But
according to RFC ASPs will wait for the 5th ACTIVE ASP before starting
traffic. In my opinion, this is a problem.

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

--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 07:50:18 -0700

TOLGA,

TOLGA ASVEREN wrote:                                                                 (Tue, 25 Feb 2003 16:31:24)
> opened.

I disagree.  The ASP can use whatever means it has at its disposal to decide
when "n" ASPs are active.  That includes advisory messages.  It is not
(and cannot be) required that the ASP start traffic based on NTFY(AS_ACTIVE),
but that does not forbid the ASP from using NTFY(AS_ACTIVE) in any fashion
it desires.

This is why the RFC says that the ASP SHOULD wait for "n" ASPs to start
traffic.  How the ASP decides when "n" has been reached is the ASP's own
business.  One of the things it may consider is NTFY.

This is no different than an ASP using (or not) NTFY("Insufficent ASPs
Active in AS") as one of a number of things to decide to go active.

> This needs to be clarified in IG.

It does not need to be clarified.

> And IMO this also requires a chnage in the AS state machine, for transition
> from INACTIVE to ACTIVE.  This transition won't occure with the first ACTIVE
> ASP but SG will decide for it based on number of ACTIVE ASPs.

No, no, no.  The SG moves the AS to AS-ACTIVE.  It only decides when to send
NTFY based on an OPTIONAL procedure.

> consensus for the change-.

They SHOULD coordinate until "n" are active.  This is already stated.

> better rely on NTFY also for deactivation.

The ASP can rely (or not) on NTFY until the cows come home.  It does not
change the advisory nature of NTFY.  The point is that the ASP is never
REQUIRED to act on NTFY messages.  They are advice: not commands.  This has
not changed.  The ASP is welcome to use whatever other means it has at its
disposal (e.g. coordinating between ASPs, but NTFY too if it so desires)
to determine when "n" ASPs are active.

Still there is no change required.  That is the way it is now in the RFC.

> NTFY(AS Actýve) but they will coordinate number of ACTIVE ASPs and will

So?  The ASPs SHOULD NOT start traffic until "n" ASPs are active regardless
of whether they receive NTFY(AS_Active) or not.  The RFC is fine as it stands.

> contradiction with the statement that ASPs SHOULD wait for n ACTIVE ASPs.

It is not.  The SG MAY withhold traffic and the ASPs SHOULD wait regardless.

> traffic. In my opinion, this is a problem.

There is no problem.  The ASPs should wait for the 5th ASP to be active before
starting traffic regardless of when the SG starts traffic.

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

Section 3.15 still needs to be struck because it is plain wrong.

--brian

---

From: Tolga Asveren <[email-masked]>
Date: Tue, 25 Feb 2003 12:15:22 -0800 (PST)

Brian,

[..snip..]

> For example n=5. SG decides to start traffic with
>the 2nd ACTIVE ASP. 
>But
> according to RFC ASPs will wait for the 5th ACTIVE
>ASP before 
>starting

There is no problem.  The ASPs should wait for the 5th
ASP to be active 
before
starting traffic regardless of when the SG starts
traffic.
[TOLGA]O.K. finally there we are, the source of the
disagreement. IMO, it is not a good idea to open/close
the traffic path between ASP/SGP unidirectionaly. 
And secondly, if you prefer SG to decide dynamically
to start traffic, why do you want ASPs to decide for
this statically by interpreting n as mandatory?

__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 25 Feb 2003 13:48:42 -0700

Tolga,

Tolga Asveren wrote:                                                                 (Tue, 25 Feb 2003 12:15:22)
> the traffic path between ASP/SGP unidirectionaly. 

Nowhere does it say that the traffic path need be
opened or closed unidirectionally.  The RFC talks about
the "start" of traffic, not the establishment of
unidirectional flows.

> this statically by interpreting n as mandatory?

The SG is neither required nor prohibited by the RFC to
decide dynamically.  Nor is the ASP required to decide
statically.

The RFC permits the SG to do what it needs to do with
regards to the SS7 network because of the "MAY".

The RFC recommends that the ASPs wait until "n" because
they SHOULD.

I explained the rationale behind both already on this
thread.

--brian

---

From: Tolga Asveren <[email-masked]>
Date: Tue, 25 Feb 2003 13:02:47 -0800 (PST)

Brian,
--- "Brian F. G. Bidulock" <[email-masked]>
wrote:
> Tolga Asveren wrote:                                
>                                 (Tue, 25 Feb 2003
> 12:15:22)
[TOLGA]IMO, the path between ASP/SGP will be opened
unidirectionslly, if ASPs will wait for n of them to
be ACTIVE whereas SG decides to not withhold traffic
when number of ACTIVE ASPs is less than n.
> decide dynamically.  Nor is the ASP required to
[TOLGA]For SG part I agree.But for ASP I disagree, RFC
says that ASPs SHOULD not start traffic before n of
them are ACTIVE, and this n is a static attribute. If
ASPs rely on NTFY for this, starting traffic will be
decided by SG and will be decided dynamically (or
better said by SG, which can base this decision also
to the configured value n statically, this IMO is
totally responsibility of SG)
> regards to the SS7 network because of the "MAY".
[TOLGA]The MAY is about withholding traffic to ASP
destination. I don't interprete it directly related
with interaction of SG with SS7 network.
> The RFC recommends that the ASPs wait until "n"
[TOLGA]So it is static according to RFC.

---

From: Tolga Asveren <[email-masked]>
Date: Tue, 25 Feb 2003 13:03:20 -0800 (PST)

Brian,

---

From: Tolga Asveren <[email-masked]>
Date: Tue, 25 Feb 2003 13:02:20 -0800 (PST)

Brian,

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 25 Feb 2003 14:34:24 -0700

Tolga,

Tolga Asveren wrote:                                                                 (Tue, 25 Feb 2003 13:02:20)
> when number of ACTIVE ASPs is less than n.

| For the n+k redundancy case, ASPs which are in that AS should
| coordianate amoung themselves the number of active ASPs in the AS, and
| should start sending traffic only after n ASPs are active.

This does not say that the ASP should not respond to traffic
delivered to it by the SG: it says that the ASP should not
"start" sending traffic.

It is just saying that the ASPs should coordinate going into
service and shouldn't start sending traffic until they are
capable of handling the expected load (and they shouldn't).

> totally responsibility of SG)

You are making many assuptions, most of which are not valid.
The SG does not "start" traffic because there is no stimulus
at the SG: the stimulus is either at the ASP or in the SS7
network.  All the SG can do is decide to "direct" traffic.
That does not mean that traffic actually exists, or that it
will exist any time in the near future after.

This is not a switch that you throw and current starts flowing.

> with interaction of SG with SS7 network.

But it is directly related to the SS7 network and that was
the reason for the MAY.  This is an AS which is newly active:
not an AS recovering from AS-PENDING.  Regardless of the
granularity of the RK, the SG has performed necessary management
functions towards the SS7 network with regards to the AS.
This could be UPU response, TFC response, or even TFP response
if the SG is acting as STP.  Directing traffic back to the
ASP for the AS requires that something be done to undo whatever
was told to the SS7 network.

As the SG's primary purpose in life is to transer traffic between
ASPs and the SS7 network, what did you think the SG was going to
do to "direct" traffic if it is not going to interact with the
SS7 network to do so?

> [TOLGA]So it is static according to RFC.

Where does it say static?  It says "coordinate" which sounds
pretty dynamic to me.

--brian