[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [IP-Optical] Re: Proposed text for the concatenation
Eric et all,
For each feature which is not defined by the ITU-T or the ANSI T1,
we could add a footnote refering to the following text: "this
feature is not defined either in ANSI T1 or in ITU-T Standards".
In addition to the proposed proposed text (see below), we could
add under parenthesis in which section each of these features are
defined within the draft.
--- proposed new section:
X. Relationship with SDH and SONET standards
Some of the features described in this specification are not defined
either in ANSI T1.105 (1995 and 2000), or in ITU-T G.707 (1996 and
2000). However, these features are useful and implemented in many
equipment's. All these features are optional but can be controlled
using this specification.
These features are: arbitrary contiguous concatenation, flexible
arbitrary contiguous concatenation and transparency. They have been
addressed in the relevant sections of this specification.
With the added text, everything gets our agreement.
> "Ong, Lyndon" wrote:
> It cannot be "proprietary" in the sense that you still need at least 2
> sets of people to implement it,
> if only 1 person implements it that will cause it to be removed. You
> could argue that this may lead to a
> feature that is weak and not useful because only a few implement it
> (and of course this NEVER
> happens with ITU-T specs ;o) but not that it is proprietary as in 1
> vendor only.
> Marking the document to show where something is not (currently!) in
> the ITU standard seems like
> a fair solution, and we can put this discussion to bed. If on the
> other hand there is a technical
> concern, this should be expressed.
> -----Original Message-----
> From: Guo-Qiang Wang [mailto:firstname.lastname@example.org]
> Sent: Wednesday, May 23, 2001 7:31 AM
> To: 'Maarten Vissers'; Dimitri Papadimitriou
> Cc: email@example.com; firstname.lastname@example.org;
> q11/15; t1x1.5
> Subject: RE: [IP-Optical] Re: Proposed text for the
> I agree with your opinion not putting proprietary stuff
> into GMPLS. The purpose
> of GMPLS is to define an open protocol platform to support
> public/private optical NNI
> signaling, NOT proprietary NNI. From interworking
> perspective, the openness of
> signaling interface has to be consistent with transport
> It does not exclude that someone wants piggyback the
> proprietary over GMPLS.
> It is O.K as long as they keep this in their cloud and
> nobody really care what
> they have inside. But it is not a GMPLS, whatever you call
> There is no need to introduce proprietary into GMPLS.
tel;home:+32 2 3434361
tel;work:+32 3 2408491
org:Alcatel Bell;IPO NSG - Antwerpen
title:Optical Networking R&S - Senior Engineer
adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM