Re: [IP-Optical] Re: Proposed text for the concatenation

[Zhi-Wei Lin <zwlin@lucent.com>]

Hi,

A few general comments...

Seems we all have different ideas about what "proprietary" means and
what "standard" means. I hear two things:

Proprietary #1 -- if more than two vendors implement, then it is not
proprietary. Then what is it? Standard?

Proprietary #2 -- any extensions or differences from that which is
specified by a standards body. This includes features that may be
supported by 99% of the vendors, but is still proprietary if not
introduced and standardized by the standards body.


The other thing I see in the discussion is...some features may belong in
the document while others may not.

==> What is the criteria that we are using in evaluating which feature
gets into the document, and which feature stays out? There are many
vendors in the industry. I am fairly certain that each vendor will have
a "unique" capability that their box can support. Some of these features
may be VERY similar amongst a set of vendors. If we open up to the
proprietary #1 definition, I am sure that there are many additional
features that will need to be added. 

Let's be democratic...define what evaluation metric is used, then let's
compare features and allow ALL vendors the opportunity to prove to meet
the metric...

or decide only standards-based capability is supported, but mention that
control plane can always be extended to support proprietary
extensions...

Zhi



"Mannie, Eric" wrote:
> 
> Hello Guo-Qiang,
> 
> I would like again to clarify a few important points:
> 
> - we are doing signaling and not an implementation profile, not a data plane
> specification.
> - ****almost all the features are optional****.
> - put the field to zero to say: "no way, I don't want to hear about that".
> - 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.
> - a basic signaling implementation that allows *only* to open a VC-4 circuit
> is compliant.
> - you can ignore what you don't want to implement or just pick up what you
> want.
> - GMPLS is a toolbox, we don't say which tools to use, it is up to you to
> decide.
> 
> We don't try to restrict the draft to only the features that are implemented
> or implementable by *all* the manufacturers because this is an endless
> discussion and that's exactly what is happening now.
> 
> Some features that we want to control are not standardized by the ITU-T, but
> they exist, they are implemented by manufacturers, they are asked by
> operators. They will not disappear because a few folks don't want to hear
> about them.
> 
> We are speaking about "we would like to have a screwdriver in the toolbox",
> the guys that only use hammers say "we don't want to see screwdrivers in the
> toolbox" we just use nails. Let's be open and fair and let's the guys that
> like screws the right to use them (that's called democracy).
> 
> Why are some people so afraid by having signaling features that they don't
> have to support. Why would you like to prevent others to do what they want
> and need if it does not impact you.
> 
> We are not trying to find the minimum set of features that everybody agreed
> on, we don't want neither to incorporate everything. We want to have a
> sufficiently large set of features that can allow to implement a powerful
> new kind of behavior for SDH/SONET.
> 
> GMPLS supports your "public/private optical NNI", and *in addition* what you
> call a proprietary NNI. Why are you so disturbed by the fact that it does
> more than *you* need ?
> 
> As you said "purpose of GMPLS is to define an open protocol platform", what
> is your definition of "open" in that context ?
> 
> Kind regards,
> 
> Eric
> 
> -----Original Message-----
> From: Guo-Qiang Wang [mailto:guoqiang@nortelnetworks.com]
> Sent: Wednesday, May 23, 2001 4:31 PM
> To: 'Maarten Vissers'; Dimitri Papadimitriou
> Cc: ccamp@ops.ietf.org; ip-optical@lists.bell-labs.com; q11/15; t1x1.5
> Subject: RE: [IP-Optical] Re: Proposed text for the concatenation
> 
> Maarten,
>   I agree with your opinion not putting proprietary stuff into GMPLS. The
> purpose
> of GMPLS is to define an open protocol platform to support public/private
> optical NNI
> signaling, NOT proprietary NNI. From interworking perspective, the openness
> of
> signaling interface has to be consistent with transport interface.
>   It does not exclude that someone wants piggyback the proprietary over
> GMPLS.
> It is O.K as long as they keep this in their cloud and nobody really care
> what
> they have inside. But it is not a GMPLS, whatever you call it.
>   There is no need to introduce proprietary into GMPLS.
>   Regards,
> G.Q Wang
> Emerging Network Technology
> Nortel Networks
> Tel: (613)765-4195 (ESN 395-4195)
> Fax: (613)768-1140
> guoqiang@nortelnetworks.com
> -----Original Message-----
> From:   Maarten Vissers [SMTP:mvissers@lucent.com]
> Sent:   Tuesday, May 22, 2001 6:34 AM
> To:     Dimitri Papadimitriou
> Cc:     ccamp@ops.ietf.org; ip-optical@lists.bell-labs.com; q11/15; t1x1.5
> Subject:        [IP-Optical] Re: Proposed text for the concatenation
> Dimitri, Eric,
> When one or two vendors or one or two operators would like to support a
> particular feature in their equipment/network, it doesn't imply that
> there is general agreement to add such feature in to the standard. Only
> those features for which interworking is agreed end up in the standard.
> Some of the others may find its way into an informative annex/appendix
> in the standard, clearly marked as such to stress that you can not
> expect network support for this feature, nor interworking. Many other
> features do not make it at all into the standard in the absence of
> sufficient support; those are completely rejected.
> This process is present in any standards body as far as I can see,
> including the IETF. Many proposals in IETF are rejected, like in other
> standards bodies.
> At this moment we argue about features to be supported by the control
> plane for the automatic switched optical network (consisting of
> SDH/SONET, WDM/pre-OTN and OTN networks) for which specifications the
> ITU-T and T1X1.5 are responsible. Any issues are to be addressed by
> these standards bodies.
> Those organisations not being a member of ITU-T can address their issue
> in T1X1.5, and if support is obtained members of T1X1.5 being also a
> member of ITU-T can/will then forward this issue to ITU-T for world wide
> consideration.
> For the case a new feature (idea) is developed for the transport plane,
> any organisation (vendor, operator) can contribute this to ITU-T and/or
> T1X1.5 to seek support, and to make it part of the standard. If this
> isn't done, the feature seems to be unimportant for standardisation (and
> thus interworking). For this case, there is no rationale to add control
> plane functionality for this feature to the transport plane's control
> plane specification; standard transport plane UNIs and NNIs are not
> supporting this feature, so why would the associated standard control
> plane UNI/NNI support it.
> This doesn't imply that the feature is not developed; the feature is
> developed as a proprietary extension of the transport plane, control
> plane and management plane standards. Many vendors and operators offer,
> require and operate proprietary features today, and (most likely) will
> continue to do so in the future.
> 
> The IETF is extending the control plane definitions of MPLS with optical
> network specific constructs to be able to use this extended control
> plane specification as part of the automatic swithced optical network.
> As part of this work, vendors have requested control plane extensions to
> support their proprietary transport plane features. In order to do so,
> these proprietary transport plane features had to be defined to some
> level of detail in the control plane specification... otherwise nobody
> understood what was controlled. And what a marvelous interactions we
> have seen in the last few weeks on these transport plane specifications
> of concatenation, transparency and adaptive pointer processing modes
> (AUG/STSG/TUG/VTG)... :-( .  This clearly showed that these issues are
> all but control plane issues; these are transport plane issues and are
> outside the charter of GMPLS (and IETF).
> As all standards bodies progress their work by means of received
> contributions, it is peculiar to read in messages from people active
> within the IP standard body (i.e. IETF) that the transport plane
> standards bodies (i.e. ITU-T and T1X1.5) are not adequately reacting to
> the needs of the transport plane. Where were their contributions to the
> transport plane standards bodies ...?
> And the following message from IETF to ITU-T will no doubt be received
> with open arms :-( : "i propose here to postpone the edition of this
> G.783 document in order to include the needed changes in order to
> synchronize the ITU-T specification with the last GMPLS SDH/Sonet
> document version (Ed. Eric Mannie) which has demonstrated that current
> ITU-T standards clearly don't cover some specific functions like
> flexible ACC". WOW... can we ever be more respectful and friendly...?
> 
> Regards,
> Maarten << File: Card for Maarten Vissers >>