Subject: RE: [Sigtran] ASP Identifier

From: "Vats, Umesh" <[email-masked]>
Date: Tue, 5 Mar 2002 15:09:25 -0800

Hi  Brian

The following section in ASP Inactive Procedures in M3UA 
draft specifically talks about sending NTFY message with "Insufficient ...
*".

"In the case of a Loadshare mode AS, the SGP moves the ASP to the ASP-
INACTIVE state and the AS traffic is reallocated across the remaining 
ASPs in the state ASP-ACTIVE, as per the loadsharing algorithm 
currently used within the AS.  A Notify message ("Insufficient ASP 
resources active in AS") MAY be sent to all inactive ASPs, if required.  
An ASP Inactive Ack message is sent to the ASP after all traffic 
is halted and Layer Management is informed with an M-ASP_INACTIVE 
indication primitive." 

The corresponding text is missing in the ASP Down and ASP failure cases. 

Umesh

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: Tuesday, March 05, 2002 12:06 PM
To: Vats, Umesh
Cc: Sigtran (E-mail)
Subject: Re: [Sigtran] ASP Identifier

Umesh,

Vats, Umesh wrote:                                          (Tue, 05 Mar
2002 10:56:01)
> Hi  Brian
> 
> In this case, M3UA specs should specify that
> NTFY message with "Insufficient ASP resources active in AS"
> may be sent in the following cases also :
>   1. ASP going down(on reception of ASP-DOWN message)
>   2. Connectivity between SGP and ASP going down(Association faliure).
> 
> Right now, the NTFY with "Insufficient ASP resources active in AS"
> is sent only when ASP-INACTIVE is received.

Your statement is incorrect.  Section 4.3.4.5 says that AS state
change notifications must be sent regardless of whether the state
change was a result of an ASP management message or whether it was
the result of an ASP failure.

The answer is "Both".

--brian

> 
> Umesh
> 
> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Thursday, February 28, 2002 2:34 PM
> To: Vats, Umesh
> Cc: Sigtran (E-mail)
> Subject: Re: [Sigtran] M3UA NOTIFY Message
> 
> Umesh,
> 
> Both.
> 
> --brian
> 
> Vats, Umesh wrote:                                          (Thu, 28 Feb
> 2002 12:10:39)
> > Hi
> > 
> > Let us suppose that at SG, it is configured that 
> > minimum N number of ASPs should be active for an AS.
> > Also suppose that all the N and only N ASPs for this 
> > AS are active at the moment.
> >  
> > Now one of the N ASPs fails for that AS(due to association
> > going down). Which NOTIFY message should SGP send to the
> > remaining ASPs :
> > 
> > 1. NTFY message for "Insufficient ASP resources 
> >                        active in AS"
> > 2. NTFY message for "ASP Failure"
> > 3. Both
> > 
> > Umesh
> > 
> 
> -----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

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

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

---

From: "Vats, Umesh" <[email-masked]>
Date: Wed, 6 Mar 2002 09:54:14 -0800

Hi  Brian

I too believe that the description of ASP Id is
inadequate in the current M3UA draft. Similar
views have been expressed by other members also.

Some more details are needed in the draft regarding the
Need, Usage, Scope and Procedures for ASP Id. This will
obviate the need for each new implementor to dig through 
all the mailing list archives for reaching some understanding
about an ASP Id. Also, different members may arrive at
different conclusions about ASP Id if concise and clear
explanation for it is missing in the draft.

The following two usages of ASP Id need to be mentioned 
clearly in the draft :
1. Use at SGPs where the ASPs connected to it 
   use dynamic port allocation
2. USe at ASPs (e.g acting as standby for some ASPs in
   AS)

Umesh 

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: Wednesday, March 06, 2002 9:33 AM
To: Nitin Vairagare
Cc: Goel, Soni; 'Tolga Asveren'; Sigtran (E-mail)
Subject: Re: [Sigtran] ASP Identifier

Nitin,

Nitin Vairagare wrote:                                      (Wed, 06 Mar
2002 09:55:20)
> This has been a long discussion with certain good points.
> But this clearly shows there isn't very clear text for
> use of ASP Identifier. And that is why different
> implementation tend to have different assumptions.
> 
> Can some one summarise text for ASP Identifier?
> 1) Clear definition for ASP Identifier (including usage)?

It's definition is clear: it identifiers an ASP.

> 2) what is scope of it?

It's scope is obviously the SGP receiving it.  The SGP
has two error codes: "ASP Identifier Required" and "Invalid
ASP Identifier."

> 3) What are different scenarios it can be used?

These are examples and can be address in an imp guide.

> 4) clear procedures to use it.

It is identified in which message the APS Identifier must
appear.

> 5) If it makes redundancy and take over procedure clear
>    then why can't we make it mandatory for networks
>    using more than one ASP behind SGP? And thereby define
>    clear procedure for notifications and action taken by
>    ASPs.

