RE: [T1X1.5] RE: Proposed text for the concatenation

[John Drake <jdrake@calient.net>]

Monica,

When you say standards compliant, which standards bodies are you
considering?  I.e., from one of Eric's
notes I got the impression that there were actually multiple bodies that had
defined SONET/SDH features.
Further, we could indicate that implementations of GMPLS signalling are are
GMPLS compliant - see 'self
defining term' in the index of Knuth vol 1.

Thanks,

John

-----Original Message-----
From: Lazer, Monica A, NNAD [mailto:mlazer@att.com]
Sent: Wednesday, May 23, 2001 1:42 PM
To: 'Heiles Juergen'; '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: [T1X1.5] RE: Proposed text for the concatenation


>From an operator's perspective, it is essential to clearly flag the features
that are standards compliant from those, which deviate from existing
standards, even when they are improvements to the standards. The reason for
this is rooted in the need to have the ability to identify all the relevant
issues when inter-working network elements from multiple vendors in the same
networks, while taking advantage of new non-standard features.

Monica A. Lazer
Advanced Transport Technology and Architecture Planning

908 234 8462
mlazer@att.com


-----Original Message-----
From: Heiles Juergen [mailto:Juergen.Heiles@icn.siemens.de]
Sent: Wednesday, May 23, 2001 8:57 AM
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: [T1X1.5] 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
>
>