Subject: Re: [Sigtran] M3UA : Multiple SGPs in SG

From: [email-masked]
Date: Fri, 6 Jun 2003 20:59:14 +0530

Hi Tolga,

 RFC does not say any thing about n+k redundancy as you have pointed out in
your first response. I am
 attaching the lines from RFC from section 4.3.4.3 ASP Active Procedures:
"For the n+k redundancy case, ASPs which are in that AS should
 coordinate among themselves the number of active ASPs in the AS, and
 should start sending traffic only after n ASPs are active.

 All ASPs within a loadsharing mode AS must be able to process any
 Data message received for the AS, to accommodate any potential
 failover or rebalancing of the offered load."

So if there is any interopability problem as you have indicated by keeping
the RFC open ended then it should         be addressed in the
implementation guide.I still believe that it is an implementation issue and
can be resolved by configuring each AS and SG nodes in one of the two ways
of n+k redundancy scope i.e specific to SG or SGP.

Regards
Kamesh

Tolga Asveren <[email-masked]>@ietf.org on 06/06/2003 04:35:03 PM

Sent by:    [email-masked]

To:    [email-masked]
cc:

Subject:    Re: [Sigtran] M3UA : Multiple SGPs in SG

Hi Kamesh,

If we have to types of SGs (one, which activates
traffic based on number of ACTIVE ASPs per SGP and the
other per SG), ASPs can't decide -at least based on
the current RFC- when to start/accept traffic. What
ASPs are supposed to do is coordinating number of
ACTIVE ASPs among the cluster, but if they don't know,
whether the SG is deciding based on per SGP counter or
not, there will be interoperability problems (for
example SG uses a global ACTIVE ASP counter and starts
traffic but ASPs are counting per SGP, they probably
will drop arriving DATA).

    Tolga
