Subject: RE: [Sigtran] m3ua: IG : n+k redundancy

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Mon, 24 Jun 2002 18:07:38 +0200

Hi Tolga, 

The current text gives total flexibility. I agree with you that it is not clear what to do in every case where a n+k model has been set. It will require that both nodes make an agreement and statically configure it.. 

I see it as if n+k redundancy has been added as an optional feature but not a strict requirement for the protocol. In fact the state machine is depicted for the case where n+k configuration is not present. And the "MAY" that you refer is what gives you the opportunity to make an implementation based on that. It also say that n+k is an optional feature and implementations are not enforce to include it.

Then it would be correct to think as the regular M3UA implementations not including this feature. If an specific one implements n+k redundancy (added value) then it should agree with the peer about its use.

I see here two options:
	1- Leave the text as it is and n+k is an option
	2- Clarify the n+k procedure and base the regular behaviour on it

I see the following problem: nr 2 changes the current requirements in the protocol. I don't see as a good idea to force some implementations change at this time. Probably they have been commercialized and arecurrently  compliant with the standard...

What do others think?

Cheers // Javier.

> -----Original Message-----
> From: Tolga Asveren [mailto:[email-masked]]
> Sent: Monday, June 24, 2002 3:55 PM
> To: [email-masked]
> Subject: RE: [Sigtran] m3ua: IG : n+k redundancy
> 
> 
> Let me explain in a little bit more in detail about possible 
> changes for n+k
> redundancy:
> 
> The original method of activating AS with one ASP active and sending
> NTFY("Insuff. ASP Act") if more active ASPs are desireable is 
> fine. But in
> such a case, that "SGP MAY choose not to direct traffic" is 
> not the correct
> behavior, because AS is active with the first active ASP, 
> traffic shouldn't
> be withhold afterwards. I am not against this mode of 
> operation, might be
> usefull for some cases.
> 
> But it is also clear that the above method lacks the ability 
> to wait for n
> ASPs to be active, before statrting to send/receive traffic 
> for this AS. In
> such a case, AS will switch to active state only after n ASPs 
> are active.
> Again there is no need for the sentence "SGP MAY choose not to direct
> traffic" because, it shouldn't start traffic before AS is active.
> 
> Similar comments apply also for the sentence "ASPs should 
> coordinate number
> of active ASPs among themselves". This is not necessary for 
> case1 -but still
> not wrong- but is necessary for case2. In fact even for 
> case2, it might be
> added that SGP shouldn't send DATA before sending NTFY("AS 
> Active") but this
> would be a diversion from the approach that NTFY is only 
> advisory (and also
> DATA and NTFY are sent on separate streams, which might cause loss of
> sequence between them)
> 
> Another small open point for case2 is, whether "n" should be 
> a part of the
> traffic mode or not (for example when traffic mode is present in ASPAC
> message). I tend to think that this would be nice (by adding 
> an optional
> subparameter) but also I am not sure whether this could be 
> considered as a
> too big change for this moment.
> 
> 
>    Tolga
> 
> 
> 
> 
> _______________________________________________
> 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: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 24 Jun 2002 12:12:55 -0500

Javier,

We discussed n+k specifically before and after WG last call.
Because it was optional to implement, we felt that it could be
captured in the IG.  I think we should properly capture the
changes necessary to ensure interoperability of this feature
in the IG.  IMO correcting the behavior will only enhance the
interoperability of existing and upcoming implementations.
Those that have not chosen or will not chose to implement this
feature will be unaffected, anyway.  Those who have
implemented it will benefit by getting resolution to these
interoperability issues.

--brian

Javier Pastor-Balbas (ECE) wrote:          (Mon, 24 Jun 2002 18:07:38)

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Mon, 24 Jun 2002 13:53:18 -0400

Javier,

> From: Javier Pastor-Balbas (ECE)
> [mailto:[email-masked]]
> Sent: Monday, June 24, 2002 12:08 PM
> To: 'Tolga Asveren'; [email-masked]
> The current text gives total flexibility. I agree with you that
> it is not clear what to do in every case where a n+k model has
> been set. It will require that both nodes make an agreement and
> statically configure it..
[TOLGA] IMO, the "flexibility" the current text gives is just an attempt to
cover two different things with one mechanism. I think, that 1 active ASP is
enough but more than this is desireable and that n active ASPs are mandatory
are two different cases. It even might happen that n ASPs are mandatory but
n+m are preferred.
>
> I see it as if n+k redundancy has been added as an optional
> feature but not a strict requirement for the protocol. In fact
> the state machine is depicted for the case where n+k
> configuration is not present. And the "MAY" that you refer is
> what gives you the opportunity to make an implementation based on
> that. It also say that n+k is an optional feature and
> implementations are not enforce to include it.
[TOLGA] If we change the AS state machine for n+k case, for n=1 it will be
the same like the original AS state machine.
>
> Then it would be correct to think as the regular M3UA
> implementations not including this feature. If an specific one
> implements n+k redundancy (added value) then it should agree with
> the peer about its use.
[TOLGA] IMO, if we want n+k to be part of the protocol (even as optional)
procedures for it should be clearly defined (like the optional dynamic
registeration procedures) to let two nodes interoperate without ambiguity.
> I see the following problem: nr 2 changes the current
> requirements in the protocol. I don't see as a good idea to force
> some implementations change at this time. Probably they have been
> commercialized and arecurrently  compliant with the standard...
[TOLGA] If we are carefull enough, I think we can define n+k procedures
without breaking anything on the special 1+k case. Just AS state machine
needs to be changed and the sentence "SGP MAY choose to withhold traffic"
should be reformed saying that if AS is active (n ASPs are active), traffic
will start to flow, otherwise not.