Last Modified: 2005-01-07
| 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 |
|
IETF 62 NFSv4 WG meeting --- Monday, March 7, 2005 7:50:02 PM --- Welcome, Agenda Bash etc. - beepy beepy blue sheeted, noted well, and agenda bashed. I-D Status - Shepler XDR moving through IETF last call. For consideration as Standard. RPC update from Thurlow is nearly ready? ACL mapping, Carl Burnett form IBM may get involved. RDMA - substantial revision Talpey will cover for RPC draft. Talpey to give update on sessions stuff. Shepler to wrap into a minor revision draft. Directory delegations - alternate proposal from Wickman at CITI. Saadia Khan has the other proposal. We will have a lively e-mail discussion. Saadia to post any feedback from Connectathon presentation to the alias. CCM and channel bindings. Drafts - have to move forward, how? Eisler says should progress with the RDMA stuff. Shepler asked if we need implementation experience. Eisler to retrigger draft. Nico is doing some prototyping. Noveck and Carl Burnett have written an interpretation draft around migration/replication on how to construct name spaces. How to move pNFS from individual to WG draft. beepy would like to see file flavor support shuffled in with Brent Welch's core draft as next step to move forward. Shepler says we need to give heads up to ADs. Connectathon - Shepler Normal NFS V4 testing went smoothly. ACL testing. Replication and Migration (get more comments from Shepler here) pNFS prototype from Sun and NetApp were played around with. RPC/RDMA draft - Talpey RPC level attack to enable RDMA support at minimum level for NFS. Mallakarjun comments are folded into the document. Including clarifications. We think document has no open issues at this time. Protocol itself is unchanged. Some new information on chunking rules. A lot of clarification on ... terminology. Draft is not completely bound to RDDP draft. Session Draft - Talpey Fourth major document updated in February. Reflects some implementation experience. Talpey talked about mgmt of sequence ID to prevent replays. Failed to document the CB_SEQUENCE operation, SEQUENCE operations has a sequence-id and a slot id - draft suggests that 1-bit can be used but that is not correct for unreliable/unorder transports; Talpey to follow up with additional detail. (Over UDP neither reliable nor ordered. Talpey hasn't thought about all permutations). Implementation experience - several. Sessions client on Linux and a server. Sessions client on Solaris. Sessions side had a protocol incompatibility. Linux sessions server was complete except for old version of draft and callback channel support is missing. But the implementations and issues arising from work was discussed amongst the developers at Connectathon. Mike Stolarchuk presented experience with using the callback channel in the client at Connectathon. Security of callback channel needs to be resolved Transport Switch is being used by Groupe Bull to do IPv6 work. Some IB and iWARP. Protocol on wire independent of wire type. (discussion with Mallakarjun) Changes will be pushed into Linux 2.6.12 (the transport switch fixes). Linux prototype on CITI UMich web site (see slides). pNFS Operations Summary - Brent Welch Brent gave a brief overview... Support parallel I/O to storage, adds concept of a layout to data to allow finding it (in a parallel world). Lots of proprietary solutions in this area (background). See slides. Motivated why add 'p' to NFS (parallel == performance). David Black says open issue on EOF update... Issue on overlapping layouts. More discussion needed here. Eisler asked about attributes being in sync - totally controlled by the metadata server (except perhaps EOF). GETATTR to data servers will yield unpredictable results... beepy is sitting here thinking of - the metadata server as a bottleneck - fundamental scalability issues in number of data servers? - availability issues of metadata server - etc. Garth Goodson had a NetApp pNFS server prototype, Sun had a pNFS client - they interoperated. Main thing that came up were error recovery cases... Brent covered OSD and T10 and stuff. David Black objected to the use of the word "signed" in context of capability communicated by metadata server for a given OSD device. Capabilities allow impersonation - capturing a capability is worse than capturing data... you want an encrypted channel between client and metadata server...but infrequent operation? Lots o' description of OSD capabilities... I attach here Spencer Shepler's pNFS talk notes mostly unedited, covering the same material: - Review of pNFS model - Proprietary solutions that provide parallel access - NFSv4 is THE standard protocol and extend it to provide feature set - performance requirements: e.g. 1Gbyte of data per 1 Teraflop of processing - Gary Grider - T10 metadata standards (for Panasas solution) - moving to specific operations - David Black mentions the EOF update issues - Went on to a question whether attributes on a data server (for a file) are interesting -- should they be interpreted? No, the meta-data server is the place to pick up the correct attributes - Brent mentioned the cthon testing of Netapp/Sun work - Sez that additional text is needed around the error recovery issues because of the additional parties involved in the filesystem interaction (client, mds, data-server) - Moved onto a discussion/review of the object model (capability based security scheme) - object-store knows about attributes like size and capacity - Eisler asked about the difference between object-store and NFSv4 data-servers - Brent admits that the major difference is the security protocol used to access the object-store - Object-store will have a limited set of attributes - Security capability of object-store - capability encodes (stuff) and is not specific to the principal - question about the need to keep the capability secret (not specific to the client) - capability can be revoked by the server by setting the version on the capability -- applies to all outstanding capabilities - capability has a time expiration (server determined) - signing == compute the HMAC - capsignature is used to sign the requests to the object-store - Question whether the gssapi infrastructure can be used to protect the LAYOUTGET for protection of the capability Wickman on Directory delegations Brian Wickman from the University of Michigan CITI group presented an overview and alternat proposal for directory delegations. - Directory Delegations for NFSv4 - review of file delegation mechanism - applications shouldn't have to be tooled specifically to have an advantage with directory delegations - delegate portion of directory state to client filename to filehandle bindings file attributes anything else? - review of the options for directory delegation solution - review of Saadia's proposal - The Wickman proposal REQUEST_DELEGATION no new callbacks no notifications, existing data structures maintained read/write delegations are specified minimal information, coarse-grained implementation more straightforward NOTE: delegation does not provide for delegation of attributes of objects within the directory. Nico observed that if the directory is changing frequently then callbacks would be desired; Wickman does not protest (foreshadow of his study/data?) Write delegation is a little bizarre (...) Question about how directory write delegations would work in the current client model; Wickman suggests that the client can "fake" the attributes until a stat() is done and then the client can flush the creation/data. write delegation infer the need for STATEID (current stateid) How to evaluate the proposals TODOs beepy wondered if Saadia's proposal and Wickman's proposal can be reconciled with optional behaviour? Open discussion For pNFS deliveries, beepy thinks we'll be going after separate drafts to get parallelism in the workgroup and slice the problem up: pNFS with file layout separate drafts for object and blocks ----- End of forwarded message from beepy ----- |