--- [email-masked] wrote:
>
>
>
>
> Hi Tolga,
>                     I am of the openion that scope
> of n+k redundancy should
> depend on how one views and implements an SG. In
> figure given below if an
> implementation wants to reroute some AS traffic to
> its adjacent SGP on its
> way to AS it should be allowed.BTW as you have also
> agreed that ASP1 and
> ASP2 also qualifies as two ASP's of AS if SGP1 and
> SGP2 has active
> associations with ASP1 and ASP2 respectively.SGP may
> not want to block the
> traffic for AS if association between SGP1 and ASP2
> is not active for AS
> assuming n = 2, k = 0(for n+k redundancy). I am not
> able to understand what
> interopability issue will be involved in it.No doubt
> limiting scope of n+k
> redundancy to SGP is clear and simple but some
> implementations may want to
> use inter SGP routing to route there traffic to AS.
> So it ultimately
> depends on how you want your SG implementation to
> behave.
>
>
>                       SG
>                   +--------------+            AS
>                   |              |
> +---------+--+
>                   |              |        |
>   |
>                   | +--------+   |
> |+--------+  |
>                   | |        |   |        ||
> |  |
>                   | |  SGP1  *---+--------++ ASP1
> |  |
>                   | +--------+\  |
> |+--------+  |
>                   |    |         \        |
>   |
>   inter SGP  -----+----+         |        |
>   |
>   routing         |    |         |   \    |
>   |
>                   | +--------+   |     \
> |+--------+  |
>                   | |        |   |       \||
> |  |
>                   | | SGP2   +---+------ -*+  ASP2
> |  |
>                   | +--------+   |
> |+--------+  |
>                   |              |        |
>   |
>                   +--------------+
> +------------+
>
> Regards
> Kamesh
> Hughes Software Systems
>
>
>
>
> Tolga Asveren <[email-masked]>@ietf.org on
> 06/05/2003 07:40:28 PM
>
> Sent by:    [email-masked]
>
>
> To:    [email-masked]
> cc:
>
> Subject:    Re: [Sigtran] M3UA : Multiple SGPs in SG
>
>
> Hi Kamesh,
>
> IMO, it is a fair assumption for most of the cases
> that processing power for SG-side hosts is higher
> than
> of a single ASP (of course, still a configuration
> issue)
>
> For loadsharing on SG-side, for incoming traffic
> from
> SS7 there is already loadsharing among links, and
> links are residing on different hosts. So, I would
> think incoming traffic will be more or less evenly
> distributed among different hosts (and probably you
> will first try the local SGP on that host to route
> the
> traffic to ASPs, but still implementation
> dependent).
>
>    Tolga
> --- [email-masked] wrote:
> >
> >
> >
> >
> > Hi Tolga,
> >                      I want to clarify one more
> > point that in n+k
> > redundancy mode we are saying that n ASP's should
> be
> > active in SGP for the
> > AS to handle AS traffic, but can you tell me are
> we
> > assuming that SGP
> > handling entire traffic of AS is an high
> processing
> > machine with
> > processing power of 3 ASP's.I think it is slightly
> > unfair on SGP. We can
> > also distribute traffic for AS among SGP's of SG
> > which has active
> > associations with three ASP's and allow
> > implementations to load share
> > traffic of AS not only among ASP's (of AS) but
> > within SGP's of SG too.
> >
> > Regards
> > Kamesh
> >
> >
> >
> >
> > Tolga Asveren <[email-masked]>@ietf.org
> on
> > 06/05/2003 05:53:51 PM
> >
> > Sent by:    [email-masked]
> >
> >
> > To:    [email-masked]
> > cc:
> >
> > Subject:    Re: [Sigtran] M3UA : Multiple SGPs in
> SG
> >
> >
> > Hi Kamesh,
> >
> >
> >              associations
> >     | | | |    | | | |      | | | |
> >    +---------+------------+-----------+
> >    |   SGP1  |   SGP2     |   SGP3    |
> >    ************************************
> >    *              MTP3                *
> >    *         |            |           *
> >    * host1   |   host2    |  host3    *
> >    ************************************
> >      |   |       |     |       |    |
> >      |   |       |     |       |    |
> >                 Links
> >
> >
> > Basically adjacent SS7 node is just aware that
> there
> > is a MTP3 peer and some links to communicate with
> > it,
> > and will probably loadshare traffic based on SLS
> > betwen those links. Once the messages are inside
> the
> > SG-box, it is up to you, what to do with them (and
> I
> > would think although a lot of things inside SG are
> > implementation dependent, there is no direct
> mapping
> > between links and SGPs)
> >
> > BTW, like you have said, it really migt be
> possible
> > to
> > loadshare traffic between two ASPs, which are
> ACTIVE
> > for separate SGPs -and this also IMO would qualify
> > as
> > 2 ACTIVE ASPs because this is not two associations
> > to
> > the same ASP-, but I still think this might bring
> > interoperability problems. To decide, when to
> start
> > traffic, IMO ASP and SGP should work in harmony.
> So,
> > IMO it is a good choice to leave the peers as SGP
> > and
> > ASP for ASPTM procedures.
> >
> > I also checked a sentence related with this topic
> > -in
> > ASP Active Procedures- in RFC, there it stands
> that
>
=== message truncated ===

__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com
_______________________________________________
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: Tolga Asveren <[email-masked]>
Date: Fri, 6 Jun 2003 08:59:13 -0700 (PDT)

Hi Kamesh,

In IG 3.15 there are some changes/clarifications
related with n+k redundancy (those most probably will
be reworked but I think we still can rely on
INACTIVE->ACTIVE transition for AS state machine
there-)
In RFC3332 4.3.1 
"The state of each remote ASP, in each AS that it is
configured to operate, is maintained in the M3UA layer
in the SGP."
So, the AS state machine is kept in SGP -not SG wide-
and IG does not change this.

Now, IMO, what you tell -just while counting number of
ACTIVE ASPs for an AS acting SGwide but for the other
ASPTM procedures still keeping per SGP approach- is
not undoable, but not inline with current RFC/IG. 

IMO, cases, where this might be usefull will be
probably very rare (I think, it is not a very high
possibility that an association to an ASP1 can be
formed from SGP1 and can't be formed from SGP2 and for
ASP2 can be formed from SGP2 but can't be formed from
SGP1, if they are part of the same SG) and I would
think introducing a new configuration item for that is
probably not worth. 
Other opinions?

   Tolga 

--- [email-masked] wrote:
> 06/06/2003 04:35:03 PM

__________________________________
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Umesh Vats" <[email-masked]>
Date: Fri, 6 Jun 2003 09:31:45 -0700

Hi Tolga

The following text exists in implementor's guide.

                   "An SGP or IPSP, upon reception of an ASP Active message
for the first
                    ASP in a Loadshare AS, SHOULD NOT direct traffic to a
newly active
                    ASP until it determines that there are sufficient
resources to handle
                    the expected load (e.g., until there are "n" ASPs in
state ASP-ACTIVE
                    in the AS).  In this case, the SGP or IPSP SHOULD
withhold the Notify
                    (AS-ACTIVE) until there are sufficient resources."

On SG, n ASPs must be active for an AS to before an AS is made active. It
doesn't
matter whether they went ACTIVE from the same SGP or different SGPs.

Although the state of each remote ASP is maintained in the AS, the overall
AS is
visible to whole SG. The following statement in RFC 3332 helps :
 " Where an SG contains more than one SGP, the MTP3 routeset, SPMC and
   remote AS/ASP states of each SGP SHOULD be coordinated across all the
   SGPs.  Rerouting of traffic between the SGPs MAY also be supported."

Similarly for ASP to SG traffic, the SGP to which that ASP is connected
doesn't matter when
it has to decide about starting the traffic flow. All ASPs should coordinate
among themselves if n ASP are ACTIVE for an AS or not.

"For the n+k redundancy case, ASPs which are in that AS should
   coordinate among themselves the number of active ASPs in the AS, and
   should start sending traffic only after n ASPs are active."

rgds
Umesh

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Tolga Asveren
Sent: Friday, June 06, 2003 8:59 AM
To: [email-masked]
Subject: Re: [Sigtran] M3UA : Multiple SGPs in SG

Hi Kamesh,

   Tolga

---

From: Tolga Asveren <[email-masked]>
Date: Fri, 6 Jun 2003 09:46:09 -0700 (PDT)

Hi Umesh,
>    SGPs.  Rerouting of traffic between the SGPs MAY
[TOLGA]This is the place I think a bit different.
Please note the "MAY" in the last sentence. I think it
was agreed not to use  a "SHOULD" here to not force
internal routing. (BTW, I think even the "SHOULD" in
the first sentence should be changed to "MAY")As I
said, basically counting number of ACTIVE ASPs per SG
will just introduce interoperability problems unless
some modifications are introduced to the IG and
considering that SGPs in a SG will most probably have
the same IP connectivity, this IMO is not very usefull
in real life. I personally would prefer the simple and
clear way of having all ASPTM procedures per SGP.(for
example do you like the idea of having ASPTM per SG
instead of SGP?)
> among themselves if n ASP are ACTIVE for an AS or
[TOLGA]If what you mean is, that it really does not
matter for which SGP ASPs went ACTIVE, I disagree, at
least SG, SGP is part of should matter. Apart from
this, although the sentence might be not very clear in
the context of this discussion, the intention was to
coordinate number of ACTIVE ASPs for each SGP
separetly. Maybe a clarification might be added to IG.
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of
> Tolga Asveren
> >  RFC does not say any thing about n+k redundancy
> as
> > you have pointed out in
> > "For the n+k redundancy case, ASPs which are in
> that
> > AS should
> >  should start sending traffic only after n ASPs
> are
> > active.
> >
> >  All ASPs within a loadsharing mode AS must be
> able
> > to process any
> > can be resolved by configuring each AS and SG
> nodes
> > in one of the two ways
> > whether the SG is deciding based on per SGP
> counter
> > or

---

From: "Umesh Vats" <[email-masked]>
Date: Fri, 6 Jun 2003 10:24:15 -0700

