Subject: Re: Interop > Re: Proposal: explain MEGACO protocol RFC status ex plicitly

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 22 Mar 2000 09:17:04 -0500

I have been planning to (help) organize early interoperability
testing.  There is some experience in PacketCable and ISC
in testing MGCP that we can leverage.

I have been looking for a "home" for this effort, and hope
to have that worked out soon.

I believe the first testing will NOT be part of a larger testing
effort, and we will pair Megaco MGCs with Megaco MGs for testing.
First tests will be done with "simple" devices - no more than
a subset of the packages defined in the original document.
We may have a test profile to offer well in advance of the test
that will improve the probability of many MGCs and MGs to try.
There will be some scripts available.

It will be open to all who have devices to test.  It will be
"private" - no observers, just engineer to engineer.  The only
reports issued will be summary in nature and limited to areas
of confusion or other protocol documentation issues.

I'd like to hear from people implementing the protocol when they
would be ready to start testing.  I may have a "co-sponsor",
but others are welcome if they are interested.

Brian

> -----Original Message-----
> From: Christian Groves [mailto:[email-masked]]
> Sent: Tuesday, March 21, 2000 10:27 PM
> To: [email-masked]
> Subject: Interop > Re: Proposal: explain MEGACO protocol RFC status
> explicitly
>
>
> G'Day all,
>
> Chip raises an interesting issue of interoperability tests.
> The current
> plans for such testing seems to me to be ambiguous at best.
>
> Due to the generic nature of Megaco it seems to me to be
> quite difficult
> to test. From what I have seen (please correct me if this isn't the
> case) is that Megaco/H248 is planned to be tested as part of a larger
> application test. ie. trunking gateway, IP phone etc. This to
> me seems a
> lot of overhead just to test the megaco protocol. It also seems to put
> certain players of the interop test. ie. if I make SIP GW which have
> h248 but the interop test covers IP phones how do I get my
> Megaco stack
> tested???
>
> Are there any initiatives where something similar to the following
> approach is taken? Do people see merit in this?
> o The test is a test of the protocol mechanisms.
> o Test between 2 boxes (PCs, workstations etc) that implement
> H248 with
> the necessary SW to drive the test. These boxes would be application
> agnostic.
> o A test package could be developed with "dummy" properties, events,
> signals etc.
> o A test case document which lists test cases for a good coverage test
> of Megaco. These test cases could describe what should occur at dummy
> event detection.
>
> The aim of the approach is an interop where people who intend to
> implement Megaco but not in one of the proposed applications can test
> there stacks without having to implement an entire application.
>
> If anyone has any information of the current status of Megaco interops
> can they please share it on the list.
>
> Cheers, Christian
>
>
> Chip Sharp wrote:
> >
> > As a further clarification, independent of any judgement on
> megaco/H.248 in
> > particular, publication of any RFC as Proposed Standard is really a
> > snapshot of the development of the protocol.  At the point
> of publication
> > of the RFC as Proposed Standard, the protocol is considered
> stable enough
> > to begin implementation, perform interoperability tests and
> perhaps get
> > some deployment experience (not necessarily in production networks).
> >
> > If during this process, problems are found in the protocol
> and corrections
> > are needed, a new RFC can be published with the corrections
> while still
> > remaining in Proposed Standard state.
> >
> > There is no requirement to implement an I-D before it moves
> to Proposed
> > Standard.  Sometimes this is done and it definitely helps
> to get this
> > experience to learn the ins and outs as the protocol is
> developed, but it
> > is not required.
> >
> > As far as megaco/H.248 is concerned, I do believe something like
> > implementer's agreements (or profiles) will have to be
> worked out for
> > interoperability reasons for specific applications since
> there are so many
> > options and different ways of doing the same thing.
> Although there are
> > details we all don't agree on, the IP Phone profile is one
> attempt at doing
> > this for an IP Phone application.
> >
> > One thing to keep in mind is that before megaco can move to
> Draft Standard
> > in IETF, all options that don't have multiple interoperable
> implementations
> > have to be removed.
> >
> > Chip
> >
> > At 08:50 AM 3/21/00 -0500, Rosen, Brian wrote:
> > >I disagree with your assessment of the state of the protocol.
> > >
> > >While there have been a series of text change proposals made
> > >in the last few weeks, all of them have either been requests
> > >to clear up language, or proposals to fix some minor errors for
> > >unusual circumstances.  In no case, AFAIK, would any of the changes
> > >invalidate any existing implementation by more than a very minor
> > >addition.  There are no plans for any major changes to syntax,
> > >and no changes at all to semantics, unless you consider
> clarification
> > >of intent to be a semantic change.  I don't understand the
> "transport
> > >syntax" part at all, unless you are thinking about the ITU work
> > >on ATM transport and SCTP annexes, which will not carry
> through to the
> > >IETF version on present plans.
> > >
> > >There will be an erratum published with the RFC.  Together, they
> > >should provide a stable basis for the protocol.  The
> document is large.
> > >In any such document, there are things that could use more
> explanation.
> > >While an implementor's guide has been discussed, it has not yet
> > >been decided if we will need one.  I suspect we will.  The
> guide will
> > >not, if I have anything to do with it, change the protocol at all.
> > >If it needs to be changed, we will have to have a new RFC.
> > >
> > >Brian
> > >
> > > > -----Original Message-----
> > > > From: Pekka Pessi [mailto:[email-masked]]
> > > > Sent: Tuesday, March 21, 2000 8:35 AM
> > > > To: [email-masked]
> > > > Subject: Proposal: explain MEGACO protocol RFC status explicitly
> > > >
> > > >
> > > >         Hello all,
> > > >
> > > >         The current MEGACO/H.248 draft,
> > > > draft-ietf-megaco-protocol-07.txt,
> > > >         is still ongoing work. AFAIK the protocol is still
> > > > incomplete and
> > > >         largely unimplementable. A reference implementation
> > > > has just been
> > > >         started.  The working group is planning to
> change the protocol
> > > >         semantics and transport syntax. There would be
> no point in
> > > >         publishing the document as an RFC, if this were an
> > > > IETF-only project
> > > >
> > > >         As I have understood, publishing incomplete
> recommendations is
> > > >         business as usual in ITU-T due to practical
> reasons. The ITU-T
> > > >         recommendations must be approved using
> time-consuming formal
> > > >         process, including a ballot. So, the finalized ITU-T
> > > > specification
> > > >         actually consists of a recommendation document
> > > > together with an
> > > >         Implementor's Guide correcting the errors and
> omissions in the
> > > >         recommendation document. IG may contain major
> changes that are
> > > >         incompatible with the published recommendation
> > > > document.  Also, when
> > > >         referring to a ITU-T specification, like
> H.323v2, people are
> > > >         actually referring to the recommendation
> together with the
> > > >         respective implementor's guide.
> > > >
> > > >         The ITU-T process is (or at least should be)
> familiar to the
> > > >         developers using ITU-T recommendations.
> However, in Internet
> > > >         community people are expecting that the RFC is not
> > > > just a snapshot
> > > >         of an on-going work. They don't anticipate that there
> > > > is a companion
> > > >         document possibly changing the base protocol in
> every turn.
> > > >
> > > > Proposal
> > > >
> > > >         I propose that the MEGACO RFC should contain a
> > > > paragraph explaining
> > > >         the status of the text, ie. that the protocol will be
> > > > changed by an
> > > >         Implementors' Guide published soon. The MEGACO
> RFC should also
> > > >         recommend that any reference to it must also be
> > > > accompanied with a
> > > >         note explaining the status of the RFC, and a
> reference to the
> > > >         Implementors' Guide.
> > > >
> > > >         Best regards,
> > > >                                         Pekka Pesi
> > > >
> >
> > Support NetAid!  http://www.netaid.org
> > --------------------------------------------------
> > Chip Sharp                 Consulting Engineering
> > Cisco Systems              Telco Bio-region
> > Reality - Love it or Leave it.
> > --------------------------------------------------
>

---

From: Christian Groves <[email-masked]>
Date: Thu, 23 Mar 2000 17:00:53 +1100

G'Day Brian,

Thanks for the update. Can you elaborate on the "home" of this effort? I
know you've done some work in MSF on this. Can you provide some info to
the list if you have more details of what is to be tested and what the
current plans are?

Is it necessary to organise a "home" for this effort? Sigtran it seems
are doing a protocol interop test without having to go to another forum.
Interested parties are getting together. Perhaps someone who
participates in the Sigtran interop can comment? Perhaps we could do
something similar for Megaco?

I'm glad that the first step with not be part of a larger effort and
will be done on simple devices. The question is what sort of devices and
what packages?

I've envisaged that the test could be done as you say between Megaco MGC
and Megaco MG and would be agnostic of the application and many
packages. I saw that we test the root package as it has protocol
specific information and perhaps a specifically developed test package
that has a number of properties, signals, events, statistics labelled in
a very generic way. I didn't see that we would do a simple IP phone or
trunking GW interop. After all we just need to test the Megaco
mechanisms.

A test profile containing test cases and scripts could then be defined
to test the various protocol mechanism employed to relay the properties,
signals, events and statistics.

We can worry about format and reporting of the interop event when we get
closer to it.

Cheers, Christian