Subject: RE: RE: RE: [Sigtran] n+k redundancy + NTFY changes

From: [email-masked]
Date: Fri, 1 Feb 2002 16:26:49 -0800

Hi,

According to the message from Lyndon, which says that no big changes are
anymore desired, it seems changing use of NTFY is not possible. So I
propose following changes related with n+k redundancy and NTFY.

For M3UA:
========
1)
4.3.4.3 ASP Active Procedures
.........(Probably putting the following line to after the paragraphs,
which describe loadshare and broadcast mode operation will help)
For n+k redundancy case, ASPs, which are in that AS, should coordinate
among themselves number of active ASPs for this AS, and should start
sending traffic only after n ASPs are active.
..........

4.3.4.4. ASP Inactive Procedures
(Again after the paragraphs for loadshare/broadcast mode)
For n+k redundancy case, ASPs, which are in that AS, should coordinate
among themselves number of active ASPs for this AS, and should stop sending
traffic, if less than n ASPs are active

2) I still think it might be usefull to explain , what is meant with "ASP's
in an AS" for 4.3.4.5 Notify Procedures. But I withdraw the request to add
the sentence "An exception of this is that NTFY(Alternate ASP Active)
messages should be sent only to the ASP, which was previously ACTIVE for
this AS. .........", because 4.3.4.5 already says that only NTFYs , which
indicate state change of AS should be sent to all ASPs. NTFY(Alternate ASP
Active) does not indicate state change of AS and in fact 4.3.4.3 ASP Active
Procedures already says "The SGP or IPSP then MUST send a Notify
message("Alternate ASP Active") to the previously active ASP in the AS, and
SHOULD stop traffic to/from that ASP."

For M3UA:
========

1) Change 1) in M3UA also applies to SUA.

2) If possible I still would like to see double ASPUP scenarios in "5.2.
IPSP examples"

I don't think the above proposals are significant changes neither to M3UA
not to SUA. For n+k redundancy, we just define in detail, what is the
responsibility of ASPs working together and the rest is editorial.

     Tolga

> -----Original Message-----
> From:   [email-masked]
> Sent:   Thursday, January 31, 2002 2:40 PM
> To:     [email-masked];[email-masked]
> Cc:
> Subject:     RE: RE: [Sigtran] n+k redundancy + NTFY  changes
>
>  Hi John L. ,
> Those issues were first discussed on "M3UA-10 Example 5.1.4" thread. I
> think they are applicable both for M3UA and SUA.
>       Tolga
> NTFY changes
> ===========
> There the first problem mentioned was that in M3UA10-5.1.4 on
> the examples
> NTFYs are not sent to all of the ASPs, where in "4.3.4.5
> Notify Procedures"
> it is said that NTFY should be sent to all of the ASPs in the
> AS, which are
> not in DOWN state. Afterwards, this also brought the
> concerns, whether all
> types of NTFY really should be sent to all ASPs in the AS,
> which are not in
> DOWN state, or not. I think first of all it could be nice to
> explain, what
> it means that "an ASP is in the AS". And also it should be
> enough to send
> NTFY(Alternate ASP Active) only to  the previously active ASP.
> My suggestion is : (applicable both for SUA and M3UA)
> "4.3.4.5 Notify Procedures
> A Notify message reflecting a change in the AS state MUST be
> sent to all
> ASPs in the AS -ASPs, which are configured on SG to serve
> this AS in case
> of static configuration and ASPs, which are registered on SG
> for this AS in
> case of dynamic registeration-, except those in the ASP-DOWN
> state, with
> appropriate Status Information and any ASP Identifier of the
> failed ASP. An
> exception of this is that NTFY(Alternate ASP Active) messages
> should be
> sent only to the ASP, which was previously ACTIVE for this
> AS. ........."
> Also in "5. Examples of M3UA Procedures" in M3UA11 and "5.
> Examples of SUA
> Procedures" in SUA11 on the examples where NTFY messages are sent, it
> should be mentioned whether static or dynamic configuration
> is used, to be
> able to decide, which ASPs are in the AS.
> Another small comment about SUA, in "5.2. IPSP examples" is
> it possible to
> include also examples about 2 ASP-UP case?
> n+k redundancy
> ===============
> Again this problem was first mentioned in M3UA10-5.1.4. thread but is
> applicable for SUA as well. When ASPAC-ACK is received by an
> ASP, how can
> it be sure that n ASPs are already active in case of n+k redundancy?
> Because SGP won't start sending/receiving traffic till n ASPs
> are active
> and so preferably ASP also shouldn't send traffic to SGP.
> This could be
> done my making use of NTFY(AS Active). ASP should not start
> sending traffic
> for an AS, unless it receives ASPAC-ACK and NTFY(AS active)
> for that AS.
> Another problem case related with this is, if number of
> active ASPs fall
> below n, how ASPs should behaeve. In this case SGP will stop sending
> traffic and NTFY(Insufficient ASP resources active in AS) can
> be used by
> active ASPs, to decide to stop traffic. Still their own ASP
> state will be
> active, but they will wait till they receive a  NTFY(As
> active) (a new ASP
> will become active and active ASP number will reach n so that
> SGP will send
> this NTFY). If we want n+k redundancy configuration, I think
> we should move
> to this direction. Another alternative is of course getting rid of n+k
> redundancy.
> > -----Original Message-----
> > From:   [email-masked]
> > Sent:   Thursday, January 31, 2002 12:53 PM
> > To:     [email-masked];[email-masked]
> > Cc:
> > Subject:     RE: [Sigtran] n+k redundancy + NTFY  changes
> >
> >  Hi Tolga,
> > First off, do you mean SUA or M3UA?
> > > Because I see that some -although minor- changes are
> discussed, I am
> > > wondering whether there will be also a change to make n+k
> > > case to work in a more reasonable way or are changes
> > necessary for this
> > > too  much for now?
> > Can you be more specific about what you would like to see?
> > > Also closely related with this, will there be a text
> change for NTFY
> > > expalining in detail when should it be sent and to which ASPs?
> > If you have text to suggest, it could be added.
> > John
> > _______________________________________________
> > Sigtran mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/sigtran
> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sigtran

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