Hi Tolga

But internal routing between SGPs must be supported
if want to take care of message loss/message missequencing
when the associations between ASPs/SGPs go down or come
up.

Many other procedures in the RFC require internal communication
between ASPs and SGPs.

So in my opinion, the MAY in last sentence should be modified to SHOULD.

" Where an SG contains more than one SGP, the MTP3
> routeset, SPMC and

In reference to your statement :
"I personally would prefer the simple and
clear way of having all ASPTM procedures per SGP.(for
example do you like the idea of having ASPTM per SG
instead of SGP?)"

Having ASPTM on SG basis is someting we can explore. But it would be really
helpful if instead of SGPs, we have concept of just one physical SG with
capabilityof representing multile endpoints through configuration, each
representing
logical SGP. This will take care of all internal communication problems.
For higher fault tolerance and thorughput, one can duplicate the SG onto
several hosts using current fault tolerance and high availability
technologies
already being used in SS7 switches.

Umesh

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Tolga Asveren
Sent: Friday, June 06, 2003 9:46 AM
To: [email-masked]
Subject: RE: [Sigtran] M3UA : Multiple SGPs in SG

Hi Umesh,
> are active."

---

From: Tolga Asveren <[email-masked]>
Date: Fri, 6 Jun 2003 10:55:21 -0700 (PDT)

Hi Umesh,
> when the associations between ASPs/SGPs go down or
[TOLGA]As far as I remember, some methods were
presented, which will work withoud a need of internal
routing -unfortunately I don't remember the details-,
because this discussion about "SHOULD" v.s. "MAY" has
happened some time ago.
> >    SGPs.  Rerouting of traffic between the SGPs
> MAY
> > also be supported."
> 
[TOLGA]Apart from any technical
advantages/disadvantages, I think this would be a big
change considering the status of M3UA specifications.
BTW, to make use of the existing mechanims including
network management procedures, you might have a look
to the SGSG draft.
> > On SG, n ASPs must be active for an AS to before
> an
> > AS is made active. It
> > doesn't
> > matter whether they went ACTIVE from the same SGP
> or
> > different SGPs.
> >
> > Although the state of each remote ASP is
> maintained
> > in the AS, the overall
> > AS is
> > visible to whole SG. The following statement in
> RFC
> > 3332 helps :
> >    SGPs.  Rerouting of traffic between the SGPs
> MAY
> > also be supported."
> >    coordinate among themselves the number of
> active
> > ASPs in the AS, and
> > Now, IMO, what you tell -just while counting
> number
> > of

---

From: "Umesh Vats" <[email-masked]>
Date: Fri, 6 Jun 2003 12:43:58 -0700

Overall it looks, its dependent on the specific architecture how
they interpret the concepts of AS/SG/SGP and traffic modes.
Different people have different understanding.

In many architectures, its really helpful to have ASP-ASP and SGP-SGP
communication to take care of lot of issues :
1. Message missequencing
2. Message loss
3. Visibility of same AS and AS-status/ASP-status/SGP-status on all 
   SGPs and ASPs.
4. Avoiding the need for establishment of redundant associations
   between SG and ASPs. This is by assuming n+k redundancy mode
   on SG basis instead of SGP basis.

Umesh 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Tolga Asveren
Sent: Friday, June 06, 2003 10:55 AM
To: [email-masked]
Subject: RE: [Sigtran] M3UA : Multiple SGPs in SG

Hi Umesh,

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 6 Jun 2003 13:50:37 -0600

Tolga,

This IG is wrong on this point from our last long
discussion.

Please correcct it.

--brian

Tolga Asveren wrote:                                                                 (Fri, 06 Jun 2003 08:59:13)

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 6 Jun 2003 13:51:12 -0600

Tolga,

There was no such agreement.

--brian

Tolga Asveren wrote:                                                                 (Fri, 06 Jun 2003 09:46:09)

---

From: Tolga Asveren <[email-masked]>
Date: Fri, 6 Jun 2003 13:06:08 -0700 (PDT)

