Re: Proposed text for the concatenation

[Maarten Vissers <mvissers@lucent.com>]

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
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