Subject: RE: [Sigtran] ASP Identifier

From: "Goel, Soni" <[email-masked]>
Date: Mon, 4 Mar 2002 18:32:07 -0800

The issue is not with storing or retrieving the 32-bit information. The
issue with ASP-ID is that it addresses very specific implementations (as
your examples) which are not well documented in the Draft. When we talk
about an open standard, it should be as open as possible and should not
address specific implementations.

Draft requires that ASP Id must be sent in Notify message for some status
types. But it is not required as the Routing Contexts in the Notify are
sufficient.

The Notify message with Status type as "ASP Failure" is also not required.
The AS State Change or Insufficient Resources Active are sufficient as
discussed in earlier mails.

Your example also lists down a specific implementation scenario, where a
particular ASP acts as a spare to other ASPs. This should be handled through
implementation specific ways and the protocol should not be overloaded with
their requirements.

- Soni

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: Saturday, March 02, 2002 11:10 AM
To: Goel, Soni
Cc: Sigtran (E-mail)
Subject: Re: [Sigtran] ASP Identifier

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

-- 
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: Mon, 4 Mar 2002 23:04:24 -0600

Soni,

Goel, Soni wrote:                                           (Mon, 04 Mar 2002 18:32:07)
> address specific implementations.

I contend that the reverse is true: that the M3UA specification tries
(and rather successfully, I might add) to provide a general protocol
framework for interoperabililty in which a wide spectrum of specific
implementations are possible.  IETF protocols are not an attempt to
force a specific implementation approach at all, but to provide a
basis whereby different specific implementations can interoperate.

> types. But it is not required as the Routing Contexts in the Notify are

I think that this is the third time I have pointed this out, but:
Routing Context is not present in the ASP Failure notification
message.

> discussed in earlier mails.

No, because ASP Failures can occur without changing the status of
the AS.  ASPs still need to be notified of these failures.  I have given
you some examples of these situations.  Can you not think of others?

> implementation specific ways and the protocol should not be overloaded with

I disagree.  These procedures exist to permit the ASP to make informed
decisions and to remain in control of whether it takes action to become
active or not, independently of the SG.  This has always been the consensus
view of the WG and it makes perfect sense in backhaul scenarios as the
SG is the server and the ASP is the client.

Reducing the notification information provide be the server to the client
reduces the client's ability to take this action.  It is required to handle
a range of implementations, not to mention in support of the traffic modes
which are supported by the protocol.

--brian

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