Last Modified: 2004-09-20
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 |
RFC | Status | Title |
---|---|---|
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 |
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. |