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

["BRUNGARD, DEBORAH A" <[e-mail]>]

Hi,

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-
Deborah

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

Manuel,

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.

Gert

From: Gabriele Maria Galimberti (ggalimbe) [mailto:[e-mail]]
Sent: 10 July 2014 09:11
To: [e-mail]<mailto:[e-mail]>; Gert Grammel; [e-mail]<mailto:[e-mail]>
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
[http://www.cisco.com/swa/i/logo.gif]


Gabriele Galimberti
Technical Leader
Cisco Photonics Srl

Via Philips, 12
20900 - Monza (MI)
Italy
www.cisco.com/global/IT/<http://www.cisco.com/global/IT/>

[e-mail]<mailto:[e-mail]>
Phone :[phone]
Mobile :[phone]
Fax :[phone]












From: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, July 9, 2014 3:01 PM
To: Gert Grammel <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
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.
Thanks,
Manuel

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

The authors of  https://datatracker.ietf.org/doc/draft-dharinigert-ccamp-g-698-2-lmp/ and https://datatracker.ietf.org/doc/draft-galikunze-ccamp-g-698-2-snmp-mib/
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