Subject: Re: [Sigtran] m3ua-implementors-guidev00, OPC list + missing issues

From: Ken Morneault <[email-masked]>
Date: Thu, 04 Apr 2002 17:07:08 -0500

Tolga,

Pls see below.

Ken

At 12:35 PM 3/31/2002 -0800, Tolga Asveren wrote:
>Javier and Ken,
>
>After discovering that there is a link now for m3ua
>implementors guide on SIGTRAN page, here are some
>comments:
>
>1- I couldn't understand, why it is not clear to have
>an OPC list in the Registeration Reuqest, and what
>does this has to do with alias point codes. Previous
>text was pretty clear to me.
>
>2- AS state machine change for n+k case is not
>addresses, on intention or just forgotten?

Sorry, must have missed this one.  Was a 
consensus reached?  If so, could you please
summarize the issue and conclusion so that
it can be placed into the imp guide.

Otherwise, I'll add it to the list of open issues
(which I hope to post soon).

>3- For SSNM with multiple Affected Point Code fields
>and with multiple RC fields, it should be described,
>how to correlate RC values to the Affected Point
>Codes.

Ok.  this will have to be added to the list of 
open issues.

>  Tolga
>
>__________________________________________________
>Do You Yahoo!?
>Yahoo! Greetings - send holiday greetings for Easter, Passover
>http://greetings.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: Thu, 4 Apr 2002 19:37:29 -0500

Ken,

Please see below.

  Tolga

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Ken Morneault
> Sent: Thursday, April 04, 2002 5:07 PM
> To: Tolga Asveren; [email-masked]
> Subject: Re: [Sigtran] m3ua-implementors-guidev00, OPC list + missing
> issues
>
>
>
>
> Tolga,
>
> Pls see below.
>
> Ken
>
[TOLGA] I really don't understand, why OPC list is only valid in case of
Alias Point Code configuration. I think the original question was, why
multiple DPCs are allowed in the REGREQ, not OPCs (or maybe I remember
wrong)
> it can be placed into the imp guide.
[TOLGA] Nowadays it is hard to decide whether a consensus is reached or not
in SIGTRAN list. But if no answer means no objection then I think we can
assume there is a consensus. So, I will post a text for this issue to the
list.

---

From: "Tolga Asveren" <[email-masked]>
Date: Mon, 8 Apr 2002 12:02:09 -0400

Another issue related with n+k redundancy, if n is interpreted as
"required", I think there should be a way to tell in the traffic mode
parameter, what is the value of n.

   Tolga

> Tolga Asveren
> Sent: Monday, April 08, 2002 11:57 AM
> To: [email-masked]
> Subject: RE: [Sigtran] m3ua-implementors-guidev00 n+k traffic mode
>
>
> Here are some ideas about n+k traffic mode issue:
>
> The source of the problem is, how n should be interpreted in n+k case. It
> seems the initial idea was, 1 ACTIVE ASP is always enough and n shows the
> preferred number of ACTIVE ASPs. Then there was a shift to the opinion, to
> interprete n as the required number of ACTIVe ASPs. Currently there are
> conflicting statements in the draft about this issue.
>
> I don't know whether there is an agreement , but I favor the
> approach where
> n is interpreted as the required number of ACTIVE ASPs to consider AS in
> ACTIVE state. In my opinion, the main argument for this is, if we think 1
> ACTIVE ASP always enough to consider AS as ACTIVE, there is no need to
> define something special in the protocol to cover n+k redundancy case. How
> many ACTIVE ASPs are preferred depends totally on the SGP in such
> a case. In
> fact, maybe this also could be an option, to delete everyhting
> related with
> n+k redundacy from the draft (ecxept NTFY("Insufficient ASPs are active in
> AS", which will have the meaning "I want more ASPs ACTIVE for this AS" )
>
> Now, necessary changes to interprete n as the required number of ACTIVE
> ASPs(no guarantee that thi sis the full list)
>
> 1) Figure  5 :AS State Transition Diagram
>
> New Figure 5:
>
>                  Figure 5: AS State Transition Diagram
>
>                    one ASP trans to ACTIVE
>                    causing number of ACTIVE ASPs
>      +----------+  to be n                    +-------------+
>      |    AS-   |---------------------------->|     AS-     |
>      | INACTIVE |                             |   ACTIVE    |
>      |          |<---                         |             |
>      +----------+    \                        +-------------+
>         ^   |         \ Tr Expiry,                ^    |
>         |   |          \ at least one             |    |
>         |   |           \ ASP in ASP-INACTIVE     |    |
>         |   |            \                        |    |
>         |   |             \                       |    |
>         |   |              \                      |    |
> one ASP |   | all ASP       \           one ASP   |    | one ACTIVE
> trans   |   | trans to       \          trans to  |    | ASP trans to
> to      |   | ASP-DOWN        -------\   ASP-     |    | ASP-INACTIVE
> ASP-    |   |                         \  ACTIVE   |    | or
> ASP-DOWN causing
> INACTIVE|   |                    causing number   |    | number of ACTIVE
> ASPs
>         |   |                    of ACTIVE ASPs   |    | drop below n
>         |   |                    to be n \        |    |  (start Tr)
>         |   v                             \       |    v
>      +----------+                          \  +-------------+
>      |          |                           --|             |
>      | AS-DOWN  |                             | AS-PENDING  |
>      |          |                             |  (queueing) |
>      |          |<----------------------------|             |
>      +----------+    Tr Expiry and no ASP     +-------------+
>                      in ASP-INACTIVE state)
>
>     Tr = Recovery Timer
>
>
> I didn't touch transitions to AS-DOWN and AS-INACTIVE state. I am
> not sure,
> whether also for those states we should care about n or not (for
> example if
> n-1 ASPs are in INACTIVE state and 1 ASP is in DOWN state, is AS DOWN or
> INACTIVE in n+k redundancy case?)
>
>
>
> 2)4.3.4.3 ASP Active Procedures
>
> Old Text:
> An SGP or IPSP, upon reception of an ASP Active message for the first
> ASP in a Loadshare AS, MAY choose not to 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.
>
> New Text:
> An SGP or IPSP, upon reception of an ASP Active message for the first
> ASP in a Loadshare AS, MUST 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.
>
>
>
>
>
>
>
>
>
> Old Text:
> 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.
>
>
> New Text:
> 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 MUST not start
> sending traffic related with that AS, unless n ASPs are active for it.
>
>
>
>
>
>
> As I said above, another alternative is to get rid of n+k redundancy, to
> consider any AS in ACTIVE state when there is one ASP ACTIVE for it. This
> just will require some sentences to be deleted from the draft and
> interpretating NTFY("Insufficient ASP resources active in AS") in a
> different way.
>
>    Tolga
>
>
>
>
>
>
>

---

From: "Tolga Asveren" <[email-masked]>
Date: Mon, 8 Apr 2002 11:56:37 -0400

I don't know whether there is an agreement , but I favor the approach where
n is interpreted as the required number of ACTIVE ASPs to consider AS in
ACTIVE state. In my opinion, the main argument for this is, if we think 1
ACTIVE ASP always enough to consider AS as ACTIVE, there is no need to
define something special in the protocol to cover n+k redundancy case. How
many ACTIVE ASPs are preferred depends totally on the SGP in such a case. In
fact, maybe this also could be an option, to delete everyhting related with
n+k redundacy from the draft (ecxept NTFY("Insufficient ASPs are active in
AS", which will have the meaning "I want more ASPs ACTIVE for this AS" )

New Figure 5:

                   one ASP trans to ACTIVE
ASP-    |   |                         \  ACTIVE   |    | or ASP-DOWN causing

    Tr = Recovery Timer

I didn't touch transitions to AS-DOWN and AS-INACTIVE state. I am not sure,
whether also for those states we should care about n or not (for example if
n-1 ASPs are in INACTIVE state and 1 ASP is in DOWN state, is AS DOWN or
INACTIVE in n+k redundancy case?)

Old Text:

New Text:

Old Text:

New Text:

   Tolga