[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Proposed text for the concatenation
Maarten,
>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...
Playing with words is fun ! Every word that is not part of the SDH/SONET
standards belongs only to ITU-T since it is a redefinition of SDH/SONET.
In the same way dynamic SDH/SONET circuit establishment (i.e. the use of a
control plane) is not part of SDH/SONET, it is a redefinition of SDH/SONET,
so GMPLS to control SDH/SONET is not in the GMPLS scope, and in the same way
GMPLS to control any other technology than IP is not part of the GMPLS
scope.
Transparency, arbitrary concatenation and flexible arbitrary concatenation
are not defined in SDH/SONET standards (is there a need ?). The use of a
signaling plane to control the SDH/SONET network is not defined in SDH/SONET
standards. All the types of SDH/SONET fast restoration schemes already
implemented (pre-computed, pre-signaled, etc) are not defined in SDH/SONET
standards, etc, etc.
So the conclusion is that the IETF should stop immediately to work on GMPLS
:-) We should have one different control plane for each layer :-) Cool you
will have a job for ten years, me too by the way !
Note that GMPLS doesn't do something strange about AUG-X/STSG-X, TUG-X/VTG,
they are defined in the standards, it is just a code type, like VC-4 or
STM-1. By the way, AUG-X in GMPLS was asked by your own colleagues.
Let's be serious please !
Rgds,
Eric
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
> > > >
> > > >
> > >