Conference azur::mcc

    As you probably know, SUNnet Manager will allow you to manage network
    entities via SNMP or SUN RPC.  At the present, the TCPIP_SNMP_AM will
    manage nodes via SNMP quite nicely, if you have the proper SNMP agent
    loaded on each SUN and you have the necessary MIB info.  If you have a
    private, extended MIB, it can quite easily be enrolled and used via the
    TCPIP_SNMP_AM.   Remember, though, you have to have a GOOD agent, and
    so far, we haven't found one good enough for our needs.  
    
    I would really like to have an AM that manages SUNs via RPC.  Of
    course, this will have to be developed if it does not already exist.  I
    would be willing to bet that SUN is touting standard SNMP support via
    SUNnet manager, but all of the SUNs are being managed via SUN RPC.
    
    SUN ethernet controllers are not smart enough to speak standard
    low-level ethernet test/loopback protocols, so you have to have an
    agent loaded on the SUN to respond with that information if you want to
    manage SUNs via the ETHERNET_AM (STATION).
    
    -Dan

    DECmcc currently (V1.1 with new SNMP AM) provides the ability to
    manage DNA4 (Nice protocol), DNA5 (DNA CMIP protocol), Ethernet
    Stations (Enet V2 Req Id/Sys Id and IEE802.3 XID/Test ID and
    MOP ), SNMP for TCP management. Currently in field test are
    Terminal Server AM (for Digital Terminal Servers using LAT),
    FDDI Concentrator AM and a new Bridge AM that covers all
    RBMS and ELMS bridges. The currently available V1.1 Bridge AM
    supports RBMS bridges. I might also point out that many other
    Vendors bridges, routers, terminal servers are SNMP manageable.
    Much of the items discussed above will be availabe early in
    calender year 1992. The SNA Gateway (DNA4) based are mostly
    manageable from DECmcc with the exceptions of some SNA specific
    counters. The DNA5 SNA Gateway management will be manageable
    via the DNA5 AM once the CML supports SNA Gateway child objects.
    It is in development but I have no idea of the schedule. Further
    there is an active project to make DECmcc and Netview interoperate
    by capturing SNA alerts into the DECmcc event streams and allowing
    limited command exchange. I BELIEVE their target schedules are
    CY92.
    
    The OSI CMIP AM prototype exists today. It has not been productized
    because no agents that provide OSI objects are known to exist. We
    are seeking such agents to test against to prove interoperability.
    
    We have investigated in excess of 30 claims of OSI agents. Most
    turn out to be DP1 CMIP (equivalent to DNA CMIP but different).
    We are exploring agents and objects with a wide variety of other
    vendors. Our message is give us your GDMO template and we will
    bring our workstation to test interoperability 6 weeks after you
    give us the template. We have been saying that for 6 months,
    we haven't any takers yet. 
    
    That indicates to me that most vendors are still only talking about
    OSI. I am not including British Telecom and French Telecom in the
    above discussion. There exists an AM that integrates the BT Concert
    alerts into DECmcc using OSI/NMF CMIP. It is a demo that will
    be productized in CY92 by the TBG organization.
    
    In addition, There are VMS system management objects that will
    be available via DNA5 AM (DNA CMIP) in CY92 from the VMS
    systems management people. There are configuration management
    objects that will be available via DNA5 AM (DNA CMIP) in CY92
    from the configuration management people. An Applitek AM is
    available from Aplitek for broadband applications and there
    is an AM for the Network Professor product from that organization.
    
    So, I would highly recommend that you propose DECmcc as a wide
    spectrum solution to the customers problem.
    
    wally

    Further explanation for 1809.1. SUN had serious limits in their
    diskless workstations. They decided to use RPC which is much
    more primitive than SNMP (which is fairly primitive) as the
    primary management protocol. They provide a mechanism where
    one PC on a LAN which has more resources can be a proxy for
    all the other PCs on the same LAN segment (?? did I get it
    right). The proxy speaks SNMP for all the others and uses
    RPC as its communication medium with the others. 
    
    wally

re 1809.2

Wally,

Have you seen the AM for the Network Professor?  I have a customer who is very
interested in this.

Regards,

Glen R.

Contact Kathy Jo Nelson.  She's the engineer from my group that's been working 
with TEC on their AM.

The AM code from them that I've seen just manages the attributes of their pods.
(i.e. collection intervals & other stuff..)    I know that they are definitely
planning more capability than that, though.

KJ?
/doug

The person who demonstrated it to me at Interop said he was the
engineer who wrote it.  He called it a prototype, and said it wasn't
for sale yet.  You indeed need their VMS-based user interface software
to actually view the data gathered by their LAN probes ("pods").  Their
DECmcc AM allows you to manipulate the pod parameters.  Being used to
the LTM style of monitoring and data collection, I found their approach
of uploading samples to the host to more suited to capacity planning
than for real-time network monitoring.

	- Andy