[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Proposed text for the concatenation



Hello Lyndon,

Since we are not defining any standard for the SDH/SONET data plane but only
for the signaling plane, multiple *signaling* implementations will
interoperate without any problem !

Cheers,

Eric

-----Original Message-----
From: Lyndon Ong [mailto:lyndon_ong@eudoramail.com]
Sent: Saturday, May 19, 2001 8:01 AM
To: Jonathan Lang; 'Stephen Trowbridge'; Mannie, Eric
Cc: ccamp@ops.ietf.org; ip-optical@lists.bell-labs.com
Subject: RE: Proposed text for the concatenation


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
> > >
> > >
> >