[CCAMP] New Liaison Statement, "LS/r IETF CCAMP work on YANG Alarm Module Submission (reply to IETF-LS16 )"

[Liaison Statement Management Tool <[e-mail]>]

Title: LS/r IETF CCAMP work on YANG Alarm Module Submission (reply to IETF-LS16 )
Submission Date: 2018-03-02
URL of the IETF Web page: https://datatracker.ietf.org/liaison/1564/

From: Hiroshi Ota <[e-mail]>
To: Daniele Ceccarelli <[e-mail]>,Fatai Zhang <[e-mail]>
Cc: Deborah Brungard <[e-mail]>,Scott Mansfield <[e-mail]>,Fatai Zhang <[e-mail]>,Alvaro Retana <[e-mail]>,Alia Atlas <[e-mail]>,Daniele Ceccarelli <[e-mail]>,Common Control and Measurement Plane Discussion List <[e-mail]>,[e-mail]
Response Contacts: 
Technical Contacts: 
Purpose: For information

Body: ITU-T Study Group 15 thanks IETF CCAMP WG for informing us about the adoption of a WG document https://tools.ietf.org/html/draft-ietf-ccamp-alarm-module-00 on “YANG Alarm Module” and requesting review on the module.

ITU-T Study Group 15 has been working, with collaboration with the ONF OIMT Group, on a Core Information Model in Recommendation G.7711 (ONF TR-512). The Core IM is neutral to any transport technology and is specified in UML, which is neutral to any management/control interface protocol. The Core IM can be pruned/refactored to provide a purpose-specific IM and translated into YANG code by automated tooling (xmi2yang). The OAM functionality, including Fault Management (FM) and Performance Monitoring (PM) is an area being modelled in G.7711 (ONF TR-512).

Regarding the alarm management, we would like to see the FM and PM modelling based on the same architecture, and to harmonize with the requirements in Recommendation G.7710. The YANG module should also allow transport technology specific augmentations.

Regarding the scope of the YANG Alarm Module, the draft should explicitly state that the modeling of how transport resource alarms are raised and cleared by the underlying transport instrumentation is out of the scope of this draft. Specifically, the modelling of defect detection, defect coordination into fault cause, consequent action, persistency verification declaring fault cause as failure, and raising failure as alarm and its subsequent clearing should belong to the SDO/group that owns the transport technology.

The alarm YANG draft adopts the X.733 alarm severities, but doesn’t support the function of alarm severity assignment (i.e., configuring the severity of an alarm type of a resource), i.e., the feature of the Alarm Severity Assignment Profile (ASAP) object of M.3160/M.3100 is not supported by the draft. Is this intended to be out of the scope of the alarm YANG draft?

For alarm reporting control, the alarm YANG draft supports only the simple alarm shelf function. It doesn’t support the rich features of the Alarm Reporting Control (ARC) function of M.3160/M.3100, which is required by G.7710.

We support the clear separation of resource alarm life-cycle from the operator and administrative life-cycle of an alarm.

Listed below are specific comments from our review of the YANG Alarm Module

1.   Section 4.2, paragraphs 5 & 6 discuss unknow alarm type at design time and dynamic addition of alarm types using string. Please note that the Spec Model approach of the Core Information Model (ITU-T Recommendation G.7711 Annex G) (also in ONF TR-512.7) provides a generic formal way to allow run time enhancement/decoration.

2.   Section 4.4, first paragraph, second last sentence: Add “and alarm type qualifier” so that the sentence becomes “This means that alarm notifications for the same resource, same alarm type and same alarm type qualifier are matched to update the same alarm instance.”

3.   Section 4.5: What is the relationship (dependency) among “alarm clearance”, “alarm closing”, and “alarm deleting”. Will administrative deleting automatically results in operator closing? Need more clarification among the three types of alarm life-cycle. Otherwise will cause inconsistent handling of alarm among different systems.

4.   Section 4.5.1, first paragraph, second line: Editorial error: “change severity” occurs twice.


We appreciate again for the chance to exchange information. We would like take this opportunity to inform IETF that we are currently working on a new draft Recommendation G.media-mgmt that describes the requirement and information & data model for transport media management.
Attachments:

No document has been attached