[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [IP-Optical] RE: Proposed text for the concatenation
Hi Neil,
Actually, I am not sure which operator design team has been referred to in some
of the latest emails on this list. Maybe I missed something, but I wasn't aware
that there was going to be an operators design team for GMPLS.
My understanding was that there would be a couple design teams in the TE
WG to nail down some requirements documents, but those did not seem
related to the current discussions.
Please elucidate if I missed something.
Thanks,
-Vishal
On Tuesday, May 29, 2001 1:24 PM, neil.2.harrison@bt.com
[SMTP:neil.2.harrison@bt.com] wrote:
> Hi Vishal.....I am waiting to hear what is happening with the operator
> 'design team'. It seems to me that their 1st task ought to be to create an
> agreed set of requirements.
>
> neil
>
> > -----Original Message-----
> > From: Vishal Sharma [mailto:vsharma87@yahoo.com]
> > Sent: 29 May 2001 20:57
> > To: 'Debanjan Saha'; 'Mannie, Eric'; '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
> >
> >
> > 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
> >