RE: Entity MIB State Extensions
Andy Bierman <[email protected]>
| Newsgroups | gmane.ietf.entmib |
|---|---|
| Message-ID | <[email protected]> |
At 10:57 AM 10/25/2002 -0400, Sharon Chisholm wrote: >hi > >We seem less convinced than I remember. Should I throw this >proposal into an individual submission and then we can >merge it with the Entity MIB after Atlanta when we are all >hopefully more convinced? The deadline is Monday morning, >but if I basically cut and paste the email, I think I can >make it. From a design POV, I think it would be better if there was a separate ENTITY-STATUS-MIB module that was not merged back into the ENTITY-MIB module. There is sufficient complexity and page count to warrant a separate RFC. >We can talk about a sparse augments, but I kind of like the >information being available for all components - even if >some components may only be able to support a subset of >possible values. Since you added a lot of detail about what a developer should do for each class of physical entity, it's okay with me if this table is a full augmentation, instead of a sparse one. >From my perspective, I am more interested in seeing if something >is administratively disabled than actually disabling it myself, >so if consensus is read-only objects I can certainly live with that. MAX-ACCESS read-write, MIN-ACCESS read-only would be okay. Also, an agent may selectively support read-write for some components, and read-only for others. E.g., I doubt we will allow an entire chassis to be turned off with this object, and never allow fans to be controlled by the administrator, and wouldn't have any ability to administratively control a specific container. >You raise a good question about the usage scenarios. One >use for states in general is management systems that use the state of >components in a device's physical component hierarchy as a health >indicator for the overall system. Another is in fault management where it >is necessary to be able to differentiate between a physical component >not functioning because of a problem or it being administratively >disabled. I would also expect this to be useful to confirm configuration >and to help debug problems. I'm withdrawing my concerns with the understanding that the RFC will explain what subsets of each object are appropriate and expected for each entPhysicalClass value. Andy >As for using the ISO/ISO/ITU states in particular, I see the benefit >of this, aside from the wide deployment of these models, is the >ability to tell whether or not a physical component has more capacity. >For example, Does your chassis have any more empty slots that I could >plug a card into? > >Here is some further discussion of the states for each of the >various physical classes: > >N.4 Physical Classes and States > >N.4.1 Chassis > >A value of unlocked for entStateAdmin means that this system is on. >A value of shuttingDown for entStateAdmin means that this system >is in the process of shutting down. A value of enabled for entStateOper >indicates that basic functions of this system are functioning. A >value of disabled for entStateOper indicates a problem with basic >functions on the system. A value of idle for entStateUsage may not >make sense since responding to a SNMP query may constitute service. >A value of active for entStateUsage indicates the system is functioning, >but is able to provide more services. A value of busy for entStateUsage >indicates that the system is functioning at maximum capacity and is >unable to provide more services at the present time. > >A value of hotStandby for enStateStandby indicates that the entire >system contained within this chassis is running as a hot standby for >another complete system, possibly contained within the same stack. >A value of coldStandby for enStateStandby indicates that the entire >system contained within this chassis is running as a cold standby for >another complete system, possibly contained within the same stack. >A value of providingService for enStateStandby indicates that the entire >system contained within this chassis is currently providing service. > >If this chassis is not contained in within a stack, the alarm counts >indicated by entStateAlarm will be those alarms that are against the >general system, as appose sub-components within the containment hierarchy. > >N.4.2 BackPlane > >A value of unlocked for entStateAdmin means that the backplane is not >administratively prevented from aggregating and forwarding network >traffic. A value of shutting down for entStateAdmin means that the backplane >will finish aggregating and forwarding the network traffic is currently >handling, but then transition to be administratively locked. A value of >locked for entStateAdmin means that backplane is administratively prohibited >from aggregating and forwarding any network traffic. A value of enabled >for entStateOper means that the backplane is partially or fully capable >of aggregating and forwarding network traffic. A value of disabled for >entStateOper means that the backplane is unable to aggregate and forward >any network traffic. A value of idle for entStateUsage means that the >backplane is not currently aggregating and forwarding any network traffic. >A value of active for entStateUsage means that the backplane is currently >aggregating and forwarding some network traffic, but has capacity to >handle more traffic. A value of busy for entStateUsage means that the >backplane is aggregating and forwarding network traffic at full capacity. > >A value of hotStandby for enStateStandby indicates that the >backplane is running as a hot standby for >another backplane within this system. A value of coldStandby for >enStateStandby indicates that the backplane is running as >a cold standby for another backplane, possibly within this system. >A value of providingService for enStateStandby indicates that the backplane >is currently providing service. Looking at the >entStateAlarm gives a convenient way to see if there are any alarms >currently active against this backplane. > >N.4.3 Container > >A value of unlocked for entStateAdmin means it is administratively >possible to insert things into this container. A value of >shuttingDown for entStateAdmin could be used to reflect that inserting >objects into this container is administratively prohibited. This value >could also be used for systems that do not support hot insertion of >components. > >The container physical class could be used to indicate, >among other things, chassis slots or daughter-card holders. >If the container is empty, for example it has no modules in >its slots, then entStateUsage would have a value of idle. >If the container is partially used, for example it has modules >in some but now all of its slots, then entStateUsage would have >a value of busy. If the container is full, for example it has no >empty slots, then entStateUsage would have a value of busy. > >If it is not possible to raise alarms against this chassis, the >entStateAlarm will have no alarms set. It may not make sense for >the entStateOper to have values other than enabled. > >N.4.4 PowerSupply > >If this power supply is the currently providing power to the system, >then entStateStandyby would have a value of providing service. If this >power supply is serving as a backup to a primary power supply, then >entStateStandyby would have a value of hotstandby. > >A value of locked for entStateAdmin means that the power supply has been >turned off. This only makes sense in the situation where there is a >backup power supply. A value of unlocked for entStateAdmin means that >the power supply is turned on. A value of enabled for entStateOper means >that the power supply is operational. A value of disabled for entStateOper >means that the power supply is not functioning. A value of idle for >entStateUsage means that the power supply is providing no power to the >system. A value of active for entStateUsage means that the power supply >is providing power to the system, but could possibly provide more. A value >of busy for entStateUsage means that the power supply is providing the >maximum power to the system that it is capable of. Looking at the >entStateAlarm gives a convenient way to see if there are any alarms >currently active against this power supply. > >N.4.5 Fan > >If this fan is serving as a backup to a primary fan, then entStateStandyby >would have a value of hotstandby. >If this fan is the currently providing service to the system, >then entStateStandyby would have a value of providing service. A value of >idle for entStateUsage would indicate that the fan was not actually running. >A value of active for entStateUsage would indicate that the fan was >running, but not at its maximum capacity. A value of busy for entStateUsage >would indicate that the fan was running at maximum capacity. > >Looking at the entStateAdmin and entStateOper provide useful information >to determine why a fan is not running. A value of locked for entStateAdmin >means that the fan is not running because it has been administratively >disabled. A value of disabled for the entOperStatus indicates that the >fan itself is not operational. A value of enabled for the entOperStatus >indicates that the fan is working in theory and that cause of it not >operator may lie elsewhere. Looking at the entStateAlarm gives a >convenient way to see if there are any alarms currently active against >this fan. > >N.4.6 Sensor > >A value of unlocked for entStateAdmin indicates that the sensor is not administratively >prohibited from sensing. A value of shutting down for entStateAdmin indicates that >the sensor will complete its current readings and then shut down. A value of locked for >entStateAdmin indicates that the sensor is administratively prohibited from sensing. >A value of enabled for entStateOper indicates that the sensor is functioning properly. >A value of disable for entStateOper indicates that the sensor is totally inoperable. >A value of idle for entStateUsage indicates that the sensor is not currently sensing. >A value of active for entStateUsage indicates that the sensor is currently sensing things, >but could sense more, more often or other types of information for example. A value of >busy for entStateUsage indicates that the sensor is sensing everything it knows how to >sense and at its fastest possible rate. > >Looking at the entStateStandby indicates whether this sensor is currently providing service >or acting as a backup for another sensor. Looking at the entStateAlarm gives a convenient >way to see if there are any alarms currently active against this sensor. > >N.4.7 Module > >For modules that support the functionality of being administratively >disabled, entStateAdmin object indicates whether the module is >administratively locked (disabled) or unlocked (enabled). Modules >that do not support disabling will always have a value of unlocked >for entStateAdmin. A value of enabled for entStateOper indicates >that this module is partially or fully operational. A value of disabled >for entStateOper indicates that this module is totally inoperable. >A value of idle for entStateUsage indicates that this module is currently >not performing any functions. A value of active entStateUsage indicates >that this module is currently performing functions, but capable of >performing more. A value of busy for entStateUsage indicates that the >module is functioning at full capacity and unable to perform further functions >at this current time. > >Looking at the entStateStandby indicates whether this module is currently >providing service or acting as a backup for another module. Looking at the >entStateAlarm gives a convenient way to see if there are any alarms >currently active against this module. > >N.4.8 Port > >A value of enabled for entStateAdmin means the port is not administratively >prohibited from passing network traffic. A value of shutting down for >entStateAdmin indicates that the port will pass its current traffic and >then transition to the locked state. A value of locked for entStateAdmin >indicates that the port is administratively prohibited from passing >network traffic. A value of enabled for entStateOper means that the >port is partially or fully capable of forwarding network traffic. A value >of disabled for entStateOper means that the port is totally unable to >forward network traffic. A value of idle for entStateUsage indicates that >the port is not currently forwarding any network traffic. A value of >active means that the port is currently forwarding network traffic, but >has capacity to forward more. A value of busy for entStateUsage indicates >that the port is forwarding network traffic at its maximum capacity. > >Looking at the entStateStandby indicates whether this port is currently >providing service or acting as a backup for another port. Looking at the >entStateAlarm gives a convenient way to see if there are any alarms >currently active against this port. > >N.4.9 Stack > >A value of unlocked for entStateAdmin means that this system is on. >A value of shuttingDown for entStateAdmin means that this system >is in the process of shutting down. A value of enabled for entStateOper >indicates that basic functions of this system are functioning. A >value of disabled for entStateOper indicates a problem with basic >functions on the system. A value of idle for entStateUsage may not >make sense since responding to a SNMP query may constitute service. >A value of active for entStateUsage indicates the system is functioning, >but is able to provide more services. A value of busy for entStateUsage >indicates that the system is functioning at maximum capacity and is >unable to provide more services at the present time. > >A value of hotStandby for enStateStandby indicates that the entire >system contained within this stack is running as a hot standby for >another complete system, possibly contained within the same parent >stack. A value of coldStandby for enStateStandby indicates that >the entire system contained within this stack is running as a >cold standby for another complete system, possibly contained within the >same parent stack. A value of providingService for enStateStandby indicates >that the entire system contained within this chassis is currently >providing service. > >If this stack is not contained in within a parent stack, the alarm counts >indicated by entStateAlarm will be those alarms that are against the >general system, as appose sub-components within the containment hierarchy. > >Sharon > >-----Original Message----- >From: Andy Bierman [<mailto:[email protected]>mailto:[email protected]] >Sent: Friday, October 25, 2002 1:54 AM >To: Chisholm, Sharon [CAR:NM50:EXCH] >Cc: Entity Mib >Subject: Re: [Entmib] Entity MIB State Extensions > >At 03:49 PM 10/23/2002 -0400, Sharon Chisholm wrote: >>hi >> >>This took a little longer than expected, but hopefully Andy still as >>time to get out another version of the Entity MIB before the Atlanta >>cut-off to give us something to poke sticks at. > >I read through this, and I'm having trouble figuring out how >I would apply it to most of the physical entities in our products. At best, it might be a sparse augmentation of the entPhysicalEntry, not a real AUGMENTS. > >I don't remember ever talking about a read-write admin object as part of this table. I don't want to put in any writable admin status object for physical entities. > >I'm not convinced we need 4 objects to describe the operational state of a physical entity. Well, 3 if you consider standby state as a separate attribute. Can you describe some usage scenarios for specific entPhysicalClass values for which this ITU model is appropriate and useful? These states seem to apply to logical services more than physical entities -- even for a module or a cpu. > >thanks, >Andy > > >>N Entity State >> >>N.1 Overview >> >>The goal in adding state objects to the Entity MIB was to define a >>useful >>subset of the possible state attributes that could be tracked for a given >>entity that both fit into the existing IETF model, as well as leveraged >>existing well deployed models. The entStateTable contains state objects >>that are a subset of ITU's X.731 state objects. Objects are defined to >>capture administrative, operational and usage states. In addition there >>are further state objects defined to provide additional information for >>these three basic states. >> >>The terms state and status are used interchangeably in this memo. >> >>Administrative state indicates permission to use or prohibition against >>using the entity and is imposed through the management services. The >>administrative state defined for an entity is independent of >>administrative states in its containment hierarchy. This means that >>administratively locking an entity does not automatically lock its >>children in the containment hierarchy. >> >>Operational state indicates whether or not the entity is >>physically installed and working. The operational state defined >>for an entity is indirectly dependent on the operational state of >>the entities in which it is contained. If its parent entities in >>its containment hierarchy are disabled, and therefore totally inoperable, >>then it is unlikely that the given entity will be operable. >> >>Usage state indicates whether or not the entity is in use at a >>specific instance, and if so, whether or not it currently has >>spare capacity. >> >>N.2 State Relationships >> >>The following section outlines all of the combinations of the three >>basic states - administrative, operational and usage - and briefly >>describes what each of these combination of states means. It also >>compare this combination of states to that of the ifAdminStatus and >>ifOperStatus objects of the Interfaces Group MIB [RFC2863] to both >>provide insight to those familiar with these status objects as well as >>to clarify the relationship between entities and interfaces, as >>indicated by entAliasLogicalIndexOrZero. >> >>N.2.1 Admin State Locked, Operational State Disabled and Usage State >>Idle >> >>The entity is totally inoperable, it is not servicing any users and it >>is >>also administratively prohibited from use. To make it available for use, >>both management permission and some corrective >>action are necessary. This is similar to an ifAdminStatus of down >>and ifOperStatus of down. >> >>N.2.2 Admin State Locked, Operational State Enabled and Usage State >>Idle >> >>The entity is partially or fully operable, it is not servicing any >>users >>but is administratively prohibited from use. To make it available for use, >>only management permission is required. This is similar to an ifAdminStatus >>of down and ifOperStatus of down. >> >>N.2.3 Admin State Shutting Down, Operational State Enabled and Usage >>State Active >> >>The entity is partially or fully operable and in use, but usage is >>administratively limited to current instances of use. For an additional >>user to gain access, management >>permission is required. Otherwise, when all current users have terminated >>their use >>of the resource, the managed object will automatically transit to the >>locked, enabled, and idle state. >>This is similar to the situation described in [RFC2863] where ifAdminStatus >>transitions to down, >>but the ifOperStatus's transition does not occur immediately, but rather >>after a small time lag to >>complete certain operations before going "down". >> >>N.2.4 Admin State Shutting Down, Operational State Enabled and Usage >>State Busy >> >>The entity is partially or fully operable and in use, but usage is >>administratively limited to current instances of use. In addition, it >>has no spare capacity to >>provide for additional users. For an additional user to gain access, beside >>waiting >>for an existing user to terminate, management permission is also required. >>Otherwise, when all current users have terminated their use of the resource, >> >>the managed object will automatically transit to the locked, enabled, >>idle state. This is similar to the situation described in [RFC2863] >>where ifAdminStatus transitions to down, >>but the ifOperStatus's transition does not occur immediately, but rather >>after a small time lag to >>complete certain operations before going "down". >> >>N.2.5 Admin State Unlocked, Operational State Enabled and Usage State >>Idle >> >>The entity is partially or fully operable, it is not actually in use >>and is >>not administratively prohibited from use. This is similar to an >>ifAdminStatus of up >>and ifOperStatus of up if the interface is able to pass packets. If the >>interface >>is found to be operable, but the interface is waiting for other, external, >>events >>to occur before it can transmit or receive packets, then this is similar to >>an ifAdminStatus of up and a ifOperStatus of dormant. >> >>N.2.6 Admin State Unlocked, Operational State Enabled and Usage State >>Active >> >>The entity is partially or fully operable, it is currently in use and >>is not >> >>administratively prohibited from use. It has sufficient spare capacity >>to provide for additional users. This is similar to an ifAdminStatus of >>up and >>ifOperStatus of up. >> >>N.2.7 Admin State Unlocked, Operational State Enabled and Usage State >>Busy >> >>The entity is partially or fully operable, it is currently in use and >>it is not administratively prohibited from use. Currently it has no >>spare capacity to provide for additional users. For an additional user >>to gain access, it is necessary to wait for an existing user to >>terminate or for some capacity increase to occur. This is similar to >>an ifAdminStatus of up and ifOperStatus of up. >> >>N.2.8 Admin State Unlocked, Operational State Disabled and Usage State >>Idle >> >>The entity is totally inoperable, it is servicing no users but it is >>not >>administratively prohibited from use. To make it available for use, >>some corrective action is required. This is similar to an ifAdminStatus >>of up and ifOperStatus of down. If the cause of the interface being down >>is because of a lower layer being down, then this is similar to >>an ifAdminStatus of up and an ifOperStatus of lowerLayerDown. >> >> >>N.3 Relation to Alarm MIB >> >>The entStateAlarm objects indicates whether or not there are any active >>alarms against this entity. If there are active alarms, then the >>alarmActiveTable should be searched for alarmActiveResourceId that >>match this entPhysicalIndex >> >>M. Definitions >> >>... >> >> -- Textual conventions >> >> >> ItuAdminState ::= TEXTUAL-CONVENTION >> STATUS current >> DESCRIPTION >> " Represents the various possible administrative states >> (ITU-T X.731). >> >> A value of locked means the resource is administratively >> prohibited from use. A value of shuttingDown means that >> usage is administratively limited to current instances >>of use. >> A value of unlocked means the resource is not >>administratively >> prohibited from use." >> SYNTAX INTEGER >> { >> locked(1), >> shuttingDown(2), >> unlocked(3) >> } >> >> >> ItuOperState ::= TEXTUAL-CONVENTION >> STATUS current >> DESCRIPTION >> " Represents the possible values of operational states >> (ITU-T X.731). >> >> A value of disabled means the resource is totally inoperable. >> A value of enabled means the resource is partially or fully >> operable." >> SYNTAX INTEGER >> { >> disabled(1), >> enabled(2) >> } >> >> ItuUsageState ::= TEXTUAL-CONVENTION >> STATUS current >> DESCRIPTION >> " Represents the possible values of usage states >> (ITU-T X.731). >> >> A value of idle means the resource is servicing no users. >> A value of active means the resource is currently in use >> and it has sufficient spare capacity to provide for >> additional users. A value of busy means the resource is >> currently in use, but it currently has no spare capacity to >> provide for additional users." >> SYNTAX INTEGER >> { >> idle(1), >> active(2), >> busy(3) >> } >> >> >> ItuAlarmStatus ::= TEXTUAL-CONVENTION >> STATUS current >> DESCRIPTION >> " Represents the possible values of alarm status >> (ITU-T X.731). >> >> When no values of this attribute are set, then none of >>the status >> conditions described below are present. When the value of >>under repair >> is set, the resource is currently being repaired. >> >> When the value of critical is set, one or more critical >>alarms are active >> against the resource. When the value of major is set, one >>or more major >> alarms are active against the resource. When the value of >>minor is set, >> one or more minor alarms are active against the resource. >> >> When the value of alarm outstanding is set, one or more >>alarms is active >> against the resource. The fault may or may not be disabling. " >> SYNTAX BITS >> { >> under-repair(1), >> critical(2), >> major(3), >> minor(4), >> alarm-outstanding(5), >> warning (6), -- Not defined in X.731 >> indeterminate (7) -- Not defined in X.731 >> } >> >> >> >> ItuStandbyStatus ::= TEXTUAL-CONVENTION >> STATUS current >> DESCRIPTION >> " Represents the possible values of standby status >> (IU-T X.731). >> >> A value of hotStandby means the resource is not >>providing service, >> but is will be immediately able to take over the role of >>the resource to >> be backed-up, without the need for initialization >>activity, and will >> contain the same information as the resource to be >>backed up. A value of >> coldStandy means that the resource is to back-up another >>resource, but >> will not be immediately able to take over the role of a >>resource to be >> backed up, and will require some initialization activity. A >>value of >> providingService means the resource is providing service. >> " >> >> SYNTAX INTEGER >> { >> hotStandby(1), >> coldStandby(2), >> providingService(3) >> } >> >> -- Entity State >> >> entStateTable OBJECT-TYPE >> SYNTAX SEQUENCE OF EntStateEntry >> MAX-ACCESS not-accessible >> STATUS current >> DESCRIPTION >> "A table of information about state/status of entities. >> " >> ::= { entStateMIB 1 } >> >> >> entStateEntry OBJECT-TYPE >> SYNTAX EntStateEntry >> MAX-ACCESS not-accessible >> STATUS current >> DESCRIPTION "" >> AUGMENTS { entPhysicaEntry } >> ::= { entStateTable 1 } >> >> EntStateEntry ::= SEQUENCE { >> entStateAdmin ItuAdminState, >> entStateOper ItuOperState, >> entStateUsage ItuUsageState, >> entStateAlarm ItuAlarmStatus, >> entStateStandby ItuStandbyStatus >> } >> >> entStateAdmin OBJECT-TYPE >> SYNTAX ItuAdminState >> MAX-ACCESS read-write >> STATUS current >> DESCRIPTION "The administrative state for this entity." >> ::= { entStateEntry 1 } >> >> entStateOper OBJECT-TYPE >> SYNTAX ItuOperState >> MAX-ACCESS read-only >> STATUS current >> DESCRIPTION "The operational state for this entity." >> ::= { entStateEntry 2 } >> >> entStateUsage OBJECT-TYPE >> SYNTAX ItuUsageState >> MAX-ACCESS read-only >> STATUS current >> DESCRIPTION "The usage state for this entity." >> ::= { entStateEntry 3 } >> >> entStateAlarm OBJECT-TYPE >> SYNTAX ItuAlarmStatus >> MAX-ACCESS read-only >> STATUS current >> DESCRIPTION "The alarm state for this entity. It does not include >> the severity of alarms raised on child components." >> ::= { entStateEntry 4 } >> >> entStateStandby OBJECT-TYPE >> SYNTAX ItuStandbyStatus >> MAX-ACCESS read-only >> STATUS current >> DESCRIPTION "The standby status for this entity." >> ::= { entStateEntry 5 } >> >> >>... >> >>Sharon Chisholm >>Portfolio Integration >>Nortel Networks >>Ottawa, Canada >>_______________________________________________ >>Entmib mailing list >>[email protected] >><https://www1.ietf.org/mailman/listinfo/entmib>https://www1.ietf.org/mailman/listinfo/entmib