Minutes for NFSV4 at IETF-interim-2011-nfsv4-1
minutes-interim-2011-nfsv4-1-00

NFSv4 Interim Working Group Meeting
Feb 18, Feb 19 - Sunnyvale CA


Agenda - Feb 18
---------------

Intro/Blue Sheets/Note Well
Agenda Bashing
Working Group status and interim meeting goals
NFSv4 bis issues
Userid Translation in AUTH_SYS Environments
LEASE_MOVED error handling
RFC 5664 pNFS Errata
Simple and Efficient Read Support for Sparse Files
FedFS Domain Roots
NFSv4.1 pNFS Open Issues
pNFS LAYOUTCOMMIT optimizations

Agenda - Feb 19
---------------

Intro/Blue Sheets/Note Well
Agenda Bashing
LAYOUTCOMMIT
Remaining Issues from pNFS issue discussion
Server-Side Copy Implementation Experience
NFSv4.2 Structure and Content
pNFS File Servers Implementation Strategy
pNFS over IPv6
Performance Related Issues of NFSv4.1/pNFS
Secure NFS in 4.x
Multi-layout pNFS server support
FedFS implementation issues


======================================================================

Opened meeting with normal Note Well statement and blue sheets.

----

Spencer briefly covered the current status of the working group and
current charter items.  Current working group charter is maintenance
with the exception of FedFS and FedFS is coming to the maintenance
portion of its lifecycle.  The goal of the interim meeting is to close
on long, outstanding issues; these issues cover the RFC3530bis work
along with NFSv4.1 issues that have been found through implemetnation
experience.  Once those agenda items are cleared, NFSv4.2 structure
and content will be discussed with the intent of drafting a charter
update such that NFSv4.2 work is included.  Timeline will be to
discuss the draft charter with Area Director during Prague meeting.
Close on issues and move forward.

----

Next up was the review of the remaining RFC3530bis issues as
identified by Tom.  The minutes will not reflect the desposition of
these items.  Please refer to the detailed notes published to the
working group alias.
http://www.ietf.org/mail-archive/web/nfsv4/current/msg08996.html

All items were discussed and reached consensus during the meeting.
(editor's note: I-D will follow normal last call process; this will
allow for working group review of final set of changes for RFC3530bis)

----

UserId translation issues

RFC3530 defined use of strings to identify users and groups for file
and directory attributes.  There has been deployment issues with NFSv4
because of translation issues from commonly used numeric user/group
ids and the string based identifiers.  Tom H. wanted to bring that
discussion tot he working group in an attempt to find common ground on
clarifications for NFSv4 to simplify NFSv4 deployments.

It was noted that RFC3530 allows for a method of user/group
identifiers to be simple string representations of the numeric ids
without the use of the @domain suffix.  Unfortunately, the language in
the RFC is very discouraging and some implementations have avoided the
use of string numeric IDs because of it.  The agreement of those in
attendance was that if the issue was a deployment blocker and if,
after this much time in the field, methods have not been found to work
around the deployment issues then the language should be relaxed.

In summary, for AUTH_SYS environments, it is acceptable to use
stringified numeric representations for user and group identifiers.
This will allow for NFSv3 to NFSv4 transitions for those environments
that are not deploying Kerberos.  Suggestions will be made to allow
for configurations of servers and clients to adapt behavior for those
environments that would prefer the use of @domain suffix.

Will be included in the RFC3530bis work

----

LEASE_MOVED error handling

Trond reviewed the issue in having the client clear a LEASE_MOVED
error from the server.  The server is supposed to keep returning the
LEASE_MOVED error until it is received by the client.  The client
doesn't have a method, in NFSv4.0, to identify which of the
filesystems have moved.  It must then query each one being access to
clear the error.

The conclusion was that both types of clients (those that support and
do not support migration) must query the server when LEASE_MOVED is
received.  The query would be of the form: 
PUTFH + GETATTR(fs_locations) + RENEW

This sequence allows the client to obtain the location information for
each of the filesystems in question.  The RENEW operation allows the
server to identify the client such that it knows which clients are
querying for which filesystems.

Tom Haynes will work to incorporate into 3530bis

----

RFC 5664 pNFS Errata

Benny reviewed the implementation experience for 5664 and what issues
arose with the document.  There seem to be a short number of issues in
the text that need to be corrected.  The corrections do NOT require
over-the-wire format changes.  However, there are changes that are
impactful (e.g. what algorithm to use for RAID-6 support).

