AVD-2036 and AVD-2087

[Paul, Manoj]

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

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