Subject: Re: NFS MIB ideas

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

At 19:42 14/03/01, Venkat Rangan wrote:

>- Table of current locks and their owners

        This has broad security implications and would make
me fairly nervous.

>1. Do we need to also handle v2 and v3 protocol implementations?

        That would be kind.  

>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.

>3. How much configuration and operation-level objects do we need?

        I'd be happiest with a monitoring MIB that is mostly
read-only.  Other folks in the SNMP community take the opposite
approach.

>5. Does it make sense to have a MIB for the client side as well?

        Yes.

Ran
[email-masked]

---

From: "Noveck, Dave" <[email-masked]>
Date: Thu, 15 Mar 2001 09:59:49 -0800

> 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.

Not only might such aggregation be impractical for the server, it 
might be undesirable for the user who is trying to figure out what 
is going on.

If the RPC abstraction is implemented in significantly different
ways, in the user and the kernel in your example, or integrated with
the actual service for high-performance paths (e.g. NFS), then aggregating
statistics that all belong to separate implementations of the RPC
abstraction is going to lose valuable information.  If there are
problems in the generic RPC implementation, the information might
be totally invisible since it will be drowned out by the miillions 
of NFS RPC requests that are happening with no problems.

> 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.

---

From: Mike Eisler <[email-masked]>
Date: Fri, 16 Mar 2001 08:35:44 -0800 (PST)

> 
> "Matthew J. Zito" wrote:
> > The extra info could be turned
> > on when you're trying to find specific addditional data - like
> > verifying that no client is mounting exported directory X before you
> > rm -rf it.
> 
> Actually, there's no easy way for a NFS server to establish whether a
> client
> has a filesystem mounted. NFS version 4 keeps track of which clients
> have file open, or which locks are held - but not whether the client
> has a filesystem "mounted".

NFSv[23] servers typically do a poor job of this as well. NFS servers should
implement showmount -a functionality (and any corresponding MIB
stuff) by seeing what clients have actively used what export points in
the last N units of time.

	-mre

---

From: Venkat Rangan <[email-masked]>
Date: Sat, 17 Mar 2001 15:44:08 -0800

Ran,

You have captured several interesting issues.

>         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.
>

It does appear that placing RPC MIB separately from NFS MIB
is a better approach. On having a separate set of objects for each RPC
instance,
the problem statement seems identical to the one that Application
Management MIB (RFC2564) runs into - each application has "responsibility"
for certain rows of a common table. Section 6 in that RFC gives
some guidelines.

It may be necessary to discuss an implementation architecture
in the RPC MIB, along the lines of that RFC. As a practical matter,
one could start with a core set of objects common to all RPC and
add the portion that is specific to NFS. May be NFS is the only one
to use it for starters.

>         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.
>
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.

To facilitate expansion of a certain set of core objects, the SMIv2
AUGMENTS clause allows one table in a MIB (either internal to it or
imported from another MIB) to be augmented with more objects. You can
only AUGMENT one level though, although a single Base table can be
augmented by multiple AUGMENTs.

Venkat Rangan
Rhapsody Networks Inc.
http://www.rhapsodynetworks.com

---

From: Venkat Rangan <[email-masked]>
Date: Sat, 17 Mar 2001 15:44:25 -0800

Dave,

> might be undesirable for the user who is trying to figure out what 

We can certainly add new columns using AUGMENTs and identify how the core
table entries are being used by each application. This also means that
there is a coordinated way to share the Index space, as RFC2564 recommends.

-----Original Message-----
From: Noveck, Dave [mailto:[email-masked]]
Sent: Thursday, March 15, 2001 10:00 AM
To: 'Mike Eisler'; RJ Atkinson
Cc: Venkat Rangan; [email-masked]
Subject: RE: NFS MIB ideas

Venkat Rangan
Rhapsody Networks Inc.

---

From: "Noveck, Dave" <[email-masked]>
Date: Tue, 20 Mar 2001 08:27:41 -0800

There is a set of things that the V4 spec refers to as "locks"
currently.  These include byte-range locks, delegations and
opens (yes, I've nouned that verb).  For many purposes, these
make sense to treat together because they have many common
characteristics: they are associated with stateid's, they have
an associated lease, they can be revoked when the lease period
has expired, and also (typically through administrator action)
during the lease period.

The problem is that it includes things that most people don't 
think of as locks at all.  For example a normal UNIX open for
read is not generally thought of as lock, even though it would 
lock out a CIFS open with DENY=READ.

I was looking for a word that could be used for all those 
things (byte-range locks, opens, and delegations) that wouldn't
be misleading for those who don't think of opens as locks at all.

-----Original Message-----
From: Matthew J. Zito [mailto:[email-masked]]
Sent: Monday, March 19, 2001 11:53 PM
To: Neil Brown; Noveck, Dave
Cc: Brent; [email-masked]
Subject: RE: NFS MIB ideas

At 2:02 PM +1100 3/20/01, Neil Brown wrote:
>I thinks words and names are very important, and it would be good to
>have a name for such an important concept.
>The "obvious" name is an "open", but that is a verb, not a noun, which
>will just lead to confuision.
>I recommend
>     reservation
>and I do so without any reservations :-)
>
>This word is already using in the RFC in the phrase "share
>reservation" which is something that may happen at OPEN time.
>

Well,  I like the name reservation - it fits the concept of accessing 
a resource without necessarily _doing_ anything with it.  But I'm a 
little unclear about what exactly would be changed with this - where 
would this be used and how?

Thanks,
Matt

-- 
Matthew J. Zito
Systems Engineer
Register.com, Inc., 11th Floor, 575 8th Avenue, New York, NY 10018
Ph: 212-798-9205
PGP Key Fingerprint: 4E AC E1 0B BE DD 7D BC  D2 06 B2 B0 BF 55 68 99