Brian,
--- "Brian F. G. Bidulock" <[email-masked]>
> There was no such agreement.
[TOLGA]If so, why is it a "MAY" in RFC?
> Tolga Asveren wrote:                                
>                                 (Fri, 06 Jun 2003
> 09:46:09)
> > >                    "An SGP or IPSP, upon
> reception
> > > of an ASP Active message
> > >                     ASP in a Loadshare AS,
> SHOULD
> > > NOT direct traffic to a
> > >                     the expected load (e.g.,
> until
> > > there are "n" ASPs in
> > >                     in the AS).  In this case,
> the
> > > SGP or IPSP SHOULD
> > > withhold the Notify
> > > matter whether they went ACTIVE from the same
> SGP or
> > > different SGPs.
> > > 
> > > Similarly for ASP to SG traffic, the SGP to
> which
> > > that ASP is connected
> > > doesn't matter when
> > > it has to decide about starting the traffic
> flow.
> > > All ASPs should coordinate
> > > among themselves if n ASP are ACTIVE for an AS
> or
> > > not.
> > > formed from SGP1 and can't be formed from SGP2
> and
> > > for
> > > think introducing a new configuration item for
> that
> > > is
> > > probably not worth.
> > > Other opinions?
> > > 
> > >    Tolga
> > > 
> > > >  attaching the lines from RFC from section
> 4.3.4.3
> > > > ASP Active Procedures:
>

---

From: Tolga Asveren <[email-masked]>
Date: Fri, 6 Jun 2003 13:07:47 -0700 (PDT)

Brian,

To my understanding, there was no consensus to change
the current INACTIVE to ACTIVE transition in IG for
n+k case.

    Tolga
wrote:
> 08:59:13)
> number of
> that is
> > >  Data message received for the AS, to
> accommodate
> > > any potential
> > > implementation guide.I still believe that it is
> an
> > > implementation issue and
> > > traffic based on number of ACTIVE ASPs per SGP
> and
> > > the
> > > > associations with ASP1 and ASP2
> respectively.SGP
> > > may
> > > > not want to block the
> > > > assuming n = 2, k = 0(for n+k redundancy). I
> am
> > > not
> > > > able to understand what
> > > > use inter SGP routing to route there traffic
> to
> > > AS.
> > > > So it ultimately
> AS

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 6 Jun 2003 14:28:27 -0600

Tolga,

Because the RFC represents the concensus and the
IG currently goes against concensus.  That section
of the IG thay you and Javier dreamed up needs to
be deleted.

--brian

Tolga Asveren wrote:                                                                 (Fri, 06 Jun 2003 13:06:08)

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 6 Jun 2003 14:29:14 -0600

Tolga,

There was concensus to let the RFC stand and remove
the section from the IG.

--brian

Tolga Asveren wrote:                                                                 (Fri, 06 Jun 2003 13:07:47)

---

From: Tolga Asveren <[email-masked]>
Date: Fri, 6 Jun 2003 13:40:16 -0700 (PDT)

Brian,

The "MAY" in the original message is the one about
internal forwarding of messages in SG.
"Rerouting of traffic between the SGPs MAY also be
supported."

And for INACTIVE to ACTIVE transition for n+k case, I
think different than you. The consensus was to change
ACTIVE to PENDING transition, at least to my
understanding.

   Tolga
wrote:
> 13:06:08)
> > >                                 (Fri, 06 Jun
> 2003
> > > > >                     ASP until it determines
> > > > > there are sufficient
> > > > >                     in the AS).  In this
> case,
> > > > >                     (AS-ACTIVE) until there
> > > > > sufficient resources."
> > > > >  " Where an SG contains more than one SGP,
> the
> > > MTP3
> > > > > routeset, SPMC and
> > > > >    remote AS/ASP states of each SGP SHOULD
> be
> > > > > coordinated across all the
> > > > internal routing. (BTW, I think even the
> "SHOULD"
> > > in
> > > > said, basically counting number of ACTIVE ASPs
> per
> > > SG
> > > > considering that SGPs in a SG will most
> probably
> > > have
> > > > in real life. I personally would prefer the
> simple
> > > and
> > > > example do you like the idea of having ASPTM
> per
> > > SG
> > > > instead of SGP?)
> > > > > 
> > > > [TOLGA]If what you mean is, that it really
> does
> > > not
> > > > matter for which SGP ASPs went ACTIVE, I
> disagree,
> > > at
> > > > the context of this discussion, the intention
> was
> > > to
> > > > separetly. Maybe a clarification might be
> added to
> > > IG.
> > > > > 
> > > > > related with n+k redundancy (those most
> probably
> > > > > will
> > > > > "The state of each remote ASP, in each AS
> that
> > > it is
> > > > > configured to operate, is maintained in the
> M3UA
> > > > > layer
> > > > > in the SGP."
>

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 6 Jun 2003 15:07:44 -0600

Tolga,

Go back and read the threads.

IIRC you claimed that there would be some
"interoperability" problem from following
the RFC, but did not point out what that
problem might be.

Could you explain now?

--brian

Tolga Asveren wrote:                                                                 (Fri, 06 Jun 2003 13:40:16)

---

From: Tolga Asveren <[email-masked]>
Date: Fri, 6 Jun 2003 14:17:57 -0700 (PDT)

Brian,
> the RFC, but did not point out what that
[TOLGA]What I did say was, for n+k case -if it is
allowed to use n per SG or per SGP-, if SG uses SGwide
number of ACTIVE ASPs and ASPs use the per SGP
counter, there will be an inconsistency between SGPs
and ASPs, when to start routing DATA to/from ASP.
> 13:40:16)
> > > > > > > The following text exists in
> implementor's
> > > > > guide.
> > > > > > > 
> > > > > > >                    "An SGP or IPSP, upon
> > > > > reception
> > > > > > > of an ASP Active message
> > > > > > > for the first
> > > > > > >                     ASP in a Loadshare
> AS,
> > > > > SHOULD
> > > > > > > NOT direct traffic to a
> > > > > > > newly active
> > > > > > >                     ASP until it
> determines
> > > that
> > > > > > > there are sufficient
> > > > > > > resources to handle
> > > > > > >                     the expected load
> (e.g.,
> > > > > until
> > > > > > > there are "n" ASPs in
> > > > > > > state ASP-ACTIVE
> > > > > > >                     in the AS).  In this
> > > case,
> > > > > the
> > > > > > > SGP or IPSP SHOULD
> > > > > > > withhold the Notify
> > > > > > >                     (AS-ACTIVE) until
> there
> > > are
> > > > > > > sufficient resources."
> > > > > > > 
> > > > > > > On SG, n ASPs must be active for an AS
> to
> > > before
> > > > > an
> > > > > > > AS is made active. It
> > > > > > > doesn't
> > > > > > > visible to whole SG. The following
> statement
> > > in
> > > > > RFC
> > > > > > > 3332 helps :
> > > > > > >    SGPs.  Rerouting of traffic between
> the
> > > SGPs
> > > > > MAY
> > > > > > > also be supported."
> > > > > > Please note the "MAY" in the last
> sentence. I
> > > > > think it
> > > > > > was agreed not to use  a "SHOULD" here to
> not
> > > > > force
> > > > > > will just introduce interoperability
> problems
> > > > > unless
> > > > > > some modifications are introduced to the
> IG
> > > and
> > > > > > the same IP connectivity, this IMO is not
> very
> > > > > usefull
> > > > > > clear way of having all ASPTM procedures
> per
> > > > > SGP.(for
> > > > > > > among themselves if n ASP are ACTIVE for
> an
> > > AS
> > > > > or
> > > > > > > not.
> > > > > > least SG, SGP is part of should matter.
> Apart
>

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 6 Jun 2003 15:44:51 -0600

Tolga,

What inconsistency?  What bad thing will happen?

--brian

Tolga Asveren wrote:                                                                 (Fri, 06 Jun 2003 14:17:57)

---

From: Tolga Asveren <[email-masked]>
Date: Fri, 6 Jun 2003 14:59:37 -0700 (PDT)

Brian,
> What inconsistency?  What bad thing will happen?
[TOLGA](We had this discussion before I think, so I
will just briefly summarize my opinion)
When AS is seen as ACTIVE, SG will expose this to SS7
network (directly with a TFA or indirectly by not
sending UPU). This might cause  some nodes in SS7
network to initiate traffic to the AS. But ASPs most
probably will drop arriving DATA, because they don't
see AS as ACTIVE.
If this is not seen as a problem, then routing DATA to
an INACTIVE ASP (n=1 case) should be also allowed.
> 14:17:57)
> > > > > of the IG thay you and Javier dreamed up
> needs
> > > to
> > > > > be deleted.
> > > > > 
> > > > > --brian
> > > > > 
> > > > > 
> > > > > Tolga Asveren wrote:                        
>    
> > >    
> > > > >                                 (Fri, 06 Jun
> > > 2003
> > > > > 13:06:08)
> > > > > > Brian,
> > > > > > >                                 (Fri, 06
> Jun
> > > > > > > > >                    "An SGP or IPSP,
> upon
> > > > > > > > >                     ASP in a
> Loadshare
> > > > > > > > >                     the expected
> load
> > > > > > > > >                     in the AS).  In
> this
> > > > > > > > >                     (AS-ACTIVE)
> > > > > > > > > matter whether they went ACTIVE from
> the
> > > > > same
> > > > > > > SGP or
> > > > > > > > > different SGPs.
> > > > > > > > > 
> > > > > > > > >  " Where an SG contains more than
> one
> > > SGP,
> > > > > the
> > > > > > > MTP3
> > > > > > > > > routeset, SPMC and
> > > > > > > > the first sentence should be changed
> to
> > > > > "MAY")As I
> > > > > > > > said, basically counting number of
> ACTIVE
> > > ASPs
> > > > > per
> > > > > > > SG