Because there were those in the WG strongly against making it
a mandatory field in the ASPUP, because the SGP could, by examining
IP addresses and port numbers in some cases of static allocation,
identify the ASP itself.  Please look back in the archives at the
previous discussions on ASP Identifier.

> 
> This would help to every one understand it better and
> concur in usage.

Everyone has understood it and concurred on usage: please refer
to the archives.  It may not be so well captured in the drafts,
but certainly ASP Id is not the only thing in that category.

Do you wish to delay the RFC to change these things?  Does anyone
else?

--brian

> Regards,
> Nitin
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Brian F. G. Bidulock
> Sent: Tuesday, March 05, 2002 4:56 PM
> To: Goel, Soni
> Cc: 'Tolga Asveren'; Sigtran (E-mail)
> As the ASP Failure notification is not required to contain an
> RC, when an ASP is "in" an AS or not is rather moot.  It is up
> to the ASP receiving the notification to determine what action
> to take.  Sending the notification to all ASPs not in the
> ASP-DOWN state ensures that no ASP is "missed" with the
> notification without needing to calculate membership.  As
> mentioned in 4.3.4.5, "[t]he ASPs remain in control of what
> (and when) traffic action is taken."  Therefore, a policy at
> the SGP which ensures that no ASP is missed is superior to a
> policy that might miss notifying a concerned ASP, for all
> notifications.  But, the draft does not required this, because
> it is not the draft's place to tell an implementation how to
> meet the requirements.
> 
> I don't see any problem in capturing this in the
> implementation guide.
> 
> --brian
> 
> Goel, Soni wrote:                                           (Tue, 05 Mar
> 2002 13:38:34)
> >
> > Don't you think that all these assumptions have to be taken because the
> > Draft doesn't state clearly the usage of ASP Id and ASP Failure. It will
> be
> > better for the protocol to be clear because you think that an ASP which
> has
> > not been registered for an AS, is still "in" an AS....although I think
> that
> > ASP can be said "in" an AS only when it is registered
> statically/dynamically
> > in that AS.
> >
> > Soni
> >
> >
> > Sent: Tuesday, March 05, 2002 1:30 PM
> > To: Goel, Soni
> > Cc: 'Tolga Asveren'; Sigtran (E-mail)
> > I send it to all ASPs that are ASP-UP within the scope of the ASP Id.
> > I do not support ASP Id scopes of less than an SGP (because ASP Id
> > is scoped on a per-SGP basis for its use in dynamic port assignment).
> > ASPs in the ASP-UP state which have not yet registered for any AS
> > also need to receive this notification, so I send it to all ASPs
> > associated with the SGP not in the ASP-DOWN state.  This does not
> > conflict with the statements in the draft, because I consider ASPs
> > that have not yet registered for an AS as being "in" the AS even
> > though they are not in the ASP-INACTIVE or ASP-ACTIVE state with
> > respect to that AS.
> >
> > --brian
> >
> >
> > Goel, Soni wrote:                                           (Tue, 05 Mar
> > 2002 13:17:04)
> > >
> > > Is it to all the ASPs associated with the SGP, or all the ASPs in the
> > > configured AS ?
> > >
> > > - Soni
> > > Sent: Tuesday, March 05, 2002 1:05 PM
> > > To: Goel, Soni
> > > Cc: 'Tolga Asveren'; Sigtran (E-mail)
> > > Goel, Soni wrote:                                           (Tue, 05
Mar
> > > 2002 12:25:03)
> > > > 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 ?
> > >
> > > I send it to all ASPs not in the ASP-DOWN state.
> > >
> > > >
> > > > 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.
> > >
> > > 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
> > >
> > > >
> > > > - Soni
> > > >
> > > > 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
> > > >
> > > > > 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
> > > > >
> >
> > --
> > Brian F. G. Bidulock
> > [email-masked]
> > http://www.openss7.org/
> 
> --
> Brian F. G. Bidulock
> [email-masked]
> http://www.openss7.org/
> 

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

---

From: "Ong, Lyndon" <[email-masked]>
Date: Wed, 6 Mar 2002 10:08:31 -0800

Folks,

Just clarification, M3UA and M2UA have already been
approved by IESG, so any clarifications we are talking
about should be in a separate draft, e.g., an
implementor's guide.

Cheers,

L. Ong

-----Original Message-----
From: Vats, Umesh [mailto:[email-masked]]
Sent: Wednesday, March 06, 2002 9:54 AM
To: [email-masked]'; Nitin Vairagare
Cc: Sigtran (E-mail)
Subject: RE: [Sigtran] ASP Identifier

Hi  Brian

