Subject: RE: Protocol version re-negotiation

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 23 Feb 2001 16:38:58 -0500

> I think you missed one point: "How does a NON-redundant MG 
> upgrade to a
> new version of the protocol?"
It comes down, reboots, and comes up again - it's a service affecting
change.  AFAIK, that's the only way today.
> 
> Can the MG Failover to itself? Will this cause any problems 
> in the MGC?
Since that's not a defined option, some MGCs might have a problem.

> 
> To allow this requires only a few changes to the text in RFC3015 as
> follows:
> Section 7.2.8 ServiceChange
> Modify text: "6) Failover - sent from MG to MGC to indicate 
> the primary
> MG is out of service and a secondary is taking over, or to indicate a
> version negotiation from the MG."
> Add a Reason: "Version Negotiation" or a more generic "MG Directed
> Change".
> Add text: "The MG may initiate a version negotiation with a
> ServiceChange Command specifying the "Root" for the TerminationID,
> ServiceChangeMethod equal to Failover and ServiceChangeReason equal to
> "Version Negotiation"."
I think that's a scope add, which I for one am reluctant to do.
If there was a real problem with something we already had, that's one thing,
but a real feature add, I'm less thrilled about.  I'll admit some of the
things
we have talked about stray at least close, if not over such a line.  Here,
I think an MG that can do a non-service affecting upgrade which is not
redundant is pretty unusual these days - I don't mean to discourage folks
from doing that, but I also don't feel we need changes in semantics (and
some additional syntax, albeit some IANA registrations) to make it happen,
it can wait for V2.

> 
> Cheers,
> Paul
> 
> "Rosen, Brian" wrote:
> > 
> > It's unlikely that we will do anything that adds
> > new features by edits to the implementor's guide.
> > It's reasonable to have explanatory text in such a
> > document that is not normative.
> > 
> > I think you failover, upgrade, and failover back
> > with this version of the protocol.
> > 
> > Brian
> > 
> > > -----Original Message-----
> > > From: Paul Rheaume [mailto:[email-masked]]
> > > Sent: Thursday, February 22, 2001 1:00 PM
> > > To: ITU-SG16 Mail List
> > > Cc: [email-masked]
> > > Subject: Re: Protocol version re-negotiation
> > >
> > >
> > > Folks,
> > >
> > > Where is the appropriate list to discuss this issue?
> > >
> > > We feel that version negotiation and the version upgrade
> > > process is not
> > > well specified and needs to be discussed and properly 
> defined at the
> > > latest in version 2 of the specification. That means 
> looking at this
> > > very soon.
> > >
> > > I think this issue belongs to the next version of the 
> Implementor's
> > > Guide.
> > >
> > > Regards,
> > > Paul
> > >
> > > Nancy Devin wrote:
> > > >
> > > > How does a non-redundant MG upgrade to a new
> > > > Megaco version without affecting service?  How
> > > > does a redundant MG upgrade to a new Megaco
> > > > version without affecting service?
> > > >
> > > > It is mentionned in RFC3015 that Protocol version
> > > > negotiation can be done at Restart, Failover, and
> > > > Handoff serviceChanges.  It is not mentionned
> > > > explicitly how version protocol re-negotiation is
> > > > done after the MG has registered with the MGC. in
> > > > both situation
> > > >
> > > > This could be done in at least two different ways
> > > > as listed bellow.
> > > >
> > > > 1-    Protocol version negotiation could be
> > > > initiated using the Failover serviceChange.  A
> > > > Failover serviceChange with a protocol version
> > > > would indicate that the MG has been configured
> > > > with a new H.248 protocol version.  Sent from the
> > > > MG to the MGC, it indicates that the MG has been
> > > > configured with a new H.248 protocol version.
> > > > This serviceChange shall not indicate Failure of
> > > > the working MG.  This would require that for
> > > > non-redundant MGs, both the primary IP address and
> > > > the secondary IP address be the same.
> > > >
> > > > 2-    Protocol version negotiation could be
> > > > intiated using a new serviceChange method:
> > > > VersionNegotiation (Method 7 of the serviceChange
> > > > command as defined in RFC3015) This serviceChange
> > > > would be sent from the MG to the MGC to initiate
> > > > protocol version initiation.  It indicates that
> > > > the MG has been configured with a new H.248
> > > > protocol version.  Sent from the MGC to the MG, it
> > > > indicates that the MGC has been configured with a
> > > > new H.248 protocol version.
> > > >
> > > > Comments please.
> > > > Nancy
> > >
>

---

From: "Michael Brown" <[email-masked]>
Date: Mon, 26 Feb 2001 18:16:33 -0500

Comments inline.

Michael

> change.  AFAIK, that's the only way today.

<MB> Yes, if the MG is really Non-redundant there doesn't seem to be an option.

> Since that's not a defined option, some MGCs might have a problem.

<MB> While there is no existing text specifically saying that this is allowed.,
there also is none that disallows this behavior. It seems to me that the MGC
should just accept the "new" address for the "secondary" MG and go on. This
would be used when an MG and its mate hide behind a single address for the MGC
<> MG control association. I would think that this could easily be added to the
implementor's guide and I don't think that it should cause problems.

> some additional syntax, albeit some IANA registrations) to make it happen,

<MB> I'm suppose I'd agree that this propoal is adding a new feature as it would
require a new, IANA registered reason and the associated behavior. I'd say it's
somewhat unfortunate because basically, I don't see problems with the proposed
approach. There is one thing about the approach that bothers me which we might
consider for V2. That is, the use of Failover in this instance seems
inappropriate. The name just seems to imply that a software upgrade is a failure
scenario. I would suggest that it would be nicer  to enhance the definition of
Handoff rather than Failover since handoff implies a more graceful transition.
Given the current definitions of Handoff and Failover in version 1, we do have
to live with Failover for now.

---

From: Nancy Devin <[email-masked]>
Date: Tue, 27 Feb 2001 13:07:01 -0500

Hi Mike,

I don't understand why your are talking about passing the address of the secondary
MG to the MGC during a Failover.  My understanding is that the MGC is configured
with both the primary MG address and the secondary MG address (even though I did
not find any text on that).  If that is not the case then which parameter is used
to transmit the address the the MGC.

Also, I think the idea of having to Handoff to another MG or Failover to the other
MG may not be the most efficient one.  If we are to add a new reason then why not
also add a new method which would be "VersionNegotiation"

Method:               VersionNegotiation
TerminationID:    Root
Reason:                MG directed change / MGC directed change
Description:
Sent from the MG to the MGC, the MG initiates a protocol version negotiation.  Sent
from the MGC to the MG, the MGC initiates a protocol version negotiation.

Nancy

--
Nancy Devin
Software Designer

Alcatel
600 March Road, P.O. Box 13600
Kanata, Ontario, Canada
K2K 2E6

Telephone: (613) 591-3600 x6897
Fax:       (613) 599-3609
Internet:  [email-masked]