2.8.12 Network File System Version 4 (nfsv4)

NOTE: This charter is a snapshot of the 61st IETF Meeting in Washington, DC USA. It may now be out-of-date.

Last Modified: 2004-09-20

Chair(s):

Brian Pawlowski <beepy@netapp.com>
Spencer Shepler <spencer.shepler@sun.com>

Transport Area Director(s):

Allison Mankin <mankin@psg.com>
Jon Peterson <jon.peterson@neustar.biz>

Transport Area Advisor:

Jon Peterson <jon.peterson@neustar.biz>

Mailing Lists:

General Discussion: nfsv4@ietf.org
To Subscribe: https://www1.ietf.org/mailman/listinfo/nfsv4
Archive: http://www.ietf.org/mail-archive/web/nfsv4/index.html

Description of Working Group:

The objective of this working group is to advance the state of NFS
technology by producing specifications to extend the original NFS
Version 4 work (RFC 3010) to provide additional capabilities, as
described below.

o NFS version 4

  Advance the protocol along the standards track, coordinating the
  development of test suites to provide a high level of implementation
  quality. The ONC RPC standards that NFSv4 references must also be
  advanced. This includes work to make NFSv4 and the underlying ONC RPC
  protocol compatible with IPv6.  Specifically, we will advance RFC
  3010, RFC 1831, RFC 1833 and RFC 2203 to Draft Standard. The working
  group will help advance related security RFCs, specifically through
  the definition of a method to advance APIs.

o Replication and Migration

  The original working group defined a mechanism for NFS clients and
  servers to support replication and migration of data transparently
  to an application.  Left undefined in the initial work was the
  server back end migration and replication mechanism.  The working
  group will produce a draft submission of a replication/migration
  protocol that supports NFS Version 4 clients - needed to create and
  maintain replicated filesystems as well as migrating filesystems
  from one location to another -  and servers for consideration as
  Proposed Standard.

o Management

  The working group will produce a draft submission for consideration
  as Proposed Standard of a management MIBs to provide better
  management and administration capabilities for NFS and ONC RPC.

o Minor Versions

  NFS Version 4 contains within it the capability for minor versioning.
  Some discussions within the working group suggest addressing
  additional requirements over the original charter.  The WG will work
  to identify additional requirements for NFSv4 and determine if they
  are appropriate and worthwhile for a minor version.  This work may
  lead to proposals for additional work items.  If it does a specific
  proposal to add these work items to the charter will be forwarded to
  the IESG and IAB.

o RDMA/RDDP enabling

  The performance benefit of RDMA/RDDP transports in NFS-related
  applications, by reducing the overhead of data and metadata
  exchange, has been demonstrated sufficiently such that the
  working group will pursue in parallel enabling NFS and RPC over
  the transport defined by the RDDP working group. The WG will
  restrict its initial activities to defining the problem
  statement and specifying the requirements for possible
  extensions to RPC and NFS (in the context of a minor
  revision).

Goals and Milestones:

Done  Issue strawman Internet-Draft for v4
Done  Submit Initial Internet-Draft of requirements document
Done  Submit Final Internet-Draft of requirements document
Done  AD reassesses WG charter
Done  Submit v4 Internet-Draft sufficient to begin prototype implementations
Done  Begin Interoperability testing of prototype implementations
Done  Submit NFS version 4 to IESG for consideration as a Proposed Standard.
Done  Conduct final Interoperability tests
Done  Conduct full Interoperability tests for all NFSv4 features
Done  Update API advancement draft
Done  Form core design team to work on NFS V4 migration/replication requirements and protocol
Done  Submit revised NFS Version 4 specification (revision to RFC 3010) to IESG for consideration as a Proposed Standard
Done  Strawman NFS V4 replication/migration protocol proposal submitted as an ID
Mar 03  ADs to submit API advancement internet draft as informational RFC (needed to advance GSSAPI to Draft Standard to allow advancement of NFS Version 4)
Mar 03  Continued interoperability testing of NFS Version 4
Apr 03  Internet draft on NFS V4 migration/replication requirements
Apr 03  AD review of NFS V4 migration/replication requirements draft
Apr 03  Creation of internet draft on ONC RPC MIB
Apr 03  Revision of internet draft on NFS MIB
Apr 03  Draft problem statement I-D for NFS/RPC/RDDP submitted
May 03  Document full Interoperability tests for all NFSv4 features
Jun 03  Depending on results of AD review of NFS Version 4 migration/replication requirements document, review scope of task
Jun 03  Submit related Proposed Standards required by NFS Version 4 for consideration as Draft Standards to IESG - RFCs 1831, 1833, 2203, 2078, 2744, RFC 1964, & 2847
Jun 03  Draft requirements document I-D for NFS/RPC/RDDP submitted
Jun 03  Submit ONC RPC and NFS MIBs to IESG for consideration as Proposed Standards
Jun 03  Submit an NFS V4 migration/replication protocol to IESG for consideration as a Proposed Standard
Jun 03  Submit report on results of NFS version 4 RFC interoperability testing
Jul 03  AD review of NFS/RPC/RDDP progress and charter
Jul 03  Interoperability tests of NFS V4 migration/replication
Aug 03  Submit revised NFS Version 4 Proposed Standard for consideration as Draft Standard to IESG

Internet-Drafts:

  • draft-ietf-nfsv4-rfc1832bis-04.txt
  • draft-ietf-nfsv4-ccm-03.txt
  • draft-ietf-nfsv4-secinfo-02.txt
  • draft-ietf-nfsv4-rpc-iana-02.txt
  • draft-ietf-nfsv4-rfc1831bis-04.txt
  • draft-ietf-nfsv4-acl-mapping-02.txt
  • draft-ietf-nfsv4-channel-bindings-02.txt
  • draft-ietf-nfsv4-nfs-rdma-problem-statement-01.txt
  • draft-ietf-nfsv4-rpcrdma-00.txt
  • draft-ietf-nfsv4-nfsdirect-00.txt
  • draft-ietf-nfsv4-directory-delegation-00.txt
  • draft-ietf-nfsv4-sess-00.txt

    Request For Comments:

    RFCStatusTitle
    RFC2623 PS NFS Version 2 and Version 3 Security Issues and the NFS Protocol's Use of RPCSEC_GSS and Kerberos V5
    RFC2624 I NFS Version 4 Design Considerations
    RFC3010 PS NFS version 4
    RFC3530 PS Network File System (NFS) version 4 Protocol

    Current Meeting Report

    NFSV4
    IETF-61

    beepy blue sheeted, noted well, and agenda bashed.

    Draft Status (Shepler)

    Spencer covered draft status. XDR draft cleared WG last call on way to become an Internet Std.

    Talpey (review of sessions proposal and status)

    RDMA draft needs to reflect Robinson and Mallakarjun comments - alpey owns.

    Sun will be proto'ing directory delegation to gain feedback targeting Connectathon in February.

    Two new individual drafts on pNFS to be presented today. Domain names etc. from Sun colleague (not discussed).

    Bakeathon (Shepler)

    ACLs were focus of testing at University of Michigan in October. Issues on semantics of ACLs (interpretation) vs. ambiguity in existing Posix implementations. On-going discussion.

    SECINFO work needed. But people are focused. Shepler wants ACL discussion to be forwarded to list arising out of Bakeathon.

    NFS Sessions Experience (Talpey)

    Talpey described NFS Sessions and recent experience in implementation. See the slides...

    Discussion of ransport diversity, trunking (really for performance). Big addition is the reliable at-most-once semantics (fixing the Duplicate Request Cache).

    Linux prototyping is occurring under the RDMA umbrella. Is passing Connectathon tests. Three things remain to be prototyped on client (see slides). Server testing is being accomplished with a Linux client and an extended pyNFS test rig. Pointed to CITI's work -- implementing just the sessions 4.1 (linux 2.6.9 is latest target -- only over tcp). RDMA TBD for sessions testing.

    What we have learned:

    - client is complete
    - still dealing with slotid (protocol) and implementation interaction
    - server is passing connectathon

    Implemented server transport switch. Sessions will be performance neutral (expected to be). Performance (user-level workloads) is of interest to explore. Sessions/rdma are separate -- sessions can enchance the use of rdma. Harmony between them - (RDMA is at the RPC transport).

    Discussion of details of NFS over RDDP and will there need to be an NFSv4 minor version update to provide for this. What interop issues when server has a mismatch of RDDP support? Will need an RPC mapping for SCTP to try testing that later - new transport type for RPC and well defined behavior of failure.

    Want to do performance measurements. Report progress at Connectathon. FileBench work at Sun for performance testing.

    RDMA is an RPC level specification, different than sessions. RPC RDMA spec is in good shape, and can be advanced. RDDP drafts to go to WG last call around Thanksgiving. We need to advance - RDMA can be advanced independent of minor versioning of NFS. The RPC negotiation will handle RDMA or not between server and client... (beepy is still waking). Nico and Tom and David mixed it up on RDMA negotiation. Nico may follow up offline.

    AI: Talpey needs to get some notes out on mail list. Define open issues. And drive to ground RDMA stuff. Brent/Talpey to drive draft forward.

    Need to review security angles of RDMA and TCP transports.

    AI: What is status of CCM? Nico to work with Mike following meeting. Draft to progress through nfsv4 WG with coordination with security group.

    RDDP status from David Black. beepy: Are there implementations?
    David: Yes!

    Global Namespace and Migration (Fan)

    Summary of state of knowledge coming.

    Using his newcomer view to bring insight into the problem and to move it forward. Namespace - Enterprise Namespace is the key to a workable solution for "cluster" and "world wide"

    Charles' view of requirements:

    - location independent users want logical location (not "which server")
    - uniform namespace
    - transparent to change
    - secure

    DISCUSSION: beepy mentioned that the fsid/filesystem mapping will raise a management issue

    Rainfinity product is at the directory level. The considerations slide is trying to capture the granularity of the referral (bogus comment).

    Attempts to capture the client/server issues:

    - purely client-based
    - automounter (managability of it is bad - that is feedback to charles)
    - update of maps is not deterministic

    DISCUSSION: beepy points out that there needs to be policy enforcement to overcome the provincial view of automounter

    beepy raised issue of what is managed entity for things like migration, name space junctions, etc. beepy reflected history of lack of agreement on heterogeneous view of thing to migrate (run afoul of file system implementations, and protocol in back end to move atomically, etc.)

    Nico mentioned distinction of location independence and name space construction.

    Is this as simple as LDAP schemas? and best practices for client on how to use. What is goal? Limit protocol support and define best practices? beepy believes reasonable customer requirements are simple for name space.

    What are the pure technical issues - things like volatile file handle solve more problems than introduced.

    Charles wants to move forward with defining what is in scope and what is out of scope. Nico said many little problems with lots of disagreements.

    Parallel NFS Requirements and Design Considerations

    NFS as metadata server - data access can be multiplexed over a variety of transports. Scale in number of dimensions.

    Nico stood up and went to mic on security issues. This will be a lot of discussion in future (access control in face of "insecure" back channels?). "You can do better."

    Heterogeneous parallel file access and back channel failure recovery by devolving to pure NFS Version 4 for completing access? Massive discussion. beepy tried to move on - this will be covered moving forward. beepy observed completely out of scope is modifying security of existing back channel protocols.

    Scalability - Spencer has questions... What about availability and reliability - what problems are introduced? Brent breaks down to data availability and metadata availability? What is in scope and out of scope?

    beepy winced on hearing pNFS server clean-up issues in event of RAID striping from client. Need an exposition of the errors and strangeness introduced by enabling pNFS stuff.

    Block reorganization - requires callback to update maps for block to file mapping...

    Managing the spec - what will core pNFS spec specify? How are new back channel protocols "added" - how generic is the mapping structures? How are extensions managed?

    What are restrictions on callback (similar to delegation callback issues in NFS) in pNFS?

    Spencer raised the following questions throughout:

    - why choose the various backend protocols? (SBC, OSD, NFSvX)
    - what is the assumed operational model?
    - pNFS server is responsible for ultimate negotation with the "data servers" to obtain data (always NFSv4.0 accessible)
    - Interoperability? What is the requirement/goal? Server's will have their own filesystem layout, propose to publish mappings and interactions with server?
    - Scalability talked about (what about availability/reliability?)

    Scott Bradner asks if LAYOUTGET/LAYOUTCOMMIT reclaims by the server. Other discussion about LAYOUTRELEASE proposed operation.

    How is pNFS work going to be done in WG - coordinate resources, etc.?

    beepy: Above all - do no harm.

    Important Dates in Future

    Connectathon will run February 24 - March 3, 2005 - right before the Spring IETF meeting March 6 - 11, 2005 in Minneapolis.

    Slides

    Agenda
    NFS Best Practices
    pNFS extension for NFSv4
    pNFS: Requirements
    I-D Status
    NFSv4 Namespace & Migration
    NFSv4 Sessions Implementation Update