Re: Proposed text for the concatenation

[Stephen Trowbridge <sjtrowbridge@lucent.com>]

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