RE: [T1X1.5] RE: [IP-Optical] Re: Proposed text for the concatenation

["Mannie, Eric" <Eric.Mannie@ebone.com>]

Hello Marc,

I think that you are speaking about two different things, you want to
compare apples and oranges. You are using ITU-T standards as counter
examples.  It is better to compare signaling protocols between them. For
instance, you should compare GMPLS (with all its options) and an ITU-T
standard like H.323 (with all its options). You need a profile for H.323 as
you need a profile for GMPLS. There are *lots* of features in H.323 that you
are not obliged to implement. It is even worst there are sometimes two ways
of doing the same thing. I made three world-wide interop event (as
developer) of H.323 and trust we it was not easy to achieve a basic
interoperability (just to open a connection, talk and close it). If you
consider supplementary services it becomes a nightmare. H.323 was also done
re-using existing signaling.

Hopefully, GMPLS has much less options and is much less complex than H.323.

If you tried to do any MPLS based implementation you should know that there
are plenty of options. One of the biggest is the signaling protocol that you
want to use: RSVP-TE or CR-LDP. Before going to signaling details you must
consider the biggest issues.

>A solution to this problem may be to have an extension to the standard.
The
>base standard includes the non-optional stuff that everyone expects to
>implement.  If there are extra features that more than one or two vendors
>are going to implement, make that a new standard that is based on the
>baseline.

I don't thing this is applicable to MPLS and GMPLS. The basic idea is to be
as generic (and general) as possible. You cannot be generic and restrictive
at the same time, these are opposite objectives.

Kind regards,

Eric

-----Original Message-----
From: Randolph, Marc [mailto:MRandolph@WhiteRockNetworks.com]
Sent: Wednesday, May 23, 2001 11:29 PM
To: Mannie, Eric; 'Guo-Qiang Wang'
Cc: ccamp@ops.ietf.org
Subject: RE: [T1X1.5] RE: [IP-Optical] Re: Proposed text for the
concatena tion


> -----Original Message-----
> From: Mannie, Eric [mailto:Eric.Mannie@ebone.com]
> Sent: Wednesday, May 23, 2001 1:17 PM
> To: 'Guo-Qiang Wang'
> Cc: ccamp@ops.ietf.org; ip-optical@lists.bell-labs.com; q11/15; t1x1.5
> Subject: [T1X1.5] RE: [IP-Optical] Re: Proposed text for the
> concatenation
> 
> 
[...]
>
> - the fact that a feature is in the signaling does not mean 
> that it must be implemented.
> - you can claim to be compliant with the draft without 
> implementing some features.

Hello Eric,

I respectively disagree with these statements.

I don't presume to know all customers, but if I were a customer, I'd
strongly dislike having four vendors approach me saying they were compliant
with standard X when in fact, each one has left out a few (but different)
features that they somehow decided weren't important.

Then the customer is reduced to asking each vendor "Did you implement
feature Y and Z?  What about A and B?"

If the features are truely that minor that they can be excluded, do they
really belong in the main spec?

I actually think of it another way... what if there were a standard for what
personal information manager features were included in a new cell phone
(because that is what I've been personally investigating lately).  But when
I go to buy a phone, I discovered they left out the calendar/scheduler and
they only have contact info, because that is what they viewed as the
important part of the standard.  I submit they don't comply with the
standard.

A solution to this problem may be to have an extension to the standard.  The
base standard includes the non-optional stuff that everyone expects to
implement.  If there are extra features that more than one or two vendors
are going to implement, make that a new standard that is based on the
baseline.

For example, take the original G.723.  It describes (well, used to, before
they moved on) an ADPCM coder for 32 and 64 kbps.  The later G.726 was
introduced to add a 16 kbps coder.  Vendors not interested in G.726 would
still call themselves G.723 compliant.  No confusion for the customer.

Best regards,

   Marc