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

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

Hello Zhi,

>Yes, The signalling can be compliant to GMPLS. But what would that mean
>for compliance of the transport network? 

We already gave a number of scenarios where there are no interoperability
issue within the transmission plane (or transport network as you said) with
the proposed features.

>As I mentioned a while back, interworking is needed in two levels,
>signalling interworking AND transport interworking. 

Yes, and so what ? Why do you ignore these scenarios ? See previous comment.

>As for "multiple standards bodies", yes there are more than one
>standards bodies working on this, but they all work TOGETHER and align
>with each other, and the folks working on this are experts in the area
>who's been in the industry for MANY years. ANSI document specifies
>SONET. So does Telcordia GRs. ITU Recommendation specifies SDH. So does
>ETSI specs. 

I never went to this expert versus non expert discussion because this is
inappropriate from my point of view. Personally I consider that people
implementing the new generation of fully non-blocking SDH/SONET switches are
very good experts of SDH/SONET, whatever are the standardization bodies
where they are active at some point in the time.

Regards,

Eric




John Drake wrote:
> 
> 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
> >
> >