RE: Proposed text for the concatenation

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

Hello Juergen,

A few brief comments (at least I tried):

- 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 reasonable set of features that matches the new SDH/SONET behaviors being
implemented in the new generation of equipment's.

- We are not designing the control plane to control only SDH/SONET as
defined by ITU-T and T1X1. We provide more control features than needed for
standardized SDH/SONET. It has no impact on those that want to use and
control strictly the standardized SDH/SONET.

- Some features don't need additional ITU-T or T1X1 standards, e.g.
transparency at the NNI. We already explained various scenarios where there
is no issue.

- We want to give the right to users and manufacturers to have their own
implementation agreements. If they don't want to be 100% compliant with the
ITU-T or T1X1 standard it is their right.

- About AUG/STS groups there is absolutely nothing new needed in SDH/SONET
to use it. That belongs to the new behaviors that we are defining. The GMPLS
behaviors are not defined in G.783. G.783 is a functional description, we
take a lot of freedom with it since we want to use signaling and routing
protocols.

What text do you propose for the draft ?

Is the following revised text acceptable:

--- proposed new section:

X. Relationship with SDH and SONET standards

Some of the features described in this specification are not defined neither
in ANSI T1.105 (1995 and 2000), nor in ITU-T G.707 (1996 and 2000). However,
these features are useful and implemented in many equipment's. All these
features are optional but can be controlled using this specification.

These features are: arbitrary contiguous concatenation, flexible arbitrary
contiguous concatenation and transparency. They have been addressed in the
relevant sections of this specification.

---------- End of text

Kind regards,

Eric


-----Original Message-----
From: Heiles Juergen [mailto:Juergen.Heiles@icn.siemens.de]
Sent: Wednesday, May 23, 2001 2:57 PM
To: Mannie, Eric; 'Fong, Man Wing'; 'Bernstein, Greg'; 'Bala
Rajagopalan'
Cc: ccamp@ops.ietf.org; ip-optical@lists.bell-labs.com; t1x1.5; q11/15
Subject: RE: Proposed text for the concatenation


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 informatio!
!
n 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


> -----Original Message-----
> From:	Mannie, Eric [SMTP:Eric.Mannie@ebone.com]
> Sent:	Tuesday, May 22, 2001 9:22 PM
> To:	'Fong, Man Wing'; 'Bernstein, Greg'; 'Bala Rajagopalan'
> Cc:	ccamp@ops.ietf.org; ip-optical@lists.bell-labs.com; t1x1.5; q11/15
> Subject:	RE: Proposed text for the concatenation
> 
> Hello Man Wing, Bala and All,
> 
> >I think Eric's proposed text gives a very good coverage on all cases
> 
> Thanks :-)
> 
> >and all we need is indicating which field is ... optional
> 
> Indeed everything is already optional in the draft except the signal type
of
> course:
> 
>   - CCT: set to zero to say no contiguous concatenation requested (default
> value)
>   - NCC: set to zero when CCT is set to zero (default value)
>   - NVC: set to zero to say no virtual concatenation (default value).
>   - Multiplier: set to one if one instance (default value).
>   - transparency: set to zero to say don't care (default value).
> 
> So there is no issue there, I will add a specific paragraph to re-enforce
> it.
> 
> In addition, when a downstream node receives an "incoming request" he can
> decide to accept it or to refuse it depending of what is requested,
> depending of the CAC process, depending of the customer profile, depending
> of the capabilities that it supports, etc.
> 
> The draft doesn't indicate what must be implemented of course.
> 
> >and all we need is indicating which field is standard....
> 
> Ok, I agree. Let's indicate in the draft the features that are not
> standardized in G.707 and T1.105, i.e. arbitrary concatenation, flexible
> concatenation, and transparency. Is there another one ? All the signal
types
> have an equivalent definition in the standards.
> 
> --- proposed new section:
> 
> X. Relationship with SDH and SONET standards
> 
> Some of the features described in this specification are not defined
neither
> in ANSI T1.105 (1995 and 2000), nor in ITU-T G.707 (1996 and 2000).
However,
> these features are useful and implemented in many equipment's. All these
> features are optional but can be controlled using this specification.> 
> 
> These features are: arbitrary contiguous concatenation, flexible arbitrary
> contiguous concatenation and transparency. They have been > described in
the
> relevant sections of this specification.
> 
> Arbitrary contiguous concatenation does not need any additional standard
to
> interoperate. It simply relaxes some limitations specified in the
> corresponding AINSI and ITU-T standards.
> 
> Transparency does not need any standard at the UNI since it is only
> implemented in the data plane at the NNI. This can be requested using the
> signaling at the UNI, independently of its implementation at the NNI.
> Interoperability between multiple manufacturers at the NNI can be achieved
> in different ways: through the use of a standard, an implementation
> agreement made by a forum, or an implementation agreement between two
> manufacturers (e.g. at the request of an operator).
> 
> Flexible arbitrary contiguous concatenation just need a very simple and
> obvious agreement to interoperate between multiple manufacturers. Again
this
> can be achieved in different ways: through the use of a standard, an
> implementation agreement made by a forum, or an implementation agreement
> between two manufacturers (e.g. at the request of an operator). A simple
> agreement could for instance simply indicate where is copied the original
> path overhead when "inverse multiplexing" locally a contiguously
> concatenated signal (e.g. in the first VC/SPE POH). --- I am not sure at
all
> about this paragraph, ideas are welcome, please help !
> 
> ---------- End of text
> 
> Agreed ? Comments ?
> 
> Comments from our ITU-T folks are welcome (really :-)
> 
> Kind regards,
> 
> Eric
> 
> -----Original Message-----
> From: Fong, Man Wing [mailto:MFong@WhiteRockNetworks.com]
> Sent: Tuesday, May 22, 2001 5:15 PM
> To: 'Bernstein, Greg'; Mannie, Eric; 'Maarten Vissers'
> Cc: ccamp@ops.ietf.org; ip-optical@lists.bell-labs.com
> Subject: RE: Proposed text for the concatenation
> 
> 
> Very good point, Greg. If I remember correctly, the initial email
initiated
> such a great discussion was someone asked about whether it was worth
> investing development effort on arbitrary concatenation. The bottom line
is
> if there is an appearing business case for the feature, then you will
> support it. As some of you (vendors) already indicated that your systems
> support AC because there are operators using and asking for this feature.
> There might be a lot of vendors and users supporting this or might be just
a
> few, but the fact is there are someone supporting it. When defining new
> protocols, I agree that we should consider and cover all cases, as long as
> any non-standard fields are optional.
> I think Eric's proposed text gives a very good coverage on all cases and
all
> we need is indicating which field is non-standard and optional.
> 
> Man Wing
> 
>