---

From: "Umesh Vats" <[email-masked]>
Date: Fri, 6 Jun 2003 15:03:17 -0700

[UMESH] This shouldn't happen.
All ASPs serving an AS can also use n as SG wide
value through inter communication between them. Following statement
in RFC says this. 

Umesh

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Tolga Asveren
Sent: Friday, June 06, 2003 2:18 PM
To: [email-masked]
Subject: Re: [Sigtran] M3UA : Multiple SGPs in SG

Brian,

---

From: Tolga Asveren <[email-masked]>
Date: Fri, 6 Jun 2003 15:10:26 -0700 (PDT)

Umesh,

1)Then think just the opposite, ASPs use SG wide
number and SG uses counter per SGP. This time ASP
sends DATA and SGPs will drop it.

2)The sentence you are referring was intended for
counting number of ACTIVE ASPs per SGP. But I agree,
it is not clear(it also does not speak about counter
per SG, so if you take the sentence literally, should
ASPs consider AS ACTIVE, if activations are done on
SGPs belonging to different SGs? SGs won't see AS as
ACTIVE in such a case)

     Tolga

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 6 Jun 2003 16:17:17 -0600

Tolga,

Tolga Asveren wrote:                                                                 (Fri, 06 Jun 2003 15:10:26)
> sends DATA and SGPs will drop it.

Why?  Where does it way that the SGP must drop a message
received from the ASPs?  Why are you dropping it?

--brian

---

From: "Umesh Vats" <[email-masked]>
Date: Fri, 6 Jun 2003 15:24:59 -0700

Hi Tolga

What I mean is that both, the SG and the ASPs serving an AS for that SG
should use same value of n.  

Like in SS7 network, two adjacent pointcodes configure that link set
should be active only if n links in it are active. The same n value is
valid for both the adjacent point code.

Umesh

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Tolga Asveren
Sent: Friday, June 06, 2003 3:10 PM
To: [email-masked]
Subject: RE: [Sigtran] M3UA : Multiple SGPs in SG

Umesh,

     Tolga

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 6 Jun 2003 16:28:21 -0600

Umesh,

The SS7 network does not behave as you describe.  There is no
value 'n' for links.

--brian

Umesh Vats wrote:                                                                    (Fri, 06 Jun 2003 15:24:59)

---

From: Tolga Asveren <[email-masked]>
Date: Fri, 6 Jun 2003 15:32:03 -0700 (PDT)

Brian,
wrote:
> 15:10:26)
[TOLGA]"1.4.2.5 Message Distribution at ASP" and
"4.3.4.3 ASP Active Procedures" are written
unfortunately just by thinking n=1 case(so they speak
of ASP being ACTIVE instead of AS). After looking now,
I think some rewording at those places is also
necessary. To me, it is clear that if SGP sees AS as
INACTIVE that it should drop incoming DATA from this
AS. 
> > > > > "Rerouting of traffic between the SGPs MAY
> also
> > > be
> > > > > supported."
> > > > > 
> > > > > And for INACTIVE to ACTIVE transition for
> n+k
> > > > case, I
> > > > > think different than you. The consensus was
> to
> > > > change
> > > > > > Because the RFC represents the concensus
> and
> > > the
> > > > > > > >                                 (Fri,
> 06
> > > > > > > > > >                    "An SGP or
> IPSP,

---

From: Tolga Asveren <[email-masked]>
Date: Fri, 6 Jun 2003 15:47:29 -0700 (PDT)

Hi Umesh,
> should use same value of n.  
[TOLGA]If both sides are using the same scheme, of
course there wouldn't be an inconsistancy. But IMO,
till now the assumption was always to use number of
ACTIVE ASPs per SGP. Using the number per SG, would
put a requirement on the internal design of SG
(internal routing -yes, I agree it is a good to have
feature-) and probably it is better to avoid this.
Afterall, IMO the benefits using n as a counter per SG
are not too much for a real life scenario(maybe just
decreasing number of necessary associations for some
configurations as you pointed out)

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 6 Jun 2003 17:18:42 -0600

Tolga,

Tolga Asveren wrote:                                                                 (Fri, 06 Jun 2003 15:32:03)
> INACTIVE that it should drop incoming DATA from this

These sections do not say that an SGP should drop a
message from an ACTIVE ASP.

Why do you drop it?

--brian

---

From: Tolga Asveren <[email-masked]>
Date: Tue, 10 Jun 2003 08:54:26 -0700 (PDT)

Brian,
wrote:
> 15:32:03)
[TOLGA]Yes. But as indicated in the original message,
IMO, messages from INACTIVE AS (rather than INACTIVE
ASP) should be dropped.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 10 Jun 2003 13:25:00 -0600

Tolga,

Tolga Asveren wrote:                                                                 (Tue, 10 Jun 2003 08:54:26)
> IMO, messages from INACTIVE AS (rather than INACTIVE

Why?

--brian

---

From: Tolga Asveren <[email-masked]>
Date: Tue, 10 Jun 2003 12:43:56 -0700 (PDT)

Brian,

[..snip..]
> > IMO, messages from INACTIVE AS (rather than
[TOLGA]Because IMO, the intention in those passages
should be not to route to/from INACTIVE AS, simply
just because it is INACTIVE.
From IG 3.15.2:
"AS-INACTIVE: The Application Server is available but
no application traffic is active. This implies that
there are at least n ASPs in either ASP-INACTIVE or
ASP-ACTIVE but the total number of ASPs in ASP-ACTIVE
state has not reach n.  The recovery timer T(r) is not

running or has expired.

AS-ACTIVE: The Application Server is available and
application traffic is active.  This state implies
that at least n ASPs are in the ASP-ACTIVE state." 

(The same explanation that during AS-ACTIVE
application traffic is active, whereas for AS-INACTIVE
not active is also present in RFC (but there number of
ASPs is mentioned just for n=1 case)

So, I would think, also based on the above statements,
when AS is INACTIVE, there shouldn't be application
traffic flow.