Subject: Re: NFS MIB ideas

From: Mike Eisler <[email-masked]>
Date: Thu, 15 Mar 2001 07:37:14 -0800 (PST)

> >2. Do we need a separate MIB for RPC layer?
> 
>         Yes.  Different protocols/layers should be in
> separate MIBs.   For example, I might not be using NFS,
> but might be using RPC and so examine the RPC MIB without
> regards to NFS at all.

RPC is typically not implemented in a common shared kernel module the
way nfs, udp, tcp, and ip are. While there are opportunities to
aggregate  in a O/S kernel the statistics and other information an RPC
MIB might report (and in the kernel the major consumers of RPC are NLM
and NFS, and in NFSv4 there is no separate NLM protocol), this is not
so easy in user space. Unless the MIB specification mandates
implementation of infrastructure maintain a shared database of
information for user level RPC consumers, the notion of examining *the*
RPC MIB seems impractical.

It would be more expedient for each ONC RPC-based service to include
the same RPC information in their MIB, similar to what nfsstat -r
reports on many implementations. I'm not an snmp expert, but presumably
there is a notion of defining a common MIB types that other MIBS can
incorporate.

	-mre

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 15 Mar 2001 10:54:48 -0500

At 10:37 15/03/01, Mike Eisler wrote:
>information for user level RPC consumers, the notion of examining *the* RPC MIB seems impractical.

        Having multiple instances of the RPC MIB might be a
fine alternative.  However, by definining each MIB separately, 
we potentially could get multiple instances of the RPC MIB
in a single system (one for each application, using your scenario).
        
        Another reason to separate the MIB definitions is that
NFS is much more likely to change than the underlying RPC protocol.
Definining them separately lets NFS MIB evolve without impacting 
the RPC MIB.  I suspect that if the RPC protocol changed, that
both the NFS MIB and RPC MIB would necessarily change, 
but perhaps not.

        In any event, a MIB specifies an abstraction, not an
implementation.  Even if specified separately, both the RPC
MIB and the NFS MIB could be implemented together -- if that 
was sensible in a particular NFS implementation.

>reports on many implementations. I'm not an snmp expert, but presumably there is a notion of defining a common MIB types 
>that other MIBS can incorporate.

        Hmm.  The problem is that network management systems
generally know about the specific objects as OIDs, not generally
as higher-level entities.  So I don't know that what's feasible
with the SMI is what you are thinking of or what would be 
operationally useful.

        My own operational experience with SNMP and MIBs is
that modularity is really important.  MIBs that aren't 
sufficiently modular (e.g. DOCSIS RF MIB, DOCSIS CD MIB) 
tend to cause operational problems as they mutate over time.
So I'm strongly inclined towards a greatly modular approach
to MIB design.  

        Perhaps others have contrary experience ?

Ran
[email-masked]

---

From: Brent <[email-masked]>
Date: Thu, 15 Mar 2001 17:46:14 -0800

Mike Eisler wrote:
> so easy in user space.

Yes, this will be a problem if SNMP is unable to distinguish
individual instances of a service running on a host.

My hope is that it would be possible to make SNMP queries
specific to a particular port on a machine and collect
data from the service listening on that port.

If I'm interested in the RPC statistics for the service
on that port, then I'll use the RPC MIB.  If it's the
NFS stuff, then the NFS MIB.

	Brent