Subject: [nfsv4] welch's notes on IETF-64 meeting

From: Brent Welch <[email-masked]>
Date: Sun, 13 Nov 2005 22:11:22 -0800

Here are my notes from last week's meeting at IETF-64.
There is some editorialization on my part...  And probably errors, too.

draft-eisler-nfsv4-impid-00.txt
This is a proposal to add operations to NFSv4 that will identify
implementations.  This is useful for correlating bugs with different
vendors, and seeing what the population of clients is like.  I think
it is a great idea, although there was concern that folks would be
tempted to write special case code based on the implementation at
the remote end.  Anyone that is tempted to do that will get what
they deserve, IMHO (a world of pain later on).  An interesting observation
is that there the number of clients is on the decline, while the number
of servers is on the increase.

draft-adamson-nfsv4-spkm3-00.txt
This is about using SPKM3 for user authentication.  Right now the
NFSv4 spec specifies GSS with Krb5
and PKI in the form of SPKM1 and SPKM2, but there haven't been many
implementations of the PKI stuff, and there are apparently some
issues in the spec and/or the implementation.  This latest draft
is to try and clear up some of those issues and go to the latest SPKM.
CITI (authors of this) want to leverage Grid X.509 Globus GSI
to set up a WAN-wide grid for user authentication.

pNFS.  The draft that Benny and I started is now a working group
doc, draft-nfsv4-pnfs-00.txt.  It is 62 pages, and includes the
definitions for the files-based back end storage protocol.  The
objects and blocks storage protocols are in drafts by Jim Zelenka
and David Black@emc respectively.  We are invited to clean these
up and submit them as working group drafts by November 29.  At that
point I'd like to have both an OSDv1 and OSDv2 version in the
objects draft to support interoperability demos in 2006.

The latest pnfs draft is looking pretty good.  The latest
additions (by Garth Goodson of NetApp) include updates on callback
race conditions and error handling issues based on my feedback at
the last IETF.  There are still a number of open issues:
  Principals and stateIDs - this has to do with how the files backend
    authenticates and checks access.
  Callback serialization via sessions.  There is a proposal to add a
    session abstraction to the NFSv4 RPC stream, and that really only
    handles retransmissions in one direction, and you need to do a little
    more to help serialize callbacks.  We think we know how to do this,
    but I'd like to see it all written down.
  Still more on error handling.  Some of the new test is kind of vague
    about when clients and servers should give up or recall layouts.
  Extra flags on CB_LAYOUTRECALL to allow for a "noflush" callback break.
  Exactly how to reference the blocks and objects drafts.

The goal is to aim for demos at the Connectathon in Feb/March of 06.

There could be these files-based demos
  NetApp server
  IBM server
  CITI client and server
  Solaris client (but not up-to-date)

Byte range delegations.
Trond gave some motivators for this, such as a 
streaming video producer (a camera) and several readers.  The
idea is that the producer would have a write delegation over the
tail of the file, and the readers could get delegations to read
(and cache) the front part of the file.  In other conversations
he's talked about scenarios where you are caching a multi-gigabyte
file on the east coast, and would like to get notified about what
ranges of the file have been modified so you can fault in just
the right stuff. While I can see the utility of this,
I'm still not convinced this is needed in NFSv4.

draft-ietf-nfsv4-referrals-00.txt
This is a working group draft to clarify the NFSv4 spec on
the referrals mechanism.  This is a redirection facility where
you ask the server for a file, and it refers you to a new owner.

draft-noveck-nfsv4-migrep-00.txt
Some clarifications on the NFSv4 spec, with proposals for
additional recommended attributes:
 fs_absent, fs_location_info, fh_replacement, fs_status
and a discussion of alternative approaches.  Dave N raised
the question about the right path for the migration work.

draft-falkner-nfsv4-acls-00
The solaris folks are exposing NFSv4 ACLs (via chmod) and wanted
to clarify some issues about mapping ACLs to Unix mode bits,
as well as issues about ACL inheritance and the semantics of
everyone@ (a user id for everyone).  This effort will probably be
welcomed by users, because POSIX ACLs are, uh, klunky.  Solaris
also exposes POSIX ACLS, but it is widely viewed that the NFSv4
ACL model, being closer to the Windows model, will be better
accepted.

RDMA
The specs for NFS over RDMA are moving into working group last call.
This is done by implementing RDMA underneath the RPC layer.

NFSv4.1
This minor extension to NFSv4 will have these (optional) extensions:
Secinfo - a way to better handle pathnames that wander through
  different security domains
Sessions - the above mentioned sessions for RPC, which are a way to
  tag successive requests between a client and server so the server
  knows the client got its previous reply. (An idea that dates back to
  the Xerox-PARC RPC protocol from about 1980.)
Directory delegations - these are a way to get notifications on files
  that have been modified within a directory, or renamed, etc.
pNFS - the goal is to fold the pNFS document right into the
  main NFSv41 standard draft.

There will be weekly conference calls starting Nov 29 and an interim
meeting at the end of January to push on v4.1, with the goal of 
completing the draft before the March '06 IETF meeting.

--
Brent Welch
Software Architect, Panasas Inc
Accelerating Time to Results(tm) with Clustered Storage

www.panasas.com
[email-masked]

--
Brent Welch
Software Architect, Panasas Inc
Accelerating Time to Results(tm) with Clustered Storage

www.panasas.com
[email-masked]

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4