Subject: [Megaco] Failure of MGC

From: [email-masked]
Date: Tue, 24 Jul 2001 16:08:51 +0530

Hi

Section 11.5 indicates, if the MG detects failure of its controlling MGC, it
sends the service change command with Failover method.
And Section D.1.5 indicates, if more than T-MAX time has elapsed since the
sending of initial datagram, the MG concludes that the MGC has failed, it sends
the service change command with Disconnected method.

Can you please differentiate between the two?

Regards
Vivek

_______________________________________________
Megaco mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/megaco

---

From: Terry L Anderson <[email-masked]>
Date: Tue, 24 Jul 2001 12:51:31 -0400

It DOES look like a contradiction.  I have always wondered about the 11.5
specification to use Failover since this case is not mentioned in the definition of
failover in 7.2.8 and there the definition of Disconnected does seem to fit
(agreeing with D.1.5).

What do others want to do?  Change 11.5 to say "Disconnected"?

--
Waiting for the other shoe to drop but hoping its a one legged man.
------------------------------------------------------------
Terry L Anderson              mailto:[email-masked]
Tel:908.582.7013   Fax:908.582.6729
Lucent Technologies/INS/Voice Over IP Access Networks
Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974
http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla

---

From: Christian Groves <[email-masked]>
Date: Wed, 25 Jul 2001 13:36:29 +1000

Hello,

I believe 11.5 is correct. The paragraph starts, "If the MG detects a
failure of its controlling MGC, it attempts to contact the next MGC on
its pre-provisioned list." This is clearly failover.

D.1.5, I believe intends "Disconnect" as it is used when communication
has been restored (recovered) with the MGC.

Disconnect is used when you don't fail over to a completely new MGC.

Regards, Christian

---

From: Terry L Anderson <[email-masked]>
Date: Wed, 25 Jul 2001 11:04:29 -0400

> has been restored (recovered) with the MGC.

The the wording is wrong as it says "The MS shall use a ServiceChange with
ServiceChangeMethod set to Disconnected to that the new MGC will  be aware ..."  so it is
referring to value sent to NEW MGC for restored communication with original MGC.

> Disconnect is used when you don't fail over to a completely new MGC.

Well whichever way we settle, I think the current wording is confusing and call cases
should be described in one place.

So our choice is:
1) use "failover" in attempts to contact next MGC on pre-provisioned list (if any) but
"Disconnected" if (possibly after trying others) one re-tries the original,
OR
2) use "Disconnected" in both cases.

If we choose case 1, I would fix the wording in D.1.5 and spell out BOTH cases in 11.5.
Def of Failover in 7.2.8 should include this case (currently it only includes case of MG
failure).
If we choose case 2, I would fix 11.5 to say "disconnected"

Which do we want??

--
Waiting for the other shoe to drop while hoping it's a one legged man.

---

From: Terry L Anderson <[email-masked]>
Date: Thu, 26 Jul 2001 14:19:25 -0400

Ok, we seem to have agreement to use "failover" in attempts to contact next MGC on
pre-provisioned list (if any) but "Disconnected" if (possibly after trying others) one
re-tries the original.

Here are my suggested changes for the IG.

To section 7.2.8

4) Disconnected – always applied with the Root TerminationID, indicates that the MG lost
communication with the MGC, but it was subsequently restored to the same MGC (possibly after
trying other MGCs on pre-provisioned list).  Since MG state may have changed, the MGC may
wish to use the Audit command to resynchronize its state with the MG's.

6) Failover – sent from MG to MGC to indicate the primary MG is out of service and a
secondary MG is taking over Sent from MG to next MGC on pre-provisioned list in the event of
detected failure of current MGC with a “MGC Impending Failure” reason.

To section 10.5 (first paragraph)

If the MG detects a failure of its controlling MGC, it attempts to contact the next MGC on
its pre-provisioned list.  It starts its attempts at the beginning (Primary MGC), unless that
was the MGC that failed, in which case it starts at its first Secondary MGC.  It sends a
ServiceChange message with a "Failover" method and a " MGC Impending Failure" reason.  If
there is no pre-provisioned secondary MGCs or all other MGCs have been attempted without
success, MG may retry the previously controlling MGC using ServiceChange message with a
“Disconnected” method.

To section D.1.5 (last paragraph)

