Subject: Minutes of nfsv4 WG meeting in London

From: Brent <[email-masked]>
Date: Wed, 15 Aug 2001 15:38:01 -0700

NFSv4 Working Group Meeting @ 51st IETF, London
-----------------------------------------------

        Reported by Brent Callaghan

After welcoming the participants and presenting the meeting
agenda, Brent Callaghan gave an update on the status of the RPC
standards that NFSv4 depends upon. Currently, RFC 1832 (XDR) is
at Draft and RFC's 1831 (RPC), 1833 (Binding) and 2203
(RPCSEC_GSS) are all at Proposed.  RFC 1831 is pending the
addition of an "IANA Considerations" (RFC 2434) section for
administration of the program number space.  RFC 2203
(RPCSEC_GSS) still awaits movement of the GSS-API standard (RFC
2743) to Draft.

Document editor, Spencer Shepler, described the "bakeoff" at the
University of Michigan/CITI as a success. The protocol was
tested between 5 implementations and no major issues were found.
He then went on to describe some updates to the protocol state
model, beginning with an pictorial explanation of the NFSv4
state hierarchy and its relationship to various threading models
(see slides). The state hierarchy begins with the clientID which
is established by the client with a SETCLIENTID call and
confirmed by the server.  Associated with the clientID is a
lockowner, which corresponds to the PID on a POSIX client. The
server has a stateid which changes after any change in status of
file locking or file open. File delegation has its own
delegation-stateid.

One problem with the file open state has come to light as the
result of implementation experience.  When a UNIX process forks,
the parent and child processes share a file descriptor to the
open file. This condition is not accurately reflected by the
file open state on the server. A proposed solution is to add
another level of indirection via an entity called a "openowner"
that can represent multiple processes on a client. Spencer plans
to incorporate the openowner into the pending updates to the
spec if the WG approves. From feedback at the bakeoff, the
implementors support this proposal.

Brian Pawlowski summarized the proposal for working group
re-charter to include on-going NFSv4 work for test suite
development, a management MIB, and a Replication and Migration
protocol. Brian agreed to submit the Re-charter text to the Area
Directors who will have the IESG consider it.

Brian summarized the aims of the replication and migration work:
Transparent, client failover for read-only replicas, good
performance across low bandwidth links, and security as good as
v4. He will work with Rob Thurlow to draft a requirements
document and publish it as an individual submission
Internet-Draft pending re-chartering the work group and since
the requirements described in this document may not be specific
to NFSv4, it will be circulated to other groups for comment.

The meeting concluded at 5:00pm.

-------------------------------

The slides from the meeting can be viewed at:

   http://playground.sun.com/pub/nfsv4/presentations/ietf51

------------------------

---

From: Robert Thurlow <[email-masked]>
Date: Thu, 16 Aug 2001 11:24:45 -0600 (MDT)

In his minutes from the NFSv4 WG at IETF 51, Brent Callaghan wrote:

> performance across low bandwidth links, and security as good as v4.

I'd like to spark some discussion about the requirements for
replication and migration.  Here are the requirements Brian
Pawlowski presented at IETF 49, lifted from:

http://playground.sun.com/pub/nfsv4/presentations/ietf49/beepy2.pdf

They're a fairly large set, and I'd like to find out who cares
about which parts.  For that matter, I'd like to find out who
cares about replication and migration; this topic has not drawn
a lot of comments on the alias in quite a long time.  I'll also
include Brian's listing of issues.

Requirements

o Transparent client failover
  o For read-only replicas and migrated writable volumes
o Performance
  o Bandwidth conservative
  o Differences propagated
  o Restartable
  o Client lockout time minimized
o Security
  o As good as V4
o Scalable
  o Huge file systems
  o Small file s ystems
o Capability negotiation between "peers"(?)
  o I believe this referred to things like attribute differences
o Efficient multi-way replication (propagation)
o Correctness
  o "Atomic" propagation of file system from client view
  o Failover to a correct replica version
o TCP/ IP based
  o No legacy UDP requirement

Issues

o Replica versioning non-existent
  o Failing over to "correct" version of replica impossible?
  o Base V4 protocol change?
  o Proposal: Investigate versioning requirement
o Single vs. multi-master
  o Multi-master entails conflict resolution
  o Proposal: Single master copy sufficient - objections?
o Disconnected operation irrelevant
  o Corollary to above
  o Proposal: Disconnected operation for clients not required - objections?
o File oriented
  o Fits with NFS model, and heterogeneous
  o Efficiency concerns
  o Block-oriented not heterogeneous
  o Proposal: Draft proposal for comments.
o Replicating "opaque" (to NFS) local file system attributes
  o Proposal: NFS Version 4 named attributes propagated - unsupported
    attributes not
o Migration/replication only for V4
  o Not a general (rdist) mechanism
o Lock and delegation propagation
  o Certainly a requirement, but ouch!
  o Proposal: Locking and delegation state propagated, acceptable
    that it resembles a server reboot.
o We pushed need for reliable name/location service from clients to
  servers
  o Proposal: Investigate how far to tie back end protocol to name
    sevice

Rob T