MIBs represent a shared name space between SNMP agents and managers. They allow an operator to leverage the management facilities deployed in the network. Because of their central role in network management, MIBs should be as well written as possible. The following MIB notes provide some guidelines. Our MIB notes are primarily intended to promote NE manageability (one of the four M's mentioned in the preface). High levels of NE manageability offer a number of benefits:
The enterprise networking market is highly competitive with tight margins. If a given NE is easy to install, configure, and operate in an NMS environment, then that is a considerable advantage for the vendor. If the NE feature set (e.g., MPLS, Frame Relay) is easy to access (via both the EMS and SNMPv3), then the cost of integration and ownership are reduced. Happy end users are likely to upgrade or purchase new equipment. All of these are good things from the vendor's perspective, particularly in an industry where NEs are increasingly similar. We now describe some aspects of MIBs that improve manageability. MIB Note: Avoid MIB Object Semantic Dependencies
MIB table column semantic dependencies complicate provisioning code because the NMS software has to understand the columnar relationships. Another problem is that they also complicate the database schema when the columnar relationships have to be duplicated . The latter point illustrates the problem of modeling the NE MIBs in the NMS. Since the NMS must track the state of the NEs, it has to store NE data usually in a relational database. It is in the schema of the latter that it is often required to duplicate the MIB data. Intercolumn MIB dependencies make for a more complex database schema. MIB Note: Provide Default MIB Object Values
Default values can be given to extraneous MIB objects (column objects that are not needed in a given SNMP operation), for example, mplsTunnelIncludeAffinity in the MPLS tunnel table. This object is used when creating a tunnel in which the user wants to constrain the signaling path through an MPLS cloud so that it uses only a specific type of interface on each hop. This type of tunnel may reflect a higher (or lower) class of service reserved for certain end users ”in short, much of the time, this type of tunnel may not be required, so the mplsTunnelIncludeAffinity object will, in many cases, not be set. Providing a default value for this and similar objects can help to prevent agent exceptions caused by the insertion of bad values; these can occur if the sender inadvertently uses an invalid value for a given column but the agent tries to interpret the value anyway and generates an exception. This guideline indicates that only mandatory columns are set; the rest are given safe, default values. To illustrate this, the allowed values of mplsTunnelIncludeAffinity are integer bitmasks ; each bitmask represents an interface color code value, for example, 0x00001 for gold, 0x00010 for silver, and 0x00100 for bronze. The network operator must configure these colors on all NEs where color selection will be used. In Chapter 3, Figure 3-3, the nodes LER A, LSR D, LSR E, LSR F, and LER B could be configured to support the colors silver and bronze on their ingress interfaces. Then a tunnel could be created with a path constrained to use only interfaces with the colors silver and bronze by setting mplsTunnelIncludeAffinity to 0x00110. The tunnel so created would follow the path described. This is another example of traffic engineering, where the path is reserved in advance by special actions on the part of the network operator. A sensible default value for mplsTunnelIncludeAffinity (and its associated objects) could be 0 to indicate non-use of this MIB object. Since the default provisioning value has been chosen to match the MIB default value, there is no need to validate before updating the MIB. This reduces the size of the provisioning code layer. New MIBs should always be written to include default values for all objects. MIB Note: Centralize MIBs to Match NE Features
This is similar to solution engineering considerations. MIBS should be structured so that solution components are clearly expressed and easily accessed. Again, the MPLS tunnel table is a good example because it illustrates the main MPLS managed objects (such as tunnels, EROs, and resource blocks) in a fairly clear and concise manner. Issues like the above MIB notes provide good reason for the developers of NMS maintaining the MIBs to work in close cooperation with the NE developers. In other words, authority and responsibility for MIBs should be shared between the main interested engineering parties. Poor-quality MIBs can result in unnecessarily complex NMS software and possibly even NEs that are difficult if not impossible to properly manage. |