It is, however, important that the maximum delay of retransmissions be bounded.  Prior to any
retransmission, it is checked that the time elapsed since the sending of the initial datagram
is no greater than T-MAX. If more than T-MAX time has elapsed, the MG concludes that the MGC
has failed, and it begins its recovery process as described in section 11.5. If the MG
retries the current MGC it shall use a ServiceChange with ServiceChangeMethod set to
Disconnected so that the new MGC will be aware that the MG lost one or more transactions.
The value T-MAX is related to the LONG-TIMER value: the LONG-TIMER value is obtained by
adding to T-MAX the maximum propagation delay in the network.

---

From: "Madhu Babu Brahmanapally" <[email-masked]>
Date: Thu, 26 Jul 2001 15:08:05 -0400

HI All,
Along with the following text, can we add text to say whether both MGC and
MG can use the same method or not. For example usage of Disconnected is
listed in the document to be used only by MG.

Regards
Madhubabu

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Terry L Anderson
Sent: Thursday, July 26, 2001 2:19 PM
To: [email-masked]
Subject: Re: [Megaco] Failure of MGC

Ok, we seem to have agreement to use "failover" in attempts to contact next
MGC on
pre-provisioned list (if any) but "Disconnected" if (possibly after trying
others) one
re-tries the original.

To section 7.2.8

4) Disconnected – always applied with the Root TerminationID, indicates that
the MG lost
communication with the MGC, but it was subsequently restored to the same MGC
(possibly after
trying other MGCs on pre-provisioned list).  Since MG state may have
changed, the MGC may
wish to use the Audit command to resynchronize its state with the MG's.

6) Failover – sent from MG to MGC to indicate the primary MG is out of
service and a
secondary MG is taking over Sent from MG to next MGC on pre-provisioned list
in the event of
detected failure of current MGC with a “MGC Impending Failure” reason.

If the MG detects a failure of its controlling MGC, it attempts to contact
the next MGC on
its pre-provisioned list.  It starts its attempts at the beginning (Primary
MGC), unless that
was the MGC that failed, in which case it starts at its first Secondary MGC.
It sends a
ServiceChange message with a "Failover" method and a " MGC Impending
Failure" reason.  If
there is no pre-provisioned secondary MGCs or all other MGCs have been
attempted without
success, MG may retry the previously controlling MGC using ServiceChange
message with a
“Disconnected” method.

It is, however, important that the maximum delay of retransmissions be
bounded.  Prior to any
retransmission, it is checked that the time elapsed since the sending of the
initial datagram
is no greater than T-MAX. If more than T-MAX time has elapsed, the MG
concludes that the MGC
has failed, and it begins its recovery process as described in section 11.5.
If the MG
retries the current MGC it shall use a ServiceChange with
ServiceChangeMethod set to
Disconnected so that the new MGC will be aware that the MG lost one or more
transactions.
The value T-MAX is related to the LONG-TIMER value: the LONG-TIMER value is
obtained by
adding to T-MAX the maximum propagation delay in the network.

---

From: Terry L Anderson <[email-masked]>
Date: Thu, 26 Jul 2001 17:07:32 -0400

> listed in the document to be used only by MG.

I don't think that there is any global rule.  Each must (and most do) list
whether MG or MGC or both may use it and what the meaning is in each case.
Currently Disconnect does not explicitly indicate direction.  I believe that the
current description assumes MG->MGC.  I have heard no proposal for what it would
mean if sent from MGC->MG.  If a connection is lost (disconnected) a new one
currently must be initiated by MG.  Are you suggesting that MGC might initiate a
reconnection?  This would seem related to a previous discussion about Polling
and I believe it was agreed that MGC could not initiate.

So are you proposing that we make the restriction of MC->MGC only explicit? or
are you suggesting that it should be used MGC->MG?  If the latter, someone would
have to propose what it would mean.

The recent thread started by Andrew Russell-laing seems to be favoring the use
of Restart from MGC->MG.  Restart is one that currently does not explicitly
state direction although the description seems to assume MG->MGC.  I will add a
directional statement  for Restart if it appears we are all in agreement..

Any objections?

---

From: "Madhu Babu Brahmanapally" <[email-masked]>
Date: Thu, 26 Jul 2001 17:36:40 -0400

HI Terry, All,
my comments below [Madhu]

-----Original Message-----
From: Terry L Anderson [mailto:[email-masked]]
Sent: Thursday, July 26, 2001 5:08 PM
To: Madhu Babu Brahmanapally
Cc: [email-masked]
Subject: Re: [Megaco] Failure of MGC

I don't think that there is any global rule.  Each must (and most do) list
whether MG or MGC or both may use it and what the meaning is in each case.
Currently Disconnect does not explicitly indicate direction.  I believe that
the
current description assumes MG->MGC.  I have heard no proposal for what it
would
mean if sent from MGC->MG.  If a connection is lost (disconnected) a new one
currently must be initiated by MG.  Are you suggesting that MGC might
initiate a
reconnection?  This would seem related to a previous discussion about
Polling
and I believe it was agreed that MGC could not initiate.

So are you proposing that we make the restriction of MC->MGC only explicit?
or
are you suggesting that it should be used MGC->MG?  If the latter, someone
would
have to propose what it would mean.

[Madhu]Yes, IMO making the direction explicit will give more clarity. As you
suggested, the disconnection from MGC is not valid and hence needs to be
mentioned. Its true that the protocol at present discusses only the case
where MG uses that method, it doesn't mention whether using the same method
if valid or not (and if assumed valid, what is its implication). Because the
grammar at present support all methods in both directions, explicitly
mentioning the direction will help.

The recent thread started by Andrew Russell-laing seems to be favoring the
use
of Restart from MGC->MG.  Restart is one that currently does not explicitly
state direction although the description seems to assume MG->MGC.  I will
add a
directional statement  for Restart if it appears we are all in agreement..

Any objections?

-Regards
Madhubabu

---

From: Terry L Anderson <[email-masked]>
Date: Thu, 26 Jul 2001 18:48:30 -0400

Ok, the issue is how explicit to be as well has what sort of changes should be
introduced through the IG.  Since I have only been editor for 2 months, I'll
accept some guidance from the group about what sort of changes to allow.  I know
that there was a recent comment (Christian?) about avoiding gratuitous changes.

Personally I am bothered by ambiguity and fear it causes interoperability
problems so my bias would be to support changes whenever we uncover an ambiguity
that has a reasonable probability of leading to confusion and inconsistent
implementations - the change would attempt to remove ambiguousness by being more
specific.  I would not support change where someone merely misread the statement
because its wording was a little confusing but it could only reasonably be
interpretted one way.

I'll argue that this issue falls in the "support change" class unless the intent
was to basically allow all ServiceClassMethods (or all not mentioning direction)
to be used in either direction whether or not it makes a lot of sense.  The
problem is that one could never be sure the other end would take any suitable
action.  So I would suggest that we add a directional statement (MG->MGC,
MGC->MG or both) to each Method that does not currently have one.

Let's discuss this before I write specific language.  I propose
Graceful:  MG->MGC only
Forced: MG->MGC & MGC->MG
Restart: MG->MGC & MGC->MG
Disconnected: MG->MGC only
Handoff: MG->MGC & MGC->MG (as currently specified)
Failover: MG->MGC only (only direction currently specified)

Do we agree that MGC can send Forced and Restart but NOT Graceful?  Seems useful
for MGC to be able to manage inservice/out-of-service state in certain cases,
but I see no reason for it to use Graceful (MGC can "refrain from establishing
new connections" and can "gracefully teardown existing connections" on its own
and then send Forced when it is ready).

---

From: Christian Groves <[email-masked]>
Date: Fri, 27 Jul 2001 15:55:24 +1000

Hello Terry,

> Graceful:  MG->MGC  x  MGC->MG

I believe that both of these are valid. There could be a MGC Impending
Failure after a specified amount of time. I don't believe it is invalid
or wrong for the MGC to indicate to the MG that after a period of time
set the termination states to out of service.

Christian

---

From: Christian Groves <[email-masked]>
Date: Fri, 27 Jul 2001 15:55:16 +1000

G'Day Terry,

Please see my comments below. I think you forgot to add existing
Implementors' Guide Corrections.

Cheers, Christian

Terry L Anderson wrote:
..snip..

6) Failover - sent from MG to MGC to indicate the primary MG is out of
service and a secondary MG is taking over. <<This serviceChange method
is also sent from the MG to the MGC when the MG detects that MGC has
failed. In this case this method is sent to a secondary MGC instead of
the one that failed.>>

To section <<11>>.5 (first parapraph)

If the MG detects a failure of its controlling MGC, it attempts to
contact the next MGC on its pre-provisioned list.  It starts its
attempts at the beginning (Primary MGC), unless that was the MGC that
failed, in which case it starts at its first Secondary MGC.  It sends a
ServiceChange message with a "Failover" method and a " MGC Impending
Failure" reason. <<If the MG is unable to establish a control
relationship with any MGC, it shall wait a random amount of time as
described in section 9.2 and then start contacting its primary, and if
necessary, its secondary MGCs again.  >>