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

["Bernstein, Greg" <GregB@ciena.com>]

Hi Maarten, what's your list of proprietary features mine includes:
(1) Extended concatenation types
(2) Semi-transparency feature (all except section and line -- and of course
path)
(3) Path group/AUG-N signal type
Are there others? I'd be happy to remove or include in the specification any
of the above IF we can move forward.  I'm also happy to work with any other
vendors and carriers on interoperability of these non-standard features.  If
some of the folks that attend ITU want to take these forward to ITU or T1
I'd be happy to co-author.

Greg B.
***********************************
Dr. Greg M. Bernstein
Senior Scientist, Ciena Corporation 

-----Original Message-----
From: Maarten Vissers [mailto:mvissers@lucent.com]
Sent: Monday, May 28, 2001 12:48 AM
To: Heiles Juergen
Cc: 'Mannie, Eric'; 'Fong, Man Wing'; Bernstein, Greg; 'Bala
Rajagopalan'; ccamp@ops.ietf.org; ip-optical@lists.bell-labs.com;
t1x1.5; q11/15
Subject: [IP-Optical] Re: Proposed text for the concatenation


All,

Let's treat all GMPLS specifications associated with non-standard
transport plane features as proprietary features, and either 
A) remove those from GMPLS, 
B) move those into an informal appendix of GMPLS or 
C) move those into a separate informal GMPLS extension document
addressing GMPLS constructs for non-standard (proprietary) transport
plane features.

In my opinion after all this debate, alternatives A or C seems best.

Regards,

Maarten


> 
> -------- Original Message --------
> Subject: RE: Proposed text for the concatenation
> Date: Wed, 23 May 2001 14:57:22 +0200
> From: Heiles Juergen <Juergen.Heiles@icn.siemens.de>
> To: "'Mannie, Eric'" <Eric.Mannie@ebone.com>,"'Fong, Man
> Wing'"<MFong@whiterocknetworks.com>,"'Bernstein, Greg'"
> <GregB@ciena.com>,"'Bala Rajagopalan'" <BRaja@tellium.com>
> CC: ccamp@ops.ietf.org,
> ip-optical@lists.bell-labs.com,"t1x1.5"<t1x15@t1.org>, q11/15
> <tsg15q11@itu.int>
> 
> The concatenation waves are going high here on the mailing list.
> I attended the Paris editing session and didn't complain about the
> proprietary solutions.
> However the ongoing discussion showed me several points:
> - When we start to introduce one proprietary solution we open the
> document for any proprietary solution, where will we stop (I want B3
> transparency and I over connection setup for containers (without POH)?
> Do we really want to define the signaling support for single, two, three
> vendor solutions. I would leave this to the vendors. They implemented a
> proprietary transport plane solution so they can also define their
> proprietary control plane solution. If we have a broader interest in the
> feature we should look at the application and consider if it should be
> standardized both for the transport plane and the control plane.
> - Remember that we define the control in order to support the transport
> plane and not vice versa. A stand alone transport plane makes sense (and
> has been in use for years), a stand alone control plane doesn't.
> Interworking at the control plane doesn't help much if the transport
> plane doesn't interwork. So it should be a common standardization
> activity both in the control and in the transport plane.
> - If we define something proprietary we need information about the
> feature, we cannot do it with guesses.
> - We also have to be careful with proprietary features as we don't know
> what implications they have on the transport plane, they might exclude
> each other. That can happen as we focus only on the control plane and
> don't care about the implications at the transport plane. We can
> generate a real mess.
> - I don't want to restrict new ideas and developments. Actually you
> cannot kill a good solution that fits network needs by blocking it from
> a standard. If someone builds it and shows its advantages operators will
> start to ask for it.
> 
> Now coming to Erics new proposed section:
> In my view the proposal makes it even worse. Just say this is a standard
> feature and this is a proprietary feature. Don't start to explain how we
> can come form a proprietary  feature to interworking or a standard. And
> don't start to explain how the feature could be implemented. It will
> bring you into more trouble. This is a control plane document, nothing
> more.
> 
> Arbitrary contiguous concatenation:
> What are the relaxed limitations. Either say nothing or define it in
> detail, but the later is not the task of this document.
> 
> Transparency:
> RS and MS transparency is a standard feature, while transparency of
> individual overhead bytes is not. You have to distinguish between the
> two.
> Transparency of individual bytes is an critical issue. You violate the
> layers and can screw up your whole management. In addition it is not
> real transparency what is needed, it is functional transparency. For
> example for B2. Or for the DCC bytes you might allow byte slips. But
> what implications has this on the DCN? It is easy to define a feature
> for the control plane and don't care about the transport plane
> implications.
> Although you are a strong supporter of transparency, you were very fast
> in dropping the already included B2 transparency. Because it is not a
> straight forward solution? Requires some awkward processing? And some
> people don't understand how it works? That might be also true for other
> features (flexible arbitrary concatenation). So why include one and not
> the other?
> 
> Flexible arbitrary contiguous concatenation:
> You started to describe a implementation. You have a certain solution in
> your mind. I think about a completely different approach. We both don't
> know it exactly, we just guess. Is this a good base to achieve
> interoperability.
> One problem I see has to do with the AUG7STS Group signal type, another
> proprietary feature. The AUG/STS group signal type provides some
> transparency concerning the underlying VC-3/4/4-Xc structure. However as
> pointer processing for the individual VCs is still required in case of
> multiplexing the network elements have to detect the VC-N structure by
> themselves using the pointer information (valid pointer, concatenation
> indication). But this doesn't work with flexible arbitrary contiguous
> concatenation, at least with the solution I have in mind. Additional
> information on the VCs that belong together is needed in-band (SOH?) if
> automatic detection should be supported. If it is not supported it
> cannot be part of a AUG/STS group signal type while all other types of
> concatenation can be. If it is supported you might not need a label set.
> A label for the first time slot is enough. The network element detects
> which other belong to the group. So from the currently available
> information it is difficult to tell if the control plane support is
correct.
> One other question. The Sonet/SDH GMPLS document says that virtual
> concatenation can be used with any contiguous concatenation. Although
> with flexible arbitrary contiguous concatenation as both require a label
> set?
> 
> Coming back to the AUG/STS group and TUG. I missed it in your new
> proposed section. It is a proprietary feature.
> Dimitri mentioned that AUG-X is defined in G.707 but not supported in
> G.783. It should be noted that AUG/TUG are not and were never intended
> to be networking entities. They were introduced as internal signal
> structures in order to better describe the SDH multiplex process.
> VC-11/12/2/3/4, MS and RS are the networking entities.
> A AUG/STS group or TUG provides some transparency concerning the
> underlying VC-N structure. IF you multiplex the signal you still have to
> do pointer processing for the individual VCs. As a AUG/STS group or TUG
> has no overhead of its own, any supervision has to be performed on the
> individual VCs. So what will it buy us ?(ok, ok better not to ask the
> question, some one supports it and has its good reasons to do so as it
> is the case for any of the above features)
> 
> Regards
> 
>         Juergen