Protocol version re-negotiation

[Rosen, Brian]

> 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:paul.rheaume at alcatel.com]
> > > Sent: Thursday, February 22, 2001 1:00 PM
> > > To: ITU-SG16 Mail List
> > > Cc: megaco at fore.com
> > > 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
> > >
>

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at mailbag.intel.com