Re: Proposed text for the concatena tion

[Heiles Juergen <Juergen.Heiles@icn.siemens.de>]

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.