Umesh 

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: Wednesday, March 06, 2002 9:33 AM
To: Nitin Vairagare
Cc: Goel, Soni; 'Tolga Asveren'; Sigtran (E-mail)
Subject: Re: [Sigtran] ASP Identifier

Nitin,

--brian

Mar
4.3.4.5
to
to
AS1,
is
in
parameter
Context
not
AS1,
then

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

---

From: "Vats, Umesh" <[email-masked]>
Date: Wed, 6 Mar 2002 11:50:10 -0800

Hi  Lyndon

I was thinking that M3UA RFC will be out only after
all the issues raised during latest M3UA bakeoff are
resolved. 

Isn't it possible to delay the RFC for incorporating
the results of latest bakeoff activity and mailing list 
discussions ?

If not, what's the procedure for incorporating future
modifications in the RFC.

Umesh

-----Original Message-----
From: Ong, Lyndon [mailto:[email-masked]]
Sent: Wednesday, March 06, 2002 10:09 AM
To: 'Vats, Umesh'; [email-masked]'; Nitin Vairagare
Cc: Sigtran (E-mail)
Subject: RE: [Sigtran] ASP Identifier

Folks,

Cheers,

L. Ong

-----Original Message-----
From: Vats, Umesh [mailto:[email-masked]]
Sent: Wednesday, March 06, 2002 9:54 AM
To: [email-masked]'; Nitin Vairagare
Cc: Sigtran (E-mail)
Subject: RE: [Sigtran] ASP Identifier

Hi  Brian

Umesh 

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: Wednesday, March 06, 2002 9:33 AM
To: Nitin Vairagare
Cc: Goel, Soni; 'Tolga Asveren'; Sigtran (E-mail)
Subject: Re: [Sigtran] ASP Identifier

Nitin,

--brian

Mar
4.3.4.5
to
to
AS1,
is
in
parameter
Context
not
AS1,
then

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

---

From: "Ong, Lyndon" <[email-masked]>
Date: Wed, 6 Mar 2002 12:33:21 -0800

Hi Nitin,

I was referring to the SCTP Implementors Guide as an
example.  SCTP discussions were moved to the TSV WG
some time ago, so you will find the link on the TSV
WG web page.

Cheers,

Lyndon

-----Original Message-----
From: Nitin Vairagare [mailto:[email-masked]]
Sent: Wednesday, March 06, 2002 12:22 PM
To: Ong, Lyndon; 'Vats, Umesh'
Cc: 'Sigtran (E-mail)'
Subject: RE: [Sigtran] ASP Identifier

But unfortunately Link to SCTP Implementors guide
is not made abvailable from IETF Sigtran homepage.
Link to RFC exist but there is no Link to Implementors
guide.

I wish we can make this available from the same page
so that any one that access Sigtran home page also
know the latest version of implementors guide.

Regards,
Nitin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Ong, Lyndon
Sent: Wednesday, March 06, 2002 2:56 PM
To: 'Vats, Umesh'
Cc: 'Sigtran (E-mail)'
Subject: RE: [Sigtran] ASP Identifier

Hi Umesh,

The situation is similar to SCTP, SCTP came out as
an RFC with Proposed Standard status.  Bakeoffs
continued to be held and corrections/clarifications
have been incorporated into a separate Implementors
Guide draft.  At some point we will want to move
SCTP from Proposed Standard to Draft Standard, at
which point these corrections/clarifications can be
incorporated into the main specification or the
Implementors Guide will be marked as supplementing
the original RFC.

Cheers,

Lyndon

-----Original Message-----
From: Vats, Umesh [mailto:[email-masked]]
Sent: Wednesday, March 06, 2002 11:50 AM
To: Ong, Lyndon
Cc: 'Sigtran (E-mail)'
Subject: RE: [Sigtran] ASP Identifier

Hi  Lyndon

Umesh

-----Original Message-----
From: Ong, Lyndon [mailto:[email-masked]]
Sent: Wednesday, March 06, 2002 10:09 AM
To: 'Vats, Umesh'; [email-masked]'; Nitin Vairagare
Cc: Sigtran (E-mail)
Subject: RE: [Sigtran] ASP Identifier

Folks,

Cheers,

L. Ong

-----Original Message-----
From: Vats, Umesh [mailto:[email-masked]]
Sent: Wednesday, March 06, 2002 9:54 AM
To: [email-masked]'; Nitin Vairagare
Cc: Sigtran (E-mail)
Subject: RE: [Sigtran] ASP Identifier

Hi  Brian

Umesh

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: Wednesday, March 06, 2002 9:33 AM
To: Nitin Vairagare
Cc: Goel, Soni; 'Tolga Asveren'; Sigtran (E-mail)
Subject: Re: [Sigtran] ASP Identifier

Nitin,

--brian

Mar
4.3.4.5
to
to
AS1,
is
in
parameter
Context
not
AS1,
then

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