New comer questions

[Liu, Gary]

G'Day,

There's been a few points raised in this thread. It seems to me that
people are getting a "protocol version upgrade of Megaco" and an
"upgrade of the MG" mixed up. I don't see the need for bringing down the
whole MG just to update the Megaco interface. We have protocol version
negotiation procedures H.248 sect 11.3. We can issue a ServiceChange
with the new version number, method "warm boot" and "restart" and not
loose state on the MG. See Annex L -

3.4 Reason # : 902 Name: Warm Boot
Definition: This indicates that the entity indicated with the
TerminationID  is in ServiceState "in-Service", and that it has gone
through a start or recovery action. All transactions in process may be
lost, but otherwise all state is preserved on the termination.
Reference: -
Text in the Service Change extension: -
Comment: This reason code only applies for TerminationID root.


So I don't see what the issue is.

Any new functionality to add new methods is really something for H248v2.

Cheers, Christian

Michael Brown wrote:
> 
> Nancy,
> 
>    The parameter that would be used is be the ServiceChangeAddress. As
> far as the assumption that the MGC would be provisioned with the
> primary and secondary MGs, certainly it could be done that way (and
> the text in 11.4 does imply this), but I do think that passing the
> address is an acceptable approach and should certainly be allowed.
> 
>    IMO we don't really need a new method for this. I don't see how
> adding a new method is more efficient. I still would contend that
> adding a ServiceChangeReason is sufficient and that it is desirable to
> do so (at least in V.2).
> 
> Michael
> 
> -----Original Message-----
> From: Nancy Devin [mailto:nancy.devin at alcatel.com]
> Sent: Tuesday, February 27, 2001 1:07 PM
> To: Brown, Michael [NC1:GW10:EXCH]
> Cc: ITU-SG16 Mail List; megaco at fore.com
> Subject: Re: Protocol version re-negotiation
> 
> 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
> 
> Michael Brown wrote:
> 
> > Comments inline.
> >
> > Michael
> >
> > "Rosen, Brian" wrote:
> >
> > >
> > > > 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.
> >
> > <MB> Yes, if the MG is really Non-redundant there doesn't seem to be
> an option.
> >
> > >
> > > >
> > > > 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.
> 
> >
> > <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.
> 
> >
> > >
> > >
> > > >
> > > > 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.
> >
> > <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.
> >
> > >
> > >
> > > >
> > > > 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
> > > > > >
> > > >
> 
> --
> 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:  nancy.devin at alcatel.com