Subject: RE: [Sigtran] ASP Identifier

From: "Goel, Soni" <[email-masked]>
Date: Tue, 5 Mar 2002 12:25:03 -0800

Hi,

Following are my comments -
1) Notify for AS State Change - Following statement in section 4.3.4.5
should be corrected -
"A Notify message reflecting a change in the AS state MUST be sent to 
all ASPs in the AS, except those in the ASP-DOWN state, with
appropriate Status Information and any ASP Identifier of the failed 
ASP."

This should be changed to -
"A Notify message reflecting a change in the AS state MUST be sent to 
all ASPs in the AS, except those in the ASP-DOWN state, with
appropriate Status Information."

2) The following question remains unanswered -
> The Draft states following for "ASP Failure" -
> "For the ASP Failure case, the SGP is indicating to ASP(s)
> in the AS that one of the ASPs has transitioned to ASP-DOWN.  The ASP
> Identifier (if available) of the failed ASP MUST be placed in the
> message."
>
> Does it mean that if an ASP goes down and it was configured for AS1, then
> the "ASP Failure" message will be sent to only the ASPs which are
> active/inactive in AS1 ?
>
Yes or No ? If not, then to which ASPs ?

If an ASP is part of multiple RCs, and the answer to above question is YES,
this means that ASP Failure will be sent separately for each AS the ASP is
part of. In this case the corresponding RC can be filled in Notify.

3) The draft doesn't contain a open declaration that RC is required in case
of AS State changes + Insufficient ASP Resources Active in AS + Alternate
ASP Active, it is implied. It just states it is an optional parameter and
the following statement in 4.3.4.5 supports this -
"In the case where a Notify message does not contain a Routing Context
parameter, the receiver must know, via configuration data, of which
Application Servers the ASP is a member and take the appropriate 
action in each AS."

But as per the discussions in this thread this implication doesn't seem to
be true for ASP Failure. Therefore, the need of RC in Notify should also be
explicitly stated.

- Soni 

-----Original Message-----
From: Tolga Asveren [mailto:[email-masked]]
Sent: Tuesday, March 05, 2002 11:20 AM
To: Goel, Soni; Sigtran (E-mail)
Subject: RE: [Sigtran] ASP Identifier

Soni,

Please see comments below.

  Tolga

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Goel, Soni
> Sent: Tuesday, March 05, 2002 1:46 PM
> To: Sigtran (E-mail)
> Subject: RE: [Sigtran] ASP Identifier
>
>
> Hi,
>
> I have following queries -
>
> Does it mean that ASP Id is not required in following cases -
>
> 1) Notify with AS State Change - Yes or No
[TOLGA] ASP Id is not required.
> 2) Notify with Alternate ASP Active - Yes or No
[TOLGA] If available, ASP Id of the alternate ASP is required
>
> The Draft states following for "ASP Failure" -
> "For the ASP Failure case, the SGP is indicating to ASP(s)
> in the AS that one of the ASPs has transitioned to ASP-DOWN.  The ASP
> Identifier (if available) of the failed ASP MUST be placed in the
> message."
>
> Does it mean that if an ASP goes down and it was configured for AS1, then
> the "ASP Failure" message will be sent to only the ASPs which are
> active/inactive in AS1 ?
>
> Does the M3UA Draft state that "Routing Context is not present in the ASP
> Failure notification
> message" ? Can you please give me the section number ?
[TOLGA] If the ASP, which went down was active for multiple ASs, then how
are you planning to fill RC field? It is not openly stated in the draft but
RC is not to be filled for ASP Failure case. Well, indirectly it is still
indicated in the draft:
1- RC is optional, which means there are cases, where it is not filled.
2- For AS State changes + Insufficient ASP Resources Active in AS +
Alternate ASP Active, RC is needed
3- So, only ASP Failure case is left, if it needed RC, then RC wouldn't be
optional but mandatory.
>
> - Soni
>
> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Monday, March 04, 2002 9:04 PM
> To: Goel, Soni
> Cc: Sigtran (E-mail)
> Subject: Re: [Sigtran] ASP Identifier
>
>
> Soni,
>
> Goel, Soni wrote:                                           (Mon, 04 Mar
> 2002 18:32:07)
> >
> > 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.
>
> 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.
>
> > 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.
>
> 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.
>
> >
> > 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.
>
> 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?
>
> >
> > 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.
>
> 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
>
> >
> > - 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
>
> --
> Brian F. G. Bidulock
> [email-masked]
> http://www.openss7.org/
>
> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sigtran

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 5 Mar 2002 15:04:50 -0600

Soni,

Goel, Soni wrote:                                           (Tue, 05 Mar 2002 12:25:03)
> Yes or No ? If not, then to which ASPs ?

I send it to all ASPs not in the ASP-DOWN state.

> be true for ASP Failure. Therefore, the need of RC in Notify should also be

It's fairly clear from Section 3.8.2 that RC is only required (where not
implied) for AS state changes.  There is no statement requiring RC in
messages not related to an AS state change (ASP Failure).

--brian

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