[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [IP-Optical] RE: Proposed text for the concatenation
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