Re: [CCAMP] draft-dharinigert-ccamp-g-698-2-lmp and draft-galikunze-ccamp-g-698-2-snmp-mib

"BRUNGARD, DEBORAH A" <> Fri, 18 July 2014 20:11 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A95E31B2A69 for <>; Fri, 18 Jul 2014 13:11:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MANGLED_AVOID=2.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YLe7DzMbrVoa for <>; Fri, 18 Jul 2014 13:10:57 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EC61B1B2A67 for <>; Fri, 18 Jul 2014 13:10:56 -0700 (PDT)
Received: from unknown [] (EHLO by with ESMTP id (envelope-from <>); Fri, 18 Jul 2014 20:10:55 +0000 (UTC)
X-MXL-Hash: 53c97f4f18014396-c91895768acb4afecb957eb96a9ec1372214b515
Received: from unknown [] (EHLO by over TLS secured channel with ESMTP id (envelope-from <>); Fri, 18 Jul 2014 20:10:13 +0000 (UTC)
X-MXL-Hash: 53c97f251ea60eda-46cba2ea632d9d64afde193d009c1cd8e47ca43b
Received: from (localhost []) by (8.14.5/8.14.5) with ESMTP id s6IKACeo010136; Fri, 18 Jul 2014 16:10:13 -0400
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id s6IKA2s6009908 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Jul 2014 16:10:07 -0400
Received: from ( []) by (RSA Interceptor); Fri, 18 Jul 2014 20:09:46 GMT
Received: from ([]) by ([]) with mapi id 14.03.0174.001; Fri, 18 Jul 2014 16:09:46 -0400
To: Gert Grammel <>, "Gabriele Maria Galimberti (ggalimbe)" <>, "" <>, "" <>
Thread-Topic: [CCAMP] draft-dharinigert-ccamp-g-698-2-lmp and draft-galikunze-ccamp-g-698-2-snmp-mib
Thread-Index: Ac+XAT5ztVyFVTboTtq7YqBZHj6KHgEc6cpwADT8aQAA0Vs4MADNIdcw
Date: Fri, 18 Jul 2014 20:09:46 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
x-originating-ip: []
Content-Type: multipart/related; boundary="_004_F64C10EAA68C8044B33656FA214632C80CB8D1DCMISOUT7MSGUSRDE_"; type="multipart/alternative"
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public, General SSNFP Patterns II
X-AnalysisOut: [v=2.0 cv=Tf4hQ2sh c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a]
X-AnalysisOut: [=H3iOxsc2R5wA:10 a=ofMgfj31e3cA:10 a=jhmz5UIrLHEA:10 a=BLc]
X-AnalysisOut: [eEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=48vgC7mUA]
X-AnalysisOut: [AAA:8 a=AUd_NHdVAAAA:8 a=OUXY8nFuAAAA:8 a=JiJVGvLU_ebjdW6u]
X-AnalysisOut: [AcYA:9 a=CjuIK1q_8ugA:10 a=gUn9MpX-c_cA:10 a=lZB815dzVvQA:]
X-AnalysisOut: [10 a=p3EP0m9KMXkA:10 a=JfD0Fch1gWkA:10 a=peF9eE_zjQwA:10 a]
X-AnalysisOut: [=YW0Io7EaZ3zhjENY:21 a=UEI8QimJ87N5uAdl:21 a=yMhMjlubAAAA:]
X-AnalysisOut: [8 a=SSmOFEACAAAA:8 a=4vgIikcKAAAA:8 a=DcnvcS5-yquDsFeAk4oA]
X-AnalysisOut: [:9 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a]
X-AnalysisOut: [=frz4AuCg-hUA:10 a=ojWHkEdhfyMA:10 a=uf5W-bUQJFWA-vGR:21 a]
X-AnalysisOut: [=RzCmTiyF194HY9VP:21 a=7pr6eGljs0JSVRnx:21 a=eS-SIszKxxoeb]
X-AnalysisOut: [kHINWQA:9 a=HXjIzolwW10A:10 a=IkHgBtt53EAdg95B:18]
X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)]
Subject: Re: [CCAMP] draft-dharinigert-ccamp-g-698-2-lmp and draft-galikunze-ccamp-g-698-2-snmp-mib
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, 18 Jul 2014 20:11:01 -0000


Seeing the lack of discussion, I'll repeat some of the items which I noted from previous meetings. As I noted at the last meeting, the documents have improved to align better with ITU's data plane. Most of the remaining concerns were on non-alignment with ITU's data plane terminology and the recent ITU work on managing G.698.2 and optical interfaces, e.g. G.872 (2012), G.872 Amd. 1 (2013), and G.874.1 (2012:

-          Gert, I think your question below has been asked several times at ccamp - why specific for G.698.2, why not generalize this? In the lmp document, continue to name as "BL_", whereas the mibs document has been aligned with RFC3591, to say "OCh".

-          In the lmp draft, it says "BL_ApplicationCode". It has two parameters, "single-channel" and "vendor transceiver". This implies that G.698.2 (or a "BL") allows for "vendor transceiver application codes". But G.698.2 only supports compatibility for the standard codes. This was the main concern of the Q6 Rapporteurs on our WSON work and these drafts, that we infer compatibility for the data plane when it is not appropriate. As they said, the parameters are necessary,  but not sufficient to guarantee compatibility.

-          G.872 and G.874 use the generic term, Application Identifier (AI) and Central Frequency to characterize an OCh. Malcolm had mentioned this at our previous meetings. AI covers both standard codes and vendor identifiers. Using these terms would cover your need to include proprietary (vendor) identifiers, and not infer these are equal to application codes. Also, "Central frequency" (vs. wavelength) is used in ITU's data plane work and in other CCAMP work as a more precise term. By adopting "single channel" (vs. BL) terminology and "OCh" and "AI", you will align better with ITU and other CCAMP documents. And hopefully address much of the concern on how you are managing/modelling these interfaces.

-          RFC3591 has monitoring mibs for power and read capability of "current input power". So why introduce "BL" specific mibs for this monitoring? These can be referenced from RFC3591 or as extensions to RFC3591 if the naming doesn't match.

-          The only parameter missing is setting the output power? I don't think it is supported though by G.874.1? Have the authors contributed to ITU-T to request it be added?

Hopefully this helps-

From: CCAMP [] On Behalf Of Gert Grammel
Sent: Monday, July 14, 2014 2:15 PM
To: Gabriele Maria Galimberti (ggalimbe);;
Subject: Re: [CCAMP] draft-dharinigert-ccamp-g-698-2-lmp and draft-galikunze-ccamp-g-698-2-snmp-mib


Overall it is difficult for the authors to grasp in what respect a G.698.2 interface would differ from an optical interface in terms of supervision and configuration capabilities. Also link management is already around since a while for a set of technologies. Application codes defined in G.698.2 are link characteristics which should be discovered however there seem still to be some reluctance the way we looked at it. It would be great if we could get substantial feedback on the list on how to supervise a G.698.2 interface should be supervised and monitored.


From: Gabriele Maria Galimberti (ggalimbe) []
Sent: 10 July 2014 09:11
To:<>; Gert Grammel;<>
Subject: Re: [CCAMP] draft-dharinigert-ccamp-g-698-2-lmp and draft-galikunze-ccamp-g-698-2-snmp-mib

Hi Manuel,

I absolutely agree.  Also retrieving the TX and RX (measured) power is fundamental for trouble shooting.

Best Regards,


Gabriele Galimberti
Technical Leader
Cisco Photonics Srl

Via Philips, 12
20900 - Monza (MI)
Phone :+39 039 2091462
Mobile :+39 335 7481947
Fax :+39 039 2092049

From: "<>" <<>>
Date: Wednesday, July 9, 2014 3:01 PM
To: Gert Grammel <<>>, "<>" <<>>
Subject: Re: [CCAMP] draft-dharinigert-ccamp-g-698-2-lmp and draft-galikunze-ccamp-g-698-2-snmp-mib

Hello CCAMPers,

I worked through the last ccamp minutes and try to catch the issues with these both documents.
The values in the drafts are corresponding to ITU-T G.698.2.
Why should it not be possible to set power and wavelength in the Black Link case?  Every transponder could be configured  and maintained in the same manner.

From: CCAMP [] On Behalf Of Gert Grammel
Sent: Thursday, July 03, 2014 10:57 PM
To: CCAMP (<>)
Subject: [CCAMP] draft-dharinigert-ccamp-g-698-2-lmp and draft-galikunze-ccamp-g-698-2-snmp-mib

The authors of and
Put new versions out and would encourage discussion on the list. We'd like to collect input before the meeting to a void last-minute surprises. We also work in parallel on a draft Liaison request to clarify with SG15 Q6 and Q14 to clarify comments made at previous ccamp meetings.

As a reminder: the drafts define parameters to enable management and Link Management of G.698.2 compliant interfaces.
Gert Grammel