Re: [CCAMP] Second review of draft-ietf-ccamp-alarm-module-01

[Qin Wu <[e-mail]>]

Stefan:
Remove the comments I have reached agreement.
See my followup comments marked with [Qin-2].

发件人: stefan vallin [mailto:[e-mail]]
发送时间: 2018年8月17日 17:10
收件人: Qin Wu
抄送: [e-mail]
主题: Re: Second review of draft-ietf-ccamp-alarm-module-01

Hi!


[Qin]: One way to handle the reference to the alarming resource is add Alarm-name or alarm-serial-no as one field of alarm list.
So alarm-name or alarm-serial-no can be seen as alias of 3 tuple (resource, alarm-type-id, alarm-type-qualifier).
No, I will not do this. 3GPP used to notion of alarmId as a redundant/alias (and even conflicting) key to the  3GPP triplet (mo, event-type, probable-cause).
This is really confusing and the 3GPP specs showed inconsistent scenarios where you had the same (mo, event-type, probable-cause) and different alarmId.

The spec said in text that is not allowed. Which database designer would have two conflicting overlapping keys?


[Qin-2]: I am not sure introducing alarmed is confusing in 3GPP standards, as described in http://www.qtc.jp/3GPP/Specs/32111-2-340.pdf,
Alarmid can be used to detect alarm loss. So it is still a useful information.

suppose you have two alarms generated on the same managed object, if you have alarmid, you can easily distinguish one from another.
But without alarmid, you just thought this is the same alarm reraised again, I don’t understand why alarmid will introduce overlapping key. With alarm id added into 3 tuples, you will identify the same type of alarm generated in the same managed object(you use resource to specify each managed object).

When you say alarmSerialNo, this is really confusing. The notion of a serial-number in alarm standards normally refer to individual notifications.

[Qin-2]: Yes, in some case, alarm-serial-no and alarm notification are one to one alarm relationship, in such case, you may use alarmserialno to specify each notification. In TMF814 standard, notificationId is defined to identify each notification.
In addition, I believe you haven’t touched my followup comments posted at:
https://www.ietf.org/mail-archive/web/ccamp/current/msg18904.html
which are not controller support specific comment, appreciate your response to those comments.
4 issues highlighted below:

1.  Alarm-type-id supports union of identity and string

I know defining alarm-type-id as identity make alarm-type-id is more extensible, but waste more space than using enum.

I am wondering why not define alarm-type-id as uint32 or string with embedded format such as groupid-alarmid(e.g., ”2310-36700394”), this will help manage millions of alarm types easier.

Defining alarm-type-id as identity seems wasting a lot of space and hard to deal with millions of alarm type in the design time since Enumerating each of them require human to enter all of alarm types in yang file.
A) a flat enum does not work globally across enterprises and organisations, see ITU failure with probable cause
B) Millons of alarm types ??? No that will not happen
[Qin]: That’s the reality we are facing.(:-
If you have this you need to rethink. I will not buy your equipment if I need to train my operators in the NOC to learn how to manage millions of different alarm *types*.

C) uint32, that is meaningless for operators
[Qin]: That’s why we should have both alarm-name and alarm-serial-no, alarm-name provide meaning for operators.
Alarm-type is a yang identity, it has a clear name. No need for a separate “name”.
Just give your identity a good name

D) string, that will result in surprises for operators, developers will introduce strings in their code that suddenly shows up in the NOC.
[Qin]: The essence of alarm-type-qualifier is string qualifier, so you believe introduce alarm-type-qualifier will result in surprises for operators as well??
Read the RFC, it is explained


[Qin-2]:See definition of alarm-type-qualifier：
“  typedef alarm-type-qualifier {
       type string;
       description
         "If an alarm type can not be fully specified at design time by
          alarm-type-id, this string qualifier is used in addition to
          fully define a unique alarm type.

          The definition of alarm qualifiers is considered being part
          of the instrumentation and out of scope for this module.
          An empty string is used when this is part of a key.";
     }
”
My point is alarm-type-qualifier will have the same issue as string.

E) I do not get your last comment ”require human to enter all alarm types in yang file”.
     You have to design which alarm types your system has, that should not come as.a surprise to the operator.
[Qin]: Enter 2 million alarm type in YANG file is challenging to human.
1) You are in deep problems if your system has millions of alarm types
2) So without enumerating the alarm types in a YANG file (could be generated from whatever source you have, does not have to be “manual” ) what do you argue?
Programmers entering them “manually” as strings in a printf? Difference?

There is a huge value for the operators that the alarm-types are known


There are several benefits of hierarchical identities for alarm types:
- Alarm types can be parsed from YANG modules
- You can reason about “abstract” alarm types
- Extensibility, enterprises and organisations can extend previous identities

[Qin-2]:I am not against to define alarm-types as identity, what I like to see is to add additional information that can be used to identify alarm.
In 3 tuple, resource is actually the managed object that generate alarm, so use resource as part of 3 tuples key to identify each alarm instance has limitation,
that is why we proposed to add alarm-name or alarm-id.



2.  Alarm-name or alarm-serial-no field support for alarm and alarm inventory

Suppose we have alarm-name or alarm-serial-no, I believe it is more easier to based on one field rather than 3 tuple(resource, alarm-type-id, alarm-type-qualifier) to identify each alarm instance,

The most important is this will simplify operation and management.
I think that
(GigabitEthernet0/15, link-alarm, “")

Tells more than:
42

[Qin]: The limitation of 3 tuple is when the same alarm identified by (GigabitEthernet0/15, link-alarm, “")
is raised again, (GigabitEthernet0/15, link-alarm, “")can not be used to distinguish first raised alarm and second raised alarm.
By introducing unsigned integer type alarm-serial-no and string type alarm-name, this issue can be solved.
You are confusing the individual alarm notifications with the alarm itself.
Each notification is available in the status-change list for the alarm
       +--ro status-change* [time]
          +--ro time                    yang:date-and-time

The key being the time of the alarm-notification.


[Qin-2]: See above, I am not mixing alarm-serial-no with notification itself.

[Qin]: If you correlate alarm instance with alarm name or alarm-serial-no, it will be easier to look up each alarm instance based on alarm-name or alarm-serial-no than using 3 tuple(resource, alarm-type-id, alarm-type-qualifier).
Do not agree...

[Qin-2]: See above,
1.alarmid can be used to distinguish two alarm generated at the same managed object or resource while 3 tuple not.
2.Adding alarm-name and alarmid help you manage more alarm type and provide fine granularity on alarm control.