Re: Proposed text for the concatenation

[Maarten Vissers <mvissers@lucent.com>]

Lyndon,

I had the hope that the message below would have been unambiguous:

--------------------------------
Subject: Is IETF redefining SONET/SDH?
Date: Fri, 18 May 2001 17:50:01 +0200
From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
To: ccamp-wg <ccamp@ops.ietf.org>

Well... from some of the emails posted to a few of the subIP area WGs
it may seem like that. However, it should be clear to everyone that we
are
not.
     
	It seems that the discussion is moving into that direction, but,
	let us be clear, we in the IETF shouldNOT be defining things
	that already have been defined or tried in the ITU. So we will not
	redefine SONET/SDH. We'd rather be in sync with what the ITU is
	defining in this area. It would be best to focus on defining the 
> the use of signaling/routing protocols to do provisioning and 
> restoration.
> 
Bert and Scott
-----------------------------------

The descriptions of arbitrary concatenation, flexible arbitrary
concatenation, AUG-X/STSG-X, TUG-X/VTG, STM-N/OC-N transparency are
beyond existing SONET/sDH standards and when included in GMPLS are
"redefinitions of SONET/SDH". Redefinitions of SDH/SONET are not within
the scope of GMPLS work...

Regards,

Maarten




Lyndon Ong wrote:
> 
> Perhaps it may reassure people to note that part of the IETF process
> involves removal of a feature if you cannot document interoperability of
> multiple implementations of the feature.  This means that if it can't be
> implemented or no one wants to do it, it will be taken out of the specs.
> 
> Cheers,
> 
> Lyndon
> 
> At 02:31 PM 5/18/2001 -0700, Jonathan Lang wrote:
> >Stephen,
> >   The intent of draft-ietf-ccamp-gmpls-sonet-sdh-00.txt is to define
> >signaling mechanisms, NOT to standardize SONET/SDH concatenation types --
> >there has been some confusion on the list about this.  Since vendors are
> >doing the "arbitrary concatenation" that Greg and Eric are describing, why
> >shouldn't we allow the signaling protocol to support this?  To me this seems
> >like fostering interoperability.
> >
> >-Jonathan
> >
> > > -----Original Message-----
> > > From: Stephen Trowbridge [mailto:sjtrowbridge@lucent.com]
> > > Sent: Friday, May 18, 2001 2:06 PM
> > > To: Mannie, Eric
> > > Cc: ccamp@ops.ietf.org; ip-optical@lists.bell-labs.com
> > > Subject: Re: Proposed text for the concatenation
> > >
> > >
> > > Eric,
> > > I think this goes against earlier email that says T1X1 and ITU-T
> > > are responsible for specification of SONET/SDH. There are two
> > > standardized forms of concatenation. Your proposal includes only
> > > one of the standardized forms and two that are, for the moment,
> > > proprietary. If we accept that SONET/SDH is the responsibility
> > > of T1X1/ITU-T, then for the moment I think the options can only
> > > be:
> > > - No concatenation
> > > - Standard Contiguous concatenation
> > > - Standard Virtual concatenation
> > > - (all others are, for the moment proprietary) vendor specific
> > >   concatenation types
> > > The other concatenation proposals must go to T1X1/ITU-T before
> > > they can be considered standardized.
> > > Regards,
> > > Steve Trowbridge
> > >
> > > "Mannie, Eric" wrote:
> > > >
> > > > Dear All,
> > > >
> > > > I am pleased to see so many people discussing so much on
> > > these mailing
> > > > lists, but now as an editor of
> > > draft-ietf-ccamp-gmpls-sonet-sdh-00.txt I
> > > > would like to make some progress.
> > > >
> > > > Please, carefully read the following text that clarifies
> > > the contiguous
> > > > concatenation part of the draft and that introduces one simple new
> > > > concatenation type.
> > > >
> > > > "This field indicates the type of SONET/SDH contiguous
> > > concatenation to
> > > > apply on the Elementary Signal. It is set to zero to
> > > indicate that no
> > > > contiguous concatenation is requested (default value). The
> > > values are
> > > > defined in the following table:
> > > >
> > > >        Bits   Contiguous Concatenation Type
> > > >       -----   ----------------------------------
> > > >        000     No contiguous concatenation requested
> > > >        001     Standard contiguous concatenation
> > > >        010     Arbitrary contiguous concatenation
> > > >        011     Flexible arbitrary contiguous concatenation
> > > >       others   Vendor specific concatenation types
> > > >
> > > > Standard contiguous concatenation refers to the contiguous
> > > concatenation as
> > > > it is defined in SDH G.707 and SONET ANSI T1.105. Arbitrary
> > > contiguous
> > > > concatenation relaxes the limitations of these standards in
> > > terms of the
> > > > location where a contiguous signal can start, and in terms
> > > of the number of
> > > > concatenated VC's/SPE's that can compose this signal.
> > > >
> > > > Flexible arbitrary contiguous concatenation is an
> > > optimisation of the
> > > > arbitrary contiguous concatenation that allows to "inverse
> > > multiplex" a
> > > > contiguously concatenated signal on a per multiplex
> > > section/line basis. In
> > > > order to be effectively used, an upstream node must
> > > indicate that its
> > > > supports this feature to its immediate downstream node,
> > > using the CCT field.
> > > > The downstream node can in that case use that feature and
> > > return a list of
> > > > labels, one for each element of the "inverse multiplex";
> > > instead of one
> > > > single label indicating the beginning of the contiguous signal.
> > > >
> > > > The three types of contiguous concatenation defined here
> > > before defines
> > > > indeed a hierarchy of flexibility in the contiguous
> > > concatenation. If
> > > > selected, the flexible arbitrary contiguous concatenation,
> > > indicates that
> > > > any of the three types of contiguous concatenation can be
> > > chosen by the
> > > > downstream node. It is up to the downstream node to choose
> > > the one that it
> > > > wants to use. The upstream node, when receiving the labels from the
> > > > downstream node, may accept or refuse what was proposed."
> > > >
> > > > Please send me your technical comments about the technical
> > > correctness of
> > > > this text only. Please, delay discussions about the
> > > usefulness of these
> > > > features and the way to implement them to another time.
> > > What is important is
> > > > that each feature works. Your profile, implementation, or
> > > configuration
> > > > should determine what you like and what you want to
> > > support, not this
> > > > signalling.
> > > >
> > > > Take your time to read the text and to answer, it is 10PM
> > > in my time zone
> > > > and I will leave my office. I'll be back on Monday morning
> > > to read your
> > > > answers.
> > > >
> > > > Many thanks to all of you and have a nice week-end.
> > > >
> > > > Kind regards,
> > > >
> > > > Eric
> > > >
> > > > Eric Mannie
> > > > Technology & Standards Strategy Manager
> > > > Network Engineering Strategy
> > > > EBONE
> > > >
> > > > Terhulpsesteenweg 6A
> > > > 1560 Hoeilaart - Belgium
> > > >
> > > > Tel:    +32 2 658 56 52
> > > > Mobile: +32 496 58 56 52
> > > > Fax:    +32 2 658 51 18
> > > > E-mail: eric.mannie@ebone.com
> > > >
> > > >
> > >
begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:mvissers@lucent.com
title:Consulting Member of Technical Staff
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard