Conference azur::mcc

The entity model for SNMP entities reflects the native structure of
the SNMP MIBs.  There may be solutions, but they would require
new code.  You might want to enter this discussion in the NOTED::EMF_REQ
notes conference.

-- Erik

Well, if you think the DECnis is bad, look at some other MIBS.

When you see the Host mib done, it will have information spread out
over as many as 15 different tables.  You will need to look at all of them
to make any reason out of the set.  I dont really see a simple way
that a management station can have special knowledge about how to group
these together, as the information base changes with each new version of 
a product from each vendor.  e.g. Cisco has released at least 5 different 
mibs for their routers, and each time, things get added, moved, or have their
foirmat/contents changed.  Multiply that by all the vendors and the problem is
almost unsolveable.

BTW:
	SNMP = simple network management PROTOCOL,

and it does not imply that it be easy to manage via snmp, or that
the logic and support in the agent is very simple, only that the
agent PE is fairly simple.

    Sorry, but all I saw in .1 and .2 were excuses for either other vendors
    complexity or the typical "submit a QAR or ...whatever".
    
    This situation will only get worse with intelligent hubs, DECnis and
    other multifunction, multiprotocol routers and what ever comes next
    that combines several different "things" in a single managable box.
    
    Come on folks....look to the future.  This is the way the industry is
    moving and simply saying "that's the way it is" is not a solution.
    Nor is pushing it off to "some other time...".
    
    Designing and building a management station requires more than just
    fancy architectural specifications and wizbang engineers working in
    isolation.
    
    It means sitting down and putting engineer together with network
    manager and hardware designer and network design planners.
    
    I get damned frustrated talking with MCC engineers who are begging for
    user feedback, but either have neither the time or funding to do this.
    
    It's going to take a co-operative group effort and time to solve these
    issues, but be certain of one thing....the longer we take in starting such
    an effort, the further we drop behind the competition.
    
    

Al-

  I understand (and share) your frustration.  But taking out your
frustrations here is not going to help either of us.  The reality is that
there are literally hundreds of requirements of this kind that we would
love to address by "sitting down and doing something".  We obviously
can't do all of them.

  The people who decide which ones we are funded to address are in
product management.  That is why it important to us that your voice
be heard in the right place.

-- Erik

Eric,

Venting frustration is healthy, no matter where it takes place.

It also tends to get people talking and expressing other ideas.

Fortunately, there is a movement underfoot to coordinate some efforts with
DEC, around network management.  MCC is only now coming into wide spread
use within the company and it's shortcomings will be made known with new
plans for the Easynet.   

I hope these talks turn out to be productive and management can understand that
looking only to customers does not solve all of the problems.  

Al

    Whatever happened to attribute groups and attribute partitions?

On a more positive note, what appears to be needed is some sore of user macro
definition or display setup, such that the end user could define a set of
displays or counters that could be involked with a single command.

As Kelly points out, the information in Phase V entities is even more spread
out and to obtain enough data to resolve a problem or even to be to understand
where to begin looking, several different sub-entities must be queried.

Each sub-entity requires a click-to-open the display action and if all of the
information lies in the third level subentity of two or more sub entities, then
each of these must be "clicked".

Now if a user could say "show me all of the pertinent counters" for lets say
a bridge entity on a mulifunction router, with a single click and be given
one or more side by side displays in which all of the desired counters and
perhaps a few secondary ones would be displayed, then we'd have the start of
a good trouble shooting tool.  

Please let's not get into a discussion about what or which information is
pertinant to a particular problem,  but leave it to the individual user to
decide.  

In addition, for Phase V and other entities, we are beginning to gather a known
set of information needed to resolve such problems.  These can be documented
and given a starting points to the user community.

This is the type group developement activity I am proposing.  

I believe some other SNMP only network management workstations already allow the
user to define a set of MIB variables which would give them a menu of lists of
MIB variables to gather on a single command.

We should be able to do this for any other type of entity that MCC manages.

Now that is one possible solution for multiple counters or other partitions
for a single entity function classification.

There is still the issue of respresentation of multifunction entities visually
and how to best get at the pertinent data quickly.

Unless this can be done, MCC is only good as a monitor and not as a trouble 
shooting tool.    SPEED IS OF OPERATION AND INFORMATION RETRIEVAL IS MOST 
               IMPORTANT WHEN TRYING TO RESOLVE PROBLEMS.

