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

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

Hello Juergen,

Briefly,

> ...if we introduce flexible arbitrary contiguous concatenation

As you said flexible arbitrary contiguous concatenation is NOT part of the
current draft in WG last call. This feature is only being debated on the
mailing list as it was proposed to add it to the draft.

>We also have to state, that the combination of these proprietary features
with other reasonable proprietary or standard features is not always checked
and cannot be guaranteed.

Note that every toolbox has combination of features that doesn't make sense.
Sometimes it belongs to  the manufacturer itself (creativity) to find the
right combinations that could make sense to his customers and that will
differentiate his product from the others.

> It seems a common understanding now that we have at least to identify the
proprietary features

That's agreed but with the right terminology (e.g. not specified by
ITU-T/T1X1 etc).

> (either move them in an informative annex or a separate document). It
seems we don't have consensus to remove them at all.

Correct.

Kind regards,

Eric


-----Original Message-----
From: Heiles Juergen [mailto:Juergen.Heiles@icn.siemens.de]
Sent: Tuesday, May 29, 2001 2:36 AM
To: ccamp@ops.ietf.org; ip-optical@lists.bell-labs.com;
tsg15q11@itu.int; t1x15@t1.org
Subject: [IP-Optical] Re: Proposed text for the concatena tion


Eric and all,

let me again stress my view.
My major concern is to get usefull standards, RFCs, interworking agreements
or what ever you call it, that don't confuse people. If it is done in the
IETF, ITU, OIF, ... is an secondary issue. All have their pros and cons. As
soon as several bodies get involved it is getting more difficult to
synchronize the activities. With MPLS the IETF had both the transport and
control plane in its hands. With GMPLS it is different. GMPLS defines the
control plane signaling for already existing transport planes defined by
other bodies. Defining a control plane needs in my view solid knowledge of
the underlying transport plane. One of our (the Sonet/SDH guys) faults might
be that we got involved in the discussion to late.
I am following the GMPLS development for some time now and did sent some
comments on the email list over the last months. As I didn't get response
back and the comments seemed to be ignored I was thinking about stoping my
activities on the list. It changed at the Paris editing session when my
proposal for virtual concatenation was included. Thats why my name came on
the author list. But that doesn't mean that I am sure that the whole
document is correct or tht I fully agree with it as I hadn't time to go
through all the details togehter with the other GMPLS IDs. That might also
be the case for other people on the authors list. As I said before I
accepted the proprietary extensions at the Paris session as it seemed to me
that this is the way it works at the IETF (what does rough consensus mean?).
I brought up the issue of flexible arbitrary contiguous concatenation and
that triggered me. We try to define control plane support for a proprietary
transport plane features that we don't know much about. How are we sure that
the control plane support is correct. How are we sure that it can be
combined with other features. As Greg told me in a privat mail (see below)
flexible arbitrary concatenation cannot be supported by the STS group/AUG
signal type as explizit configuration (via management or signaling) of the
time slots is required. However the Sonet/SDH document says 
"STS Group-N is a collection of STS-1 SPE signals whose contiguous
concatenation relationship within the group need not be defined and is
permitted to change during the life of the STS-Group-N."
So that is not correct if we introduce flexible arbitrary contiguous
concatenation.
That is only one point, we may missed others as we don't have all the
information.
If the IETF accepts proprietary features, please make sure that you have the
necessary information. Otherwise you create a mess. Furthermore explizitly
state what is standard and what is not standard. Most readers don't have the
background knowledge of all the discussions we have.

Now how to deal with the proprietary features in the document:
It seems a common understanding now that we have at least to identify the
proprietary features (either move them in an informativ annex or a separate
document). It seems we don't have consensus to remove them at all.
We also have to state, that the combination of these proprietary features
with other reasonable proprietary or standard features is not always checked
and cannot be guaranteed. Note that it is also not possible to combine all
standard features, but that is described in the related standards.

Regards

Juergen



Hi Juergen, see comment below.  

Greg B.

-----Original Message-----
> (1)	Arbitrary concatenation (assuming standard sizes) is fairly minor
> tweak of standard contiguous concatenation, i.e., the framer just needs to
> be told the starting time slot (which has the pointer) and the remaining
> (arbitrary) time slots (which have the concatenation indication set).  No
> path overhead is used for this process.  It is strictly a line level
> operation, e.g., B3 is not recalculated.  This is suitable for LTE
equipment
> and has nice consequences for avoiding re-grooming.
	[Juergen Heiles]  How will you tell the framer the starting time
slot and the remaining timeslots? Via TMN cnfiguration or GMPLS signaling?
Not in-band using some SOH? If you also want to support the STS Group, AUG
or partially transparent signal type defined in GMPLS you need the in-band
information.

*** This is what GMPLS or some kind of signaling protocol is good for. But
of course I can set it up via management too. A set of time slot numbers vs.
a set of numbers! What's the big deal...  Now in-band I can run GMPLS over a
DCC channel so I don't really differentiate between this and GMPLS (or any
other signaling protocol based method).
The STS Group concept/transparency:  Yes, you're right I wouldn't support
the "arbitrary concatenation" over this.  Since, its a "transparent" service
and the concatenation must be automatically detected, i.e., without
signaling.  


_______________________________________________
IP-Optical mailing list
IP-Optical@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/ip-optical