Last Modified: 2004-06-17
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.
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).
|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|
|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|
Network File System Version 4 (nfsv4)
Tuesday, August 3, 2004 at 0900-1130
Brian Pawlowski <firstname.lastname@example.org>
Spencer Shepler <email@example.com>
Welcome and Introduction (Pawlowski) 5 min
Agenda bash etc.
- BLUE SHEETS
- NOTE WELL
- Status of drafts
Interim meeting and bakeathon results (Shepler) 10 min
Transfer of RPC Numbering to IANA (Shepler) 2 min
On the Use of Channel Bindings to Secure Channels (N. Williams) 10 min
NFS RDMA Problem Statement (Talpey) 3 min
RDMA Transport for ONC RPC (Talpey) 3 min
NFS Direct Data Placement (Talpey) 3 min
NFSv4 Session Extensions (Talpey) 20 min
NFSv4.1: Directory Delegations and Notifications (Khan) 15 min
Migration Issues for NFSv4 (Noveck) 15 min
Server recovery issues (Noveck) 10 min
Implementation Best Practices (Pawlowski) 10 min
NFSv4 minor version planning (Shepler) 25 min
Open discussion (Pawlowski) 10 min
Wrapup (Pawlowski) 5 min
Beepy welcomed and introduced; reviewed "note well" and started the blue sheets for attendance.
Spencer covered the status of the existing drafts and working group milestones. Noted that the milestones are woefully out of date and that effort to update will start very soon.
The XDR draft is ready for working group last call and as a reminder this will be for a move to Internet Standard. Rob Thurlow has updated the RPC draft and that too, after one round of minor updates, will be ready for working group last call. Still working the issues of transfer of RPC program number assignment to IANA but that will be dealt with as part of the normal update to the RPC RFC and Sun will be seeding the number allocations based on its record. An I-D explaining the transfer does exist.
The draft on V4.1 SECINFO minor version item is considered complete - locked down and ready to go. CCM is GSS exploit of underlying transport to eliminate double encryption is also ready. Plan is to divide labor between us and security area.
Tom Talpey mentioned that the NFS/RDMA problem statement is a working group draft and will be taken forward as an informational RFC. The RDMA transport/DDP is intended for minor versioning.
Note that the current directory delegations I-D is targeted as a minor versioning items as well.
Note that the ACL mapping I-D has not been refreshed.
Spencer reviewed the interim meeting results at the Bakeathon in June.
- Talpey added additional author and updated the sessions draft.
- Saadia has updates from discussion to directory delegations draft.
- ADs have agreed we have good things queued up for minor versioning.
- Interim meeting interrupted by tornado warning.
On with the regular presentation section:
"On Channel Bindings" - Nico Williams. About how you avoid double encryption, exploit a secure channel underneath. Point is to have a lightweight authentication based on Eisler's notions to allow leverage of a secure channel. Intended for use in RDDP and other NFS deployments (leverage HW acceleration). Back and forth with Talpey and Nico on negotiation of channel bindings - who owns, implementation choice? Nico says GSS/RPC layer will own. David Black and Nico chatted about I-Ds and peers and men in the middle and ... "Group pre-shared keys work just fine with IKE," David Black.
Talpey NFS-RDMA drafts. Three of them describing protocols. RDMA for ONC RPC - enables RDMA also for V2 and V3 - but not spending much time discussing legacy lock manager etc.
ONC RPC over RDMA - a WG item. Inserts a slightly more complex marker to allow marshalling RDMA data. Leverage copy avoidance. No semantic extensions. Since last Ann Arbor meeting - chunking only impacts data.
NFS Direct Data Placement - republished in July as a working group item. See slides for more details. NFS is blissfully unaware of most issues with RDMA usage beyond providing a buffer target.
V4 Sessions draft - Jon Baumann added as co-author given changes he has introduced from his server work. Sessions are not RDMA specific - but there is a chapter on use of sessions with RDMA. See slides. Talpey argued that XIDs are wimpy - tightened up with sequence ID. Chaining removed in Ann Arbor - ordering constraints were its downfall. Sufficiently large COMPOUNDs get around it. Session BIND went away - problem arose in reconnect, which is an RPC level recovery, unable to force an NFS op into the rebind sequence which was serious layer violation.
Saadia Khan - directory delegations and notifications. To reduce traffic between client and server. Saadia covered the changes introduced in Ann Arbor - see slides. Need attribute notifications with directory notifications. Draft currently defines notifications as asynchronous - but needs further discussion. Currently depends on sessions being in V4.1 - will have to be changed if sessions fails to make it. Spencer said synchronous notifications would enable negative lookup elimination - big win. Saadia to follow up with a the problem statement and nail requirements on the feature on the alias.
Noveck on migration, replication and referrals. Some issues with RFC 3530. He produced an I-D. Noveck argues that while not explicitly mentioned, referrals exist. But referrals (telling a client attempting to access a recently moved file is somewhere else) seem to work. Evanescent file handles - the Quantum Mechanical view. The file handle for a migrating root file system. Garth Gibson observes this is Windows DFS like functionality. What about a global name space - referrals do not define a server to server communication to join to construct one. See slides... Description needs work in spec moving forward to clarify referrals and have explicit section. Errata? In V4.1? How to deal with clarification.
Noveck - Lock Recovery Delimitation... section 8.6.3 issues. Need mechanism to determine when a client is done reclaiming locks in face of network partition during lock reclaim. Edge condition. Argh. Fix possibilities. Client can back off on reclaim in face of rebooting server. But server may persistently store locks to remember the sequencing. Spec tries to allow for servers that explicitly store lock state. Trond suggests using setclientid to time shift grace period forward - there may be a workaround here - need to follow up. Noveck observes it does not work with servers that implement persistent locks. Grace period length is issue - Noveck observes long grace period in conflict with non-reclaim OPENs. Wants ti introduce DONE_RECOVERY op. Want closure on this on the list.
Beepy discussed implementation doc proposal. Practical status of NFSv4: numerous v4 releases are in the pipeline. 4Q04 and 1Q05 will get interesting! I.e. users will begin to see this
How to turn it off?
How to turn it on!
Security negotiation ("strongest security") may be problematic going forward - needs careful doc. We need to manage the v2/v3 legacy interactions through doc.
Beepy wants to resurrect the "implementation document". Focus on best practices. Not a client implementors doc, but a description of implementations for sysadmins and users. Also document the protocol features (with an eye toward having it as we move to Draft Standard).
Beepy intends to produce this document by September 30. Informational RFC track.
Shepler - Minor Versions. I-Ds are piling up. Implementations and deployment experience are pointing to additional fruitful areas to pursue. (Earlier, beepy asked about how minor versions put out - separate addendum doc? whole new doc with 4.0 core/fixes?) Issues? Limit content - set time. One RFC or separate docs? Shepler to talk to ADs how to proceed on docs and proposal to list.
Ran out of time and things to discuss at the same time. Meeting ended.