AL

    RE: .6
    
    > Whatever happened to attribute groups and attribute partitions?
    
    That sounds interesting.  Can you expand?
    
    Also, if there are any ways to start getting close to this capability
    with the current s/w, let me know.  I'ld be happy to write some DCL or
    whatever to try to get close to this.

REALITY:

VERY,VERY FEW use DECmcc to issue interactive commands to entities
because their are too many steps involved, too many windows, and it takes
too long. This is an internal and EXTERNAL observation. DECmcc is therefore
reduced to being a monitor rather than a full mngmt station. Is this the
goal of DECmcc??

To expand upon the problem is the MODEL of entities which is architectually
flawed for OPERATIONs, increasing the USER frustration shown by Kelly and
Al. This problem is so acute I've even written launchable scripts to
issue NCP commands. I thought this would get some attention but it didn't
seem to get the right kind. It is probably looked upon as a neat gadget rather
than indicating insufficient (or failed) mcc tool functionallity.

REQUIREMENTS:

I have outlined this more times, in more places, over more months/yrs than seemed
possible. The user needs USER DEFINABLE BUTTONS to issue entity commands which
can span the entire entity model and multiple partitions. One button issueing
multiple commands to gather the operational data required for mngmt. BTW, give
it to us in an OPERATIONAL window which lives for the entire session and can
be scrolled back to look at the data (read: no more pop-up windows). This could
be considered one technique for getting around architectually correct entities
which don't relate to operations. I have delivered this statement in NOTES, in
V1.4 requirements, at USER meetings (w/product mngr), etc, etc... This issue
was brought to the table eons ago, ahead of user complaints and in time to make
a requirements phase. I'm not sure if it made the priority list but I for one 
will not type the above letters again. 

sincerely,
brad...

RE: 6. , .8

	MCC has support for attribute groups, which allow attributes to be
	clumped into usefull groups, See page 7-29 in the SRM.

But....
	This only works for attributes in a single object, and the base note
	was complaining about attributes of many objects, not of a single
	object.  So the concept does not apply.

Also,
	This could be used within a single object where we have access to the
	MSL, but I dont see how it could be automatically be applied to MIBs
	which come from many vendors.  Further, the MIBs 
	(mainly the tables) are modeled with the framework as a collection
	of objects, so this would not work in this case either.

	

>	This could be used within a single object where we have access to the
>	MSL, but I dont see how it could be automatically be applied to MIBs
>	which come from many vendors.  Further, the MIBs 
>	(mainly the tables) are modeled with the framework as a collection
>	of objects, so this would not work in this case either.
    
    I'm not looking for a complete sollution from MCC engineering.  I'm
    hoping for a tool (with plenty of examples) which could be built upon
    by GIGAswitch, DECNIS, etc... engineering and also customers and maybe
    even me.
    
    Like:
    
    	define userstuff myGIGAswitch-line-3 -
    	    counters { -
    		snmp myGIGAswitch interface 3 ifOutErrors, -
    		snmp myGIGAswitch interface 3 ifInDiscards, -
    		snmp myGIGAswitch fddi snmpFddiPORT snmpFddiPORTTable (3,0) -
    				snmpFddiPORTLemRejectCts, -
    		snmp myGIGAswitch dot1dBridge dot1dBase dot1dBasePortTable 3 -
    				dot1dBasePortDelayExceededDiscards -
    		}
    
    Where:
    
      -  "userstuff" is some entity class (is that the right phrase?) just
        like "node" or "snmp" which denotes that it is user defined
      - "myGIGAswitch-line-3" is the name of the entity I'm defining
      - "snmp myGIGAswitch" is the class and name of the entity which
        actually has the attributes I want to group together
    
    The user should be able to define "counters", "status", "characteristics",
    "statistics", etc...   I suppose the things defined under counters
    should actually be counters.  But maybe not.
    
    Then the user could do:
    
    	mcc> show userstuff myGIGAswitch-line-3 all counters
    
    and get:
                                ifOutErrors = 0
                               ifInDiscards = 0
                   snmpFddiPORTLemRejectCts = 0
         dot1dBasePortDelayExceededDiscards = 0
    
    The user should also be able to do:
    
    	mcc> show userstuff myGIGAswitch-line-3 snmpFddiPORTLemRejectCts
    
    and get:
    
                   snmpFddiPORTLemRejectCts = 0
    
    And, of course, the same should work for shows of other types of
    attributes (status, char, etc) and similar things should work for sets
    and any other commands.
    
    This would really just be a short-hand mechanism to allow the user to
    tell MCC some rules for abreviating command input/output.
    
    I would also want to be able to mix and match attributes from different
    entity classes.  For example, when managing a DECbridge 620, I might
    want to use some attributes from the BRIDGE entity class (assuming the
    bridge is defined as a bridge) and some from SNMP.  Or when managing a
    DECNIS, I might want to group together status attributes from different
    layers:
    
    	define userstuff myCircuit -
    	    status { -
    		node mydnis modem connect line w618-4-0 request to send, -
    		node mydnis modem connect line w618-4-0 clear to send, -
    		node mydnis modem connect line w618-4-0 data set ready, -
    		node mydnis modem connect line w618-4-0 data terminal ready, -
    		node mydnis hdlc link w618-4-0 state, -
    		node mydnis hdlc link w618-4-0 logical station w618-4-0 state, -
    		node mydnis hdlc link w618-4-0 logical station w618-4-0 -
    			protocol state, -
    		node mydnis hdlc link w618-4-0 logical station w618-4-0 -
    			maintenance mode, -
    		node mydnis routing circuit w618-4-0 nmfoperationalState, -
    		node mydnis routing circuit w618-4-0 state, -
    		node mydnis routing circuit w618-4-0 adjacency * -
    			Neighbor Node ID, -
    		node mydnis routing circuit w618-4-0 adjacency * -
    			Neighbor Areas, -
    		node mydnis routing circuit w618-4-0 adjacency * -
    			Router NETs -
    		}, -
    	    counters { -
    		node mydnis routing circuit w618-4-0 all counters, -
    		node mydnis hdlc link w618-4-0 logical station w618-4-0 -
    			all counters -
    		}
    
    and the responses from shows should not have all this junk in them but
    should only have the name of individual attributes involved, not all
    the hierachies involved.

