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