Spencer suggested that the errata text be sent to the working group
first.  This will allow for comment/feedback before the items are
submitted to the RFC errata pages.  This will allow for faster
approval/clearance when the errata are formally submitted.  This
review will also allow for a final decision of whether a 5664bis
should be done to clean up the issues.

----

Simple and Efficient Read Support for Sparse Files

Bruce reviewed his proposal and there was much discussion.  There is
interest in seeing this support in NFSv4.2.  However, there was some
concern about details of the proposal.  The detailed notes of the
meeting capture that discussion.  Dean agreed to rework his proposal
to leave the basics in place given that consensus seemed to be moving
towards a simple mechanism that allowed for effective reading of
sparse files.  Dean to update his I-D.

----

FedFS Domain Roots

With the completion of the base FedFS work, Chuck presented 3 open
issues to solicit feedback.  First was the issue that FedFS provides
NFSv4 clients access to the root of the namespace and that portion
of the namespace is a collection of referrals.  This varies from
AFS where the client was able to "walk" into a writable version
of the filesystem.  With FedFS, the cilent would have access to
the writable portion of the referral portion of the tree.  Is that
desired or useful?

With the use of DNS SRV records and their weight, the client is
vulnerable in the event of a server reboot.  The client may make a
hard reference to that server and thus be vulnerable if things change.

Current state is that NFS is the only protocol supported; James
pointed out that the intent was to allow for extensibility such that
SMB could be included in the future.

----

NFSv4.1 pNFS Open Issues

Prior to the meeting, Dave Noveck had captured the set of outstanding
NFSv4.1/pnFS related issues into a single document.  This document
captured the choices available to the group.  This document is what
was reviewed during the meeting.

The original email/document resides here:
http://www.ietf.org/mail-archive/web/nfsv4/current/msg08938.html

The detailed meeting minutes capture the discussion and invidual
resolution of the items.  On the first day, a small number of details
were not discussed and we picked those up on the second day.

A brief summary is that a choice was made for all items and the
resolutions will be worked as needed.

----

pNFS LAYOUTCOMMIT optimizations

One of the major issues left unresolved is the use of LAYOUTCOMMIT.
Is the client required to use it?  Under what conditions should/must
be used?  What do server want to see or not see with respect to
LAYOUTCOMMIT?  What is the relationship with classic NFS close-to-open
cache consistency semantics.  These were the issues touched upon
during the discussion.

The outcome of the discussion was the realization that current
operations and return values could be used to communicate when the
client was required to use LAYOUTCOMMIT.  Mike volunteered to capture
the results and presented ideas on the second day.  We now have a
simple table that describes the use of WRITE-to-data-server return
results, what COMMIT does at the data server and meta data server.


Here the summary table.  Mike's presentation should be consulted for
further context.

Value of NFL4   WRITE to          Meaning of     Meaning     LAYOUTCOMMIT
UFLG COMMIT     Data              COMMIT to      of COMMIT   needed?
THRU MDS bit    Server            Data           to MDS
in layout       returns           Server
=========================================================================
Not set         UNSTABLE4         DATA_SYNC4     Nothing     YES
Not set         DATA_SYNC4        Nothing        Nothing     YES
Not set         FILE_SYNC4        Nothing        Nothing     NO
Set             UNSTABLE4         Nothing        FILE_SYNC4  NO
Set             DATA_SYNC4        Nothing        FILE_SYNC4  NO
Set             FILE_SYNC4        Nothing        Nothing     NO

-- Note that client can always 
   demand FILE_SYNC4 or DATA_SYNC4 in WRITE's arguments


----

Server-Side Copy Implementation Experience

Pranoop provided information about the Netapp prototype of the
server-side copy functionality as described in the I-D.  Good
experience gained from the implementation and the details of that are
in the presentation.

----

NFSv4.2 Structure and Content

This item captured aspects of timeline, form, and content for NFSv4.2
with the intent of driving an update to the working group's charter.
The summary of the discussion was captured and sent to the working
group and replicated here.

============= From working group email ===================


At the interim meeting, we discussed NFSv4.2.  This message is a
summary of that discussion, a plan for next steps, and a further
determination of rough consensus within the broader scope of the WG
alias.

