Re: Proposed text for the concatenation

[Maarten Vissers <mvissers@lucent.com>]

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
begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:mvissers@lucent.com
title:Consulting Member of Technical Staff
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard