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

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

Hello again,

>  As stated in my previous e-mail, GMPLS is defined for signaling of
optical NNI. 

Not exactly, we defined it without speaking about UNI and NNI. Indeed GMPLS
is *being* defined for all kind of interfaces, UNI, public NNI, private NNI,
etc. The signaling runs between an ingress device and an egress device, or
between two endpoints.

Also the term optical is misleading. We didn't want to put optical
everywhere because GMPLS is multi-layer and multi-technology. The TDM layer
is not optical, the packet layer is not optical.

>The openness of GMPLS is that everybody has to understand what your are 
>talking about, both syntactically and semantically.

Semantically and syntactically the siganling is non ambiguous. The
particular agreement that you choose to use to implement the mechanism
described by the siganling doesn't belong to the signaling specification.
Most of GMPLS is generic, it means that you can apply it in different
contexts for different technologies. If two different standardization bodies
(but not the IETF of course) define how to implement the transparency, the
GMPLS signaling will work with both. The manufacturer will have to choose
one profile to implement and of course two different profiles could not
interoperate. The GMPLS signaling is neutral and generic with respect to the
way to implement transparency, flexible concatenation, etc.

>It is for inter-domain communication, 
>the smallest domain is NE itself. For intro-domain signaling, one can use
whatever 
>signaling protocols they choose as nobody would care of that.

GMPLS is for both. You need standards also at an intra-domain interface if
you want to buy boxes from two different manufacturers. Indeed the current
version of GMPLS is more focussing on the intra-domain interfaces than the
inter-domain interfaces.

>  If one (or two) vendor's approach is not called proprietary, then we have
to re-define 
> what the standard is. 

I don't work for a vendor :-) Who told you that some features are needed
only for one or two vendors ? How do you quantify the number of vendors that
are needed to have a standard ? We work on a consensus based and this draft
has 17 companies on it with 30 people. Usually it is much much less at the
IETF, you only have a small number of co-authors. I already gave a summary
of the process that we followed, all the meetings that we hold, all the
conference call that we hold, all the e-mails that we exchanged, etc.

You described one model in your e-mail, that's a valid model but this is not
THE (only) model. There are plenty of other models that can be fulfilled
with GMPLS.

Kind regards,

Eric

Eric, 
  As stated in my previous e-mail, GMPLS is defined for signaling of optical
NNI. 
The openness of GMPLS is that everybody has to understand what your are 
talking about, both syntactically and semantically. It is for inter-domain
communication, 
the smallest domain is NE itself. For intro-domain signaling, one can use
whatever 
signaling protocols they choose as nobody would care of that. 
  If one (or two) vendor's approach is not called proprietary, then we have
to re-define 
 what the standard is. 

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:   Mannie, Eric [SMTP:Eric.Mannie@ebone.com] 
Sent:   Wednesday, May 23, 2001 2:17 PM 
To:     Wang, Guo-Qiang [KAN:0V10:EXCH] 
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 
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 >>