Our current working group charter includes maintenance of NFSv4.0,
NFSv4.1, and the RPC/XDR protocols.  With completion of the Federated
Namespace I-Ds, that charter item will move to maintenance.

The discussion and concensus at the interim meeting was to add a
working group charter item for the development of NFSv4.2. 

The group reviewed a set of options for how best to manage NFSv4.2
content and timeline.  The eventual conclusion was to focus NFSv4.2 as
a time limited deliverable.  The premise is that solid proposals exist
today for NFSv4.2.  Setting a deadline for NFSv4.2 delivery will act
as a forcing function to complete existing proposals and if other less
mature proposals reach a similar level of maturity, they can be
included in NFSv4.2 as well.

The timeline chosen during the meeting was 1 year; for example,
NFSv4.2 ready for working group last call by March 2012.

The next topic was what physical form NFSv4.2 would take.  An NFSv4.2
RFC will not document the entire protocol.  NFSv4.2 will build from
the NFSv4.1 RFC and note only the functional additions or semantic
clarifications required to build NFSv4.2.  NFSv4.2 may or may not be
multiple RFCs.  That determination will be made later based on content
scope and document size.

The discussion then moved to content.  The highest priority items
are bug fixes for NFSv4.1; these are more than just errata.
The current bug list is:

  - pNFS Access Permissions Check (has I-D)
  - LEASE_MOVED callback
  - Change attribute semantic description (I-D needed)

So, these bugs may take the form of new operations or semantic changes
that require the minor version update.  Note that NFSv4.2 will abide 
to RFC5661's Minor Version rules as defined in section 2.7.

Those in attendance discussed all of the outstanding functional
proposals -- those in the form of personal I-Ds at the time of the
meeting.  The intent of this discussion was to determine level of
proposal completeness and current energy/interest.  Of all proposals,
the following were considered to be most appropriate for NFSv4.2 at
this time.

- NFS Server-Side Copy
- Simple and efficient read support for sparse files
- NFS space reservation operations
- RPCSEC GSS v3 (needed for NFS Server-Side Copy)

The goal of identifying the list above is two-fold.  First, provide
direction to those in the working group as to where our collective
energy should be placed.  Second is to have content for the necessary
working group charter update.  As mentioned above, this is not meant
to be exclusionary.  Other work items may be included in NFSv4.2 as
well if the required level of interest and maturity are reached.

To that end, the following set of proposals had interest but level of
maturity was less than desired.  There is potential for NFSv4.2
inclusion but these will not be the initial focus items.

- NFSv4.2 Unstable File Creation
- NFSv4 pNFS Back End Protocol Extensions
- Extending NFS to Support Enterprise Applications
- Storage Control Extensions for NFSv4
- Fadvise (from original NFSv4.2 requirements -- need I-D)

Finally, the next set of proposals seem to lack both energy and maturity.

- MAC Security Label Support for NFSv4
- NFS Pathless Objects
- Storage De-Duplication awareness and sub-file caching in NFS
- Metadata striping for pNFS


Beepy and I have asked Tom Haynes to be the editor of NFSv4.2 and he
has accepted that responsibility.

Beepy and I will be working with our area directors on the required
text and charter milestone updates for the NFSv4 working group.  We
will cover the detail of the charter update during our meeting in
Prague.  The goal is to provide our area directors the insight and
detail needed to represent our work with the remainder of the IESG.

There is an item that falls outside of NFSv4.2; it is of interest to
our working group but spans multiple groups within the IETF and an
exact home is unclear.  I am referring to the NFSv4 Multi-Domain
Access drafts that Andy Adamson has been working on.  I am going to
propose that the NFSv4 WG take this on as a charter item as well and
will include the item into our charter update.


============= End of working group email ===================

----

pNFS File Servers Implementation Strategy
pNFS over IPv6
Performance Related Issues of NFSv4.1/pNFS
Secure NFS in 4.x
Multi-layout pNFS server support
FedFS implementation issues

Sorin presented a number of items that were discussed at the last
NFSv4 bakeathon.  These are in one presentation.  The one of immediate
interest was the "pNFS block signature/disk protection" portion of the
discussion.  Sorin's action was to capture the issues in an I-D such
that a guide for further discussion would be in place.

The other item of interest was the communication that SPEC is taking
on the development of a benchmark for the measurement of client and
server and this may be of interest to those in the NFSv4.1/pNFS
community.

----

End of meeting.