For SNMP  (only)  one way of *automatically* doing something like this would
be  combine  all  tables  indexed by the same variable together (and display
them  in  a  tabular  form).   So,  for  example,  there  are several tables
(including  parts  of  the  Cisco private MIB) which are indexed by ifIndex.
That is a strong hint that they are related!

Graham

Re .various

.12 Graham is right - many MIBs "extend" existing tables rather 
than truly defining new things. For what it's worth, those issues were 
explored in a white paper on how SNMP might integrate into EMA more effectively
than it now does I wrote awhile back. The issue in .0 was one of the things 
addressed.

One of the things that MCC could do, if someone wrote the appropriate MM, 
is to gather data from one or more logically related entities into a 
"useful data about X" display. It could do that by defining a new entity,
or by extending an existing one. So you could faily easily duplicate the 
Phase IV circuit and line data. This is similar to the reasons why the Entity
Model didn't bother with a "Summary" group, the hope was that someone would 
define an MM that knew what was the useful summary data for entity X and
issue the appropriate stuff to gather them together.

Finally, a good PM would be one that allowed a user to pick data from various
entities and various attributes/stats/etc and define them as "useful display 6"
and then allow the user to recall that display at any time.

Mark

re .13
    
>Finally, a good PM would be one that allowed a user to pick data from various
>entities and various attributes/stats/etc and define them as "useful display 6"
>and then allow the user to recall that display at any time.

    Sounds like what a product specific GUI does.
    
    We may be trying to solve a problem that has already been solved by
    GUIs that buffer the user from the NMS.  The way that MIBs are structured 
    makes a GUI a required adjunct to most all SNMP managed entities. 
    Generic SNMP managers aren't the way to go. You really need an
    application GUI on top.
     
    HubWatch is a perfect example.  The various "screens" are designed to
    display the related and most useful information.   The DEChub 900 and
    the GIGAswitch will be managed by GUIs that are very similiar to  
    HUBwatch.  
    
    What we're really talking about is adding functionality to the POLYCENTER 
    Framework that would allow a  user to design new objects that were 
    groupings of other objects, along with their associated attribute
    groups.  GUIs already do this.  
    
    This proves that customers will demand a  GUI for the GIGAswitch and the 
    DECnis.  I'm glad we started designing one for the GIGAswitch months ago.
    
    Bill
          
    

    
    Well there is a hack to do some of this, but it needs DCL literate
    people.
    
    Take a look at note 4975 where you can kick off a job from a reference
    icon which can select different information and then display it in a
    window.
    
    Dave McCallum.