RE: [IP-Optical] RE: Proposed text for the concatenation

[Vishal Sharma <vsharma87@yahoo.com>]

Debanjan,

Excellent idea! I think this is what I had also proposed a few days ago,
when Eve had first provided a reference to the BT document.
However, I think it would be really helpful (now, and in the future) to
have all the carrier requirements articulated in one place.

That would not only allow us to keep track of the various issues, but
also eliminate redundant ones (so that duplication does not needlessly
crowd the field and our discussions), prioritize the issues, and start 
addressing
them one-by-one in a systematic manner, beginning with the most relevant
or most substantive ones.

Thanks,

-Vishal

On Tuesday, May 29, 2001 11:59 AM, Debanjan Saha [SMTP:DSaha@tellium.com] 
wrote:
> Monica,
> As Eric said, it's very difficult to keep track of all
> the questions that have been asked. Would someone (possibly
> you :-)) put them together in one list so that we all can
> discuss them in a more coordinated way. Thanks in advance,
> Debanjan
>
> -----Original Message-----
> From: Mannie, Eric [mailto:Eric.Mannie@ebone.com]
> Sent: Tuesday, May 29, 2001 1:20 PM
> To: 'Lazer, Monica A, NNAD'; 'Bernstein, Greg'; ccamp@ops.ietf.org
> Cc: ip-optical@lists.bell-labs.com
> Subject: RE: [IP-Optical] RE: Proposed text for the concatenation
>
>
> > The text does not look good
>
> Monica, I didn't sent the same e-mail and text again, apparently one
> exploder is re-sending old e-mails, you read the text that was send last
> week :-)
>
> Anyway, it should be time for everybody to calm down and to behave.
>
> Eric
>
> -----Original Message-----
> From: Lazer, Monica A, NNAD [mailto:mlazer@att.com]
> Sent: Tuesday, May 29, 2001 5:46 PM
> To: 'Bernstein, Greg'; Mannie, Eric; ccamp@ops.ietf.org
> Cc: ip-optical@lists.bell-labs.com
> Subject: RE: [IP-Optical] RE: Proposed text for the concatenation
>
>
> Eric,
> The text does not look good. Many have expressed concerns about having
> support for arbitrary concatenation show as if it is a standard transport
> feature.
> I am flabbergasted by the fact that many comments, which expressed the same
> or similar concerns from many companies, have simply been ignored.
> Below are comments that   I sent out. They were not addressed or replied to.
> So I assumed that there were no objections. I now see that they were
> ignored.
>
> Eric,
> Below I have some additional specific comments for the document GMPLS
> Extensions for SONET and SDH Control
>
>
> CCT field (3 bits)
> Since arbitrary contiguous concatenation is not a standard concatenation, it
> falls within the vendor proprietary set of solutions.
>
> So the CCT bits may be used as follows:
> 000	No contiguous concatenation requested
> 001	Standard contiguous concatenation
> others	Vendor specific contiguous concatenation
>
> Alternatively, a better solution is to use only 2 bits for this field and
> use one bit to show whether contiguous concatenation is requested and the
> second bit to show whether it is standard or non-standard contiguous
> concatenation.
>
>
> NCC field (16 bits)
> This information is not sufficient.
> NCC needs better description than a zero or non-zero number.
>
> SDH and SONET Labels
>
> Text in this section (Section 3, paragraphs 5 and 6) indicates that the
> GMPLS proposal limits virtual concatenation to remain within a single
> (component) link. If I understand this correctly, it means that GMPLS will
> not allow inverse multiplexing (virtual concatenation) in the transport
> plane if it requires different component links. This is too limiting.
>
> Annex 1 (sent out by Eric Mannie on 5/22)
> Defines another type of concatenation - Flexible arbitrary contiguous
> concatenation without describing precisely how it affects the OH bits. This
> means that it will be impossible to have this type of concatenation in a
> multi vendor environment based only on the GMPLS signaling. If the transport
> plane is proprietary, having the option in the signaling message will not
> fix the interoperability problem between two different vendors supporting
> their proprietary versions of arbitrary concatenation.
>
> Annex 2 (sent out by Eric Mannie on 5/22)
> Arbitrary contiguous concatenation needs definition work for
> interoperability.
> Flexible arbitrary contiguous concatenation may be available today to
> support contiguous signals, but it is not defined in the current standards.
> Clear agreements on OH usage are needed between supporting vendors.
> Maintenance and tracking of the signal needs to be well understood.
>
>
>
> Monica A. Lazer
> Advanced Transport Technology and Architecture Planning
>
> 908 234 8462
> mlazer@att.com
>
>
> -----Original Message-----
> From: Bernstein, Greg [mailto:GregB@ciena.com]
> Sent: Monday, May 21, 2001 11:21 PM
> To: Mannie, Eric; ccamp@ops.ietf.org
> Cc: ip-optical@lists.bell-labs.com
> Subject: [IP-Optical] RE: Proposed text for the concatenation
>
> The text looks good Eric.  I'm happy to help with any text to make the
> definition of arbitrary flexible concatenation clearer.
>
> Greg B.
>
>
> -----Original Message-----
> From: Mannie, Eric [mailto:Eric.Mannie@ebone.com]
> Sent: Friday, May 18, 2001 1:28 PM
> To: ccamp@ops.ietf.org
> Cc: ip-optical@lists.bell-labs.com
> Subject: Proposed text for the concatenation
>
>
> 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.
>
> This is not a definition. For this to have any value as a standard document,
> it needs to be submitted to appropriate tranport plane standards bodies.
> This is support for proprietary solutions. Not more, not less.
>
> 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
>
>
>
>
> _______________________________________________
> IP-Optical mailing list
> IP-Optical@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/ip-optical
>
> _______________________________________________
> IP-Optical mailing list
> IP-Optical@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/ip-optical
>
> _______________________________________________
> IP-Optical mailing list
> IP-Optical@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/ip-optical