Subject: [nfsv4] Draft minutes for IETF 62 NFS V4 working group meetings

From: Brian Pawlowski <[email-masked]>
Date: Wed, 6 Apr 2005 09:26:33 -0700 (PDT)

Think "rough":-)

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

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