Subject: RE: [Sigtran] m3ua: IG : n+k redundancy - AS state machine

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Thu, 27 Jun 2002 16:00:11 +0200

Tolga, 

See comments...

> -----Original Message-----
> From: Tolga Asveren [mailto:[email-masked]]
> Sent: Thursday, June 27, 2002 3:51 PM
> To: [email-masked]
> Subject: RE: [Sigtran] m3ua: IG : n+k redundancy - AS state machine
> 
> 
> Javier,
> 
> > -----Original Message-----
> > From: Javier Pastor-Balbas (ECE)
> > [mailto:[email-masked]]
> > Sent: Thursday, June 27, 2002 9:22 AM
> > To: 'Tolga Asveren'; [email-masked]
> > Subject: RE: [Sigtran] m3ua: IG : n+k redundancy - AS state machine
> >
> >
> > Tolga,
> >
> > Sorry, but I think I don't understand your explanation completely.
> >
> > If you follow the state machine I sent out and if you have 2
> > ASP-ACTIVEs and 1 ASP-INACTIVE and n=3, I think you are in
> > AS_INACTIVE state, aren't you?  :-/
> >
> > I mean, I agree with you in that case the correct  state will be
> > AS-INACTIVE, but I think that was already covered with the
> > transition from DOWN to INACTIVE (check the figure I sent):
> >
> >
> >
> >              Figure 5: AS State Transition Diagram
> >
> >
> >      +----------+ n ASPs are in ACTIVE state  +-------------+
> >      |    AS-   |---------------------------->|     AS-     |
> >      | INACTIVE |                             |   ACTIVE    |
> >      |          |<---                         |             |
> >      +----------+    \                        +-------------+
> >         ^   |         \          one ASP trans to ^    |
> >         |   |          \       ASP-ACTIVE causing |    | one ACTIVE
> >         |   |           \        number of ACTIVE |    | 
> ASP trans to
> >         |   |            \           ASPs to be n |    | 
> ASP-INACTIVE
> >         |   |             \                       |    | or ASP-DOWN
> >         |   |              \                      |    | causing
> > n ASPs  |   | one ASP       \                     |    | number of
> > are in  |   | trans to       \                    |    | ACTIVE ASPs
> > ASP-    |   | ASP-DOWN        -------\            |    | drop
> > INACTIVE|   |                         \           |    | (start Tr)
> > or ASP- |   |                          \          |    |
> > ACTIVE  |   |                           \         |    |
> > state   |   |                  Tr expiry \        |    |
> >         |   v          The ASPs needed to \       |    v
> >      +----------+       reach n ACTIVE are \  +-------------+
> >      |          |     still in ASP-INACTIVE --|             |
> >      | AS-DOWN  |                      state  | AS-PENDING  |
> >      |          |                             |  (queueing) |
> >      |          |<----------------------------|             |
> >      +----------+    Tr Expiry and the ASPs   +-------------+
> >                     needed to reach n ACTIVE
> >                    ASPs are in ASP-DOWN state
> >
> >
> > do you think it is not still covered? Any reword in there?
> [TOLGA] My proposal (nothing conceptually new, just rewording)
> AS-INACTIVE --> AS-ACTIVE: one ASP trans. to ACTIVE, causing number of
> ACTIVE ASPs to be n (IMO, saying n ASPs are in ACTIVE state 
> is too general)

Why? I think it says what it is in a very short way. It is also aligned with the transition from DOWN to INACTIVE...

> AS-ACTIVE --> AS-PENDING: one ACTIVE ASP trans. to INACTIVE 
> or DOWN, causing
> number of ACTIVE ASPs drop below n (just I added "below n")

Ok, there was a typo here.

> AS-PENDING --> AS-ACTIVE: IMO, current explanation is fine

> AS-PENDING --> AS-INACTIVE: Tr Expiry, n or more ASPs are in 
> INACTIVE or
> ACTIVE state

The main reason here is that the some of the ASPs that previously where in ASP ACTIVE are now in ASP INACTIVE and in time Tr they didn't recover to ASP ACTIVE. I prefer the current explanation since yours can lead to have n ACTIVE and 1 or more INACTIVE and move towards INACTIVE.

The previous explanation is just saying that the INACTIVE did not recover the ACTIVE state: they are stil in INACTIVE.

> AS-PENDING --> AS-DOWN: Tr Expiry, less than n ASPs are in INACTIVE or
> ACTIVE state

No, Once you are in AS_PENDING state, you can go to AS_INACTIVE or AS-DOWN when Tr expires. The difference is that one or more of your previous ASPs moved from ACTIVE to either INACTIVE or DOWN respectively.

That's the reason why I prefer to keep the current text. It means that from the needed number of ASPs to complete n ACTIVE ASPs are in DOWN state (or at least they all are not in INACTIVE state).

> AS-INACTIVE --> AS-DOWN: one ASP trans. to DOWN, causing 
> number of INACTIVE
> or ACTIVE ASPs drop below n

Ok, but it seems it's too much text for the gap. Probably it would be nice to specify this in the AS state description...

Cheers // Javier.

> AS-DOWN --> AS-INACTIVE: IMO, current explanation is fine
> >
> >
> > Cheers // Javier.
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: Tolga Asveren [mailto:[email-masked]]
> > > Sent: Thursday, June 27, 2002 2:53 PM
> > > To: [email-masked]
> > > Subject: RE: [Sigtran] m3ua: IG : n+k redundancy - AS 
> state machine
> > >
> > >
> > > Javier,
> > >
> > > > -----Original Message-----
> > > > From: Javier Pastor-Balbas (ECE)
> > > > [mailto:[email-masked]]
> > > > Sent: Thursday, June 27, 2002 4:57 AM
> > > > To: 'Tolga Asveren'; [email-masked]
> > > > Subject: RE: [Sigtran] m3ua: IG : n+k redundancy - AS 
> state machine
> > > >
> > > >
> > > > Tolga,
> > > >
> > > > See below...
> > > >
> > > > > -----Original Message-----
> > > > > From: Tolga Asveren [mailto:[email-masked]]
> > > > > Sent: Wednesday, June 26, 2002 7:47 PM
> > > > > To: [email-masked]
> > > > > Subject: RE: [Sigtran] m3ua: IG : n+k redundancy - AS
> > > state machine
> > > > >
> > > > >
> > > > > Javier,
> > > > >
> > > > > 1) For changing MAY to SHOULD or MUST, let's change it to
> > > > > SHOULD. In 4.3.1,
> > > > > that it is not appropriate to send DATA to an ASP in
> > > > > ASP-INACTIVE is stated
> > > > > with "SHOULD NOT", so I assume, people are happy with the
> > > > > strictness level
> > > > > of SHOULD in this case, n+k case is similar.
> > > > >
> > > >
> > > > Agreed.
> > > >
> > > > > 2) For n ASPs required for each state change, there are some
> > > > > corner cases
> > > > > (assuming n is required for each state), like:
> > > > > n = 3
> > > > >   2 ASP are in ACTIVE state
> > > > >   1 ASP is in INACTIVE state
> > > > > What is the state of AS? Probably the answer is INACTIVE,
> > > > > then this should
> > > > > be said nicely in the state machine or in a special note.
> > > > >
> > > >
> > > > Don't you think it is enough with the transition "n ASPs are in
> > > > ACTIVE state" to move from AS_INACTIVE to AS_ACTIVE?
> > > [TOLGA] The problem case is not that one. If we reconsider
> > > the example I
> > > gave :
> > > n = 3 (so, we need 3 ACTIVE ASPs to declare AS as ACTIVE and
> > > similarly we
> > > need 3 INACTIVE ASPs to declare to declare AS as INACTIVE. If
> > > there is 1
> > > INACTIVE ASP and 2 ACTIVE ASPs, based on the basic rule, AS
> > > will be in DOWN
> > > state, because there aren't 3 ACTIVE ASPs and there aren't 3
> > > INACTIVE ASPs.
> > > I think, it is better to think AS in INACTIVE state in such a
> > > case, although
> > > it seems there is not too much difference between AS=DOWN or
> > > AS=INACTIVE
> > > from other procudres point of view, just when NTFY("AS
> > > INACTIVE") is sent
> > > changes.
> > > So, to cover the cases like in the above example, we just 
> need put an
> > > explanation to clarify the situation.
> 
> 
> _______________________________________________
> 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, 27 Jun 2002 10:31:56 -0400

Javier,

> Sent: Thursday, June 27, 2002 10:00 AM
> Why? I think it says what it is in a very short way. It is also
> aligned with the transition from DOWN to INACTIVE...
[TOLGA] But for other transitions, we explain, what happens causing what,
here we just say the result. Forexample also for DOWN-->INACTIVE we say "ASP
trans. to ASP-INACTIVE".
> The main reason here is that the some of the ASPs that previously
> where in ASP ACTIVE are now in ASP INACTIVE and in time Tr they
> didn't recover to ASP ACTIVE. I prefer the current explanation
> since yours can lead to have n ACTIVE and 1 or more INACTIVE and
> move towards INACTIVE.
[TOLGA] I was thinking in such a case transition from AS-PENDING to
AS-ACTIVe will be triggered but I agree it is better to clarify it. IMO, the
explanation in the figure is not very clear. It might be that ASP has
transitioned to DOWN state and it is also not necessary that the ASP, which
has transitioned to INACTIVE -or DOWN- should recover to ACTIVE state, it
might be the case that another ASP -which was previously in DOWN state for
example- transitions to ACTIVE. So, personally I would prefer an
explanation, which does not refer to a specific ASPs, which caused AS to
switch to PENDING. So, my new proposal is:
Tr Expiry, n or more ASPs are in INACTIVE or ACTIVE state and number of
ACTIVE ASPs is less than n
>
> The previous explanation is just saying that the INACTIVE did not
> recover the ACTIVE state: they are stil in INACTIVE.
>
> No, Once you are in AS_PENDING state, you can go to AS_INACTIVE
> or AS-DOWN when Tr expires. The difference is that one or more of
> your previous ASPs moved from ACTIVE to either INACTIVE or DOWN
> respectively.
[TOLGA] Like on my comment above, I think it is better not to refer to a
specific ASP. It might be the case, that this specific ASP is still in DOWN
state but another one switches from DOWN to INACTIVE during Tr, so after Tr
the AS state will be INACTIVE.
>
> That's the reason why I prefer to keep the current text. It means
> that from the needed number of ASPs to complete n ACTIVE ASPs are
> in DOWN state (or at least they all are not in INACTIVE state).
>
>
>
>
> Ok, but it seems it's too much text for the gap. Probably it
> would be nice to specify this in the AS state description...
[TOLGA] I agree that most of the explanations are too long to put on the
figure, maybe all of them can be put under the figure and on figure we can
have just labels referring to those explanations.