Subject: Why send Disconnect after Failover

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 12 Jan 2001 08:45:01 -0500

It was pointed out to me that in D.1.5 it states:
   If more than T-MAX time has elapsed, the MG concludes
   that the MGC has failed, and it begins its recovery process. The MG
   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.

This seems silly to me.  ServiceChange of Failover indicates there
was a problem.  Sending ServiceChange of Disconnected after sending
ServiceChange of Failover is redundant.  The new MGC must do a thorough
audit on the MG anyway.  I think this text should be deprecated in the
Implementor's Guide.

Brian

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 16 Jan 2001 15:45:55 -0500

The "disconnect" we seem to be having is that I think
you use "Disconnect" when you regain communications
with the same (i.e. old) MGC after losing it.
I think you use "Failover" if you decide to give up
on the old one.  I think there is no need to send
two serviceChange messages (one Failover, one
Disconnect).  I'll agree that we could either
fix the wording to say that, or fix the wording so
that you could use Disconnect to establish a
new association with a new MGC after giving up on the
old one as well as when regaining communications with
the old one.  I'd prefer failover.

If the MG exhausts it's list, it probably should
        Wait a while and then try the original again
        then try it's list again.

"a while" in this case might be a relatively long
time, or maybe exponentially increasing quickly to
a long time.

Brian

> -----Original Message-----
> From: Flemming Andreasen [mailto:[email-masked]]
> Sent: Tuesday, January 16, 2001 3:17 PM
> To: Rosen, Brian
> Cc: [email-masked]
> Subject: Re: Why send Disconnect after Failover
>
>
>
>
> "Rosen, Brian" wrote:
>
> > The text in D.1.5 says:
> > Note the phrase "new MGC".
>
> Define "new" then (I simply interpret it to mean whicever MGC
> you end up
> talking to next).
>
> > "Recovery Process" could be
> >         wait - it might come back
> > or
> >      Initiate ServiceChange for failure of MGC
> >
> > Of course, in the first instance, if you wait too long, you
> > eventually give up.  The "MG shall use a ServiceChange with
> > ServiceChangeMethod set to Disconnected" only when it
> > decides to wait, and indeed the MGC "comes back".  If it
> > gives up, it would use "failover", as in 11.5
>
> Hadn't noticed that - the definition of the Failover
> ServiceChangeMethod in
> Section 7.2.8 seems to be incorrect then.
>
> >
> >  It sends a ServiceChange message with a "Failover" method and
> >  a " MGC Impending Failure" reason.
> > If it does failover, there is no need to send "Disconnected",
> > the new MGC must audit no matter what.
> >
> > So I think we need to change the wording in D.1.5 to something like:
> > ... the MG concludes that the MGC has failed.  It may wait
> > for some further time to see if the MGC recovers, in which case it
> > shall use a ServiceChange with a ServiceChangeMethod set to
> Disconnnected
> > so that the MGC will be aware that the MG lost one or more
> transactions.
> > If the MG instead attempts to establish a connection with an
> > alternate MGC, it shall use a ServiceChange message with a
> "Failover"
> > method.  MGCs accepting MGs for service with Failover should audit
> > the MG to discover the actual state.
>
> Sounds like you might as well use "disconnected" and keep the
> definition in
> 7.2.8. Also, what do you do if the MG exhausts it list of MGC's ?
>
> -- Flemming
>
>
> >
> >
> > Brian
> >
> > > -----Original Message-----
> > > From: Flemming Andreasen [mailto:[email-masked]]
> > > Sent: Monday, January 15, 2001 4:14 PM
> > > To: Rosen, Brian
> > > Cc: [email-masked]
> > > Subject: Re: Why send Disconnect after Failover
> > >
> > >
> > >
> > >
> > > "Rosen, Brian" wrote:
> > >
> > > Not sure I follow. The text in D.1.5 talks about failover in
> > > a generic way,
> > > but you are implying it's discussing ServiceChange with a
> method of
> > > Failover (which applies to redundant MGs).
> > >
> > > -- Flemming
> > >
> > > >
> > > >
> > > > Brian
> > >
> > > --
> > > Flemming Andreasen
> > > Cisco Systems
> > >
> > >
>
> --
> Flemming Andreasen
> Cisco Systems
>
>