Subject: RE: [Sigtran] ASP Identifier

From: "Goel, Soni" <[email-masked]>
Date: Fri, 1 Mar 2002 14:39:40 -0800

Please see Comments below.

- Soni
-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: Friday, March 01, 2002 1:14 PM
To: Goel, Soni
Cc: Sigtran (E-mail)
Subject: Re: [Sigtran] ASP Identifier

Soni,

Please see comments below...

Goel, Soni wrote:                                           (Fri, 01 Mar
2002 12:30:19)
> 
> Hi,
> 
> Please see my comments below.
> 
> - Soni
> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Thursday, February 28, 2002 6:05 PM
> To: Goel, Soni
> Cc: Sigtran (E-mail)
> Subject: Re: [Sigtran] ASP Identifier
> 
> 
> Soni,
> 
> Goel, Soni wrote:                                           (Thu, 28 Feb
> 2002 16:52:20)
> > Hi,
> > 
> > Why will an ASP need to know the identity of another ASP to decide which
> > traffic it wants to take over ? After the ASP receives the identity of
> > Application Servers, it becomes a local decision at ASP to determine
which
> > AS it wants to be active for.
> 
> RC is not part of the ERR("ASP Failure") message.The ASP does not receive
> the identify of the AS.  
> [Soni] RC is a parameter in Notify message.
> If the ASP failure does not change the overall state
> of the AS (e.g. loadshare with ASPs > n), the ASP will not receive AS
> notification either.  This still means that some AS are running
> "vulnerable".
> [Soni] In such a case the minimum number of ASPs required should be (n+1).
> So that if an ASP goes down and the AS becomes "vulnerable" then the
Notify
> message with state "Insufficient Resources Active for an AS" can be sent
> with the RC to the Inactive ASPs in the AS. This removes the need for "ASP
> Failure".

Well, no.  The behavior of the SG in this case could be to move to
AS_PENDING.
insufficient resources and just sufficient resources are two different
things.
ASP Failure is still required to avoid pending at the SG.
[Soni] An AS can move to AS-PENDING when the last Active ASP changes to
Inactive/Down state. Sending Notify with ASP Failure after the last ASP goes
down will not help prevent AS-PENDING state. If the ASP going down is not
the last one and now the number of ASPs required has become less than the
minimum required, Notify with Insufficient Resources will be sent. If the
number of ASPs is not less than minimum required,then there is no need to
send Notify.

> 
> If the ASP has the identify of the failed ASP, it can determine for which
AS
> it is sparing the other ASP and become active for those AS before things
> become critical.  
> [Soni] For the ASP to determine for which AS is has to come Active, it
needs
> to know only the identity of the AS.

RC is not in the NTFY("ASP Failure") message.  And for good reason in SUA
where the number of AS supported by an ASP could be a very large number.
[Soni] NTFY with ASP Id expects an ASP to know all the Application Servers
other ASPs are active for. This is implementation dependent whether an ASP
knows such information or not. The protocol should not cater to specific
implementations.
Additionally, since RC is a parameter in Notify message. And "ASP Failure"
is a status type of Notify message. So it is wrong to say that "RC is not in
the NTFY("ASP Failure") message"

> Unfortunately, the SG does not notify when the AS only has
> `n' processors, just when it has `n-1'.
> [Soni] Please see the first two comments.
> 
> > Moreover, once an ASP becomes active for an AS in Override mode, it has
to
> > handle all the AS traffic. And if the AS is in Loadshare mode then it is
> the
> > SGP which decides the traffic distribution based on the Loadshare
> algorithm.
> 
> But you forget, as above, that the ASPs are still responsible for
> determining
> how many ASPs are serving a loadshare AS.
> [Soni] ASPs need to know the AS which is getting affected because some ASP
> has failed, so that it can come active for this AS.
> 
> Also, in broadcast mode, the ASPs determine which traffic distribution
they
> are serving, not the SG.  So, broadcast mode is another example of where
an
> ASP needs to know the identify of the failed ASP to determine the traffic
> that
> it needs to assume.
> [Soni] It seems that ASP Id and ASP Failure status in Notify message are
> only required for Broadcast mode.

ASP Id is also required in loadshare as above.
[Soni] ASP Id is not required in Loadshare mode because as said earlier -
ASPs need to know the AS which is getting affected because some ASP has
failed, so that it can come active for this AS. It is the SGP which
distributes the traffic to ASPs.

> Thus, ASP Id in ASP Failure is again necessary.
> 
> [Soni] Draft states that ASP Id MUST be present in Notify message in case
of
> AS State Change and "Alternate ASP Active". This is also not required.

This is required in Override so that the ASP can determine the identity
of the overriding ASP.  The ASP can use this information to inform local
management of who took over, as well as permitting the now INACTIVE ASP
to determine its next course of action.  (For example, for some ASPs it
could be persistent and override again.)

An example scenario would be where two ASPs are sparing each other on a
given AS: ASP1 is active and ASP2 is not.  A third ASP3 overrides the
AS even though it has no business doing so.
  ASP1 gets NTFY("Alternate ASP Active", ASP3) and can determine that the
override was in error and
perform its own ASPAC REQ to override back.
[Soni]How can this be ? Draft states -
"In the case where an "out-of-the-blue" ASP Active message is received 
(i.e., the ASP has not registered with the SG or the SG has no static 
configuration data for the ASP), the message MAY be silently discarded. "
Therefore, ASP3 cannot come active if it has no businees doing so.

Soni, ASP Id is a useful feature of the protocol, but only when included
in the proper messages.
[Soni] ASP Id is a useful feature of the protocol to be used in case of
Dynamic Port assignments. But it is not required in Notify messages.

  It is an extra piece of information that the SGP
has at its disposal which permits ASPs to make informed decisions about
what action to take in response to these events.  The focus of the protocol
has always been to put the ASPs in control of activation and deactivation
and have the SG just satisfy those requests.
[Soni] Yes ASPs are in control of activation and deactivation, that is why
ASPs just need the RC in Notify messages.

That is why NTFY messages are largely adivisory only.  As advisory messages,
they should contain as
pertinent information.  The Id of an ASP in an ASP related notification
message must include the ASP Id, otherwise it is worthless to the receiver.
[Soni] No, the Notify message is worthless when it doesn't contain the RC
because this is the only piece of information ASPs require to decide
activation or deactivation.

--brian

> 
> --brian
> 
> 
> -- 
> Brian F. G. Bidulock
> [email-masked]
> http://www.openss7.org/
> 
> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sigtran

-- 
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: Sat, 2 Mar 2002 13:10:16 -0600

Soni,

I have 3 ASPs in a loadshare AS.  Two are active (ASP1, ASP2), the third
(ASP3) is INACTIVE and acts as a standby.  I have on more roamer ASP
(ASPX) which replaces failed standby ASPs for many AS.

ASP3 Fails.  How does ASPX know to replace it?  Because it receives
NTFY("ASP Failure", ASP3) from the SG.

Also your argument below makes no sense: if the SG is capable of blocking
ASPAC from an ASP it must know the identify of the ASP and can easily place
it into the NTFY messages.

You seem to have a great problem storing and retrieving this useful 32-bit
identifier.

--brian

Goel, Soni wrote:                                           (Fri, 01 Mar 2002 14:39:40)

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