Re: [CCAMP] G.698.2 MIB concerns addressed by ITU-T colleagues

Fatai Zhang <> Fri, 14 March 2014 01:22 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 7FBC81A07D4 for <>; Thu, 13 Mar 2014 18:22:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.747
X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 93yiHwo--k81 for <>; Thu, 13 Mar 2014 18:22:34 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 06B841A07BD for <>; Thu, 13 Mar 2014 18:22:33 -0700 (PDT)
Received: from (EHLO ([]) by (MOS 4.3.7-GA FastPath queued) with ESMTP id BEO00260; Fri, 14 Mar 2014 01:22:25 +0000 (GMT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Fri, 14 Mar 2014 01:21:32 +0000
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Fri, 14 Mar 2014 01:22:23 +0000
Received: from ([]) by ([]) with mapi id 14.03.0158.001; Fri, 14 Mar 2014 09:22:18 +0800
From: Fatai Zhang <>
To: Dieter Beller <>, "" <>, "" <>
Thread-Topic: [CCAMP] G.698.2 MIB concerns addressed by ITU-T colleagues
Thread-Index: Ac8+yaJXH8vwWfWRQbyQfVfsHVxr9P//hS+A//7U8tA=
Date: Fri, 14 Mar 2014 01:22:16 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: zh-CN, en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_F82A4B6D50F9464B8EBA55651F541CF85CAD7EE6SZXEMA504MBSchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Subject: Re: [CCAMP] G.698.2 MIB concerns addressed by ITU-T colleagues
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion list for the CCAMP working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 14 Mar 2014 01:22:39 -0000

Hi Ruediger and other authors,

I agree with Dieter's point.

Is it really known what information can/should be exchanged and what can/should not? How to justify?

In addition, do you see any draft about LMP ext over UNI for other technologies such as OTN, WSON, SDH, etc. defined in CCAMP?

If no, why not make this draft more generic?

I would also kindly suggest the authors have a look at the OIF UNI IAs (UNI 1.0 & UNI 2.0 and their difference) to see if it really makes sense to have LMP ext over UNI.

Best Regards


From: CCAMP [] On Behalf Of Dieter Beller
Sent: Thursday, March 13, 2014 11:17 PM
Subject: Re: [CCAMP] G.698.2 MIB concerns addressed by ITU-T colleagues

Hi Ruediger,
On 13.03.2014 15:36,<> wrote:
Hi all,

Huub and Dieter mentioned during the CAMP session in London that ITU-T Q6 has some concerns about additional values in document.

Huub mentioned that - I asked a follow-up question regarding the exchange of power values (see below).

Gabriele mentioned the reason for adding these values and we will update the documents with explaining text. During our common meeting with ITU-T at IETF  86 Pete Anslow mentioned: Transmit power may be useful, beyond that I cannot think of anything else you may want to set.

If you guys have still concerns lets discuss these points on the list.
The question I have is the following:

The draft defines LMP protocol messages (sub-objects) to convey the (current?) Output Power at the Ss
reference point and the Current Input Power at the Rs reference point from OXC1 to OLS1 and OXC2 to OLS2,
respectively. This is my interpretation. Now, I would like to understand for what purposes these power values
are exchanged.

My suggestion at the meeting was to add some explanatory text to the draft describing the application that
makes use of these values, i.e., that motivates the definition of these LMP extensions.


Best regards



CCAMP mailing list<>