Re: [nfsv4] New draft for working group charter

David Noveck <davenoveck@gmail.com> Thu, 11 May 2017 19:02 UTC

Return-Path: <davenoveck@gmail.com>
X-Original-To: nfsv4@ietfa.amsl.com
Delivered-To: nfsv4@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4928B1300EF; Thu, 11 May 2017 12:02:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BCmNaYx_xLXN; Thu, 11 May 2017 12:02:56 -0700 (PDT)
Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E9DE13145C; Thu, 11 May 2017 11:56:48 -0700 (PDT)
Received: by mail-io0-x231.google.com with SMTP id f102so27364144ioi.2; Thu, 11 May 2017 11:56:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mnrEey6bjUAjs9glQqt5uhcxzSf0j0+eWa6gWIbyrZ8=; b=ofzg3/UOu/MRAtsUfKCq1BWFuHCRNPIC9CKv+VjNz7jvO2CUMCR4BQrOiT+Ejt+DJD 7kmYJzLOgi09IE1vyN6XXhmz1aDwbDPtuLBGDcQtKOkFUKP3scxv4hXYbs3eWhd2ESqr lIMJaiBBYqQpPW1NwZJnLBhumkc6BbuOaTFphXmoD3DZdeCCJtDZuHU1RxKxk4HyXZmR PMvP3qpCJdDmV69VQl37Jzu0sPC0A0szxGCBaRWwpSzOgeLvl1XZK7xs66tVTnxKLBhr DQA5PWZ9oq8NM2fbzhfg94AxWPfbTVqFrTemSjGS8B5Yc3rVMBtgaE4CTbjNtAQjCL2t 4tLg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=mnrEey6bjUAjs9glQqt5uhcxzSf0j0+eWa6gWIbyrZ8=; b=OQa+uVBuYxq2jtCXin7+kLoIvlUgSkAFAr5ivUShQBNAlQbachbXohaUM2oBQSJAb4 5x7ePjejeMcqxZQ9yAfpKDvLO5i95BwE2nCDsIjPmuub9HChIXJ9lZQR4PFU/QMRGKzv Nj+FueRRrS3gewjDZVo/9pkJ645FTH6R5yzd7isNUOuuLInESgzKEd8YyaD4DlsIoANQ CShT2iLrYAlg4jqRE+dq51DzIIxeoGXC6j1uy62Sq3oJeS/WLW+C1x3o615+uoblzdH6 zc8KBkZ87K4qvzb+gSxI7dNATszCNWLEJWdYl+WtoIiIA3ZqCpxBkxm0h40tfRnRARvm kouA==
X-Gm-Message-State: AODbwcDI1ntCIcp1x+lZUyv3YztVfFM1EZiiSvlJP0BlaULsHvfoP0yZ cQh6BR2GRHs1Rtda+ZCSs584t+6Gpg==
X-Received: by 10.107.3.165 with SMTP id e37mr7632ioi.232.1494529007690; Thu, 11 May 2017 11:56:47 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.20.75 with HTTP; Thu, 11 May 2017 11:56:47 -0700 (PDT)
In-Reply-To: <237296BF-A24B-4AA6-A0B0-0E9F5B9F638C@oracle.com>
References: <CADaq8jfiL4F4OmSMXOQRv-MYuQPFWc1Yo_U=KVphmr2KYc3mjw@mail.gmail.com> <237296BF-A24B-4AA6-A0B0-0E9F5B9F638C@oracle.com>
From: David Noveck <davenoveck@gmail.com>
Date: Thu, 11 May 2017 14:56:47 -0400
Message-ID: <CADaq8jeg-EMPPu9dK3SzrOPqAD58i2tVFxkC9e=H+BEXR9LfkA@mail.gmail.com>
To: Chuck Lever <chuck.lever@oracle.com>
Cc: "nfsv4@ietf.org" <nfsv4@ietf.org>, "nfsv4-chairs@ietf.org" <nfsv4-chairs@ietf.org>, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Content-Type: multipart/alternative; boundary="001a113ed3be9c3e15054f4426e9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/tk_yOysIDOr5bfBkXG5a_lEJZrc>
Subject: Re: [nfsv4] New draft for working group charter
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nfsv4/>
List-Post: <mailto:nfsv4@ietf.org>
List-Help: <mailto:nfsv4-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 May 2017 19:02:59 -0000

> Specific milestones should include:

I want to explain that my list could not include a lot of things you
mention because I felt it best to limit it to WG items.  If there are
documents that become working group items between now and when the charter
is submitted, then they should included.  I'm not sure we would be able to
include things that aren't working group items at charter submission,
although i believe that we would be able to take advantage of the provision
that Spencer S. suggested to allow later addition of milestones :-)

-  Trunking (multi-pathing)

This has no current WG item.   I expect there would be some discussion of
 possible paths forward in this area once migration-issues-13 is
published.  I'm going to be talking about this area at IETF99 and hope that
Andy will be able to as well.   I'm hoping that soon after IETF99 we will
able to add one or more milestones here.

 - NVMe layout type
 - RDMA layout type

For these there is no current WG document or I-d.  I am looking forward to
work being done on these but don't expect these to be included in the
charter submission.

 - flexfile layout type

I did ask Tom privately about setting a target date for this since it is a
WG item.  I anticipate correcting this at IETF99 by guessing at dates until
Tom nods his head.

> These are either far along, or there are identified authors and energy and
the work is well-scoped.

True but I used having a WG document started or at least agreed upon as the
gating criterion.  I'm willing to change that if you suggest an alternative
criterion.

> Other work items are less mature.

I don't agree. Specifically, I feel the following I-d's should be
considered for WG status and that could well happen  before, at, or soon
after IETF-99:

   - draft-cel-nfsv4-rpcrdma-version-two
   - draft-cel-nfsv4-rpcrdma-cm-pvt-msg

If that happens, we could add one or more milestones for those.

> I don't think the focus of this section should be strictly on RDMA.

It isn't.

We've introduced performance features in other areas of the stack besides
pNFS and RDMA.

True.

> For example, READ_PLUS, S2SC, and ALLOCATE are intended to
> help performance. One of the performance issues we chronically face is
t> hat NFS itself is still chatty (eg. Tom's suggestion about reducing the
> round-trip overhead of OPEN with delegation).

I felt that these changes were dealt with adequately in the Extension
section.  I guess I
could rename "Performance Challenges" to be "Major Performance Challenges".
If this section were to include any performance-related improvements, I
feel it
would lose necessary focus

> There is no mention of making NFS into a premier storage technology for
> supporting virtualization.

No there isn't.  Is there some addition to the charter draft you would like
to suggest?

I certainly approve of the goal.  I just don't think it is charter-ready
yet, but will
look carefully at any suggested text you provide.  We need to explain the
need/justification for this clearly to Beepy and the Spencers.

> RDMA helps there, as do the new features in NFSv4.2.

> New security models are needed to properly handle multi-tenancy,
> for example. But we've moved ahead in this area for years (NFSv4.2)
> without mention in the WG charter.

NFSv4.2 is mentioned in the existing charter.  It is not in my charter
draft,
because that work is done, except for post-RFC7862 extensions to v4.2.


On Thu, May 11, 2017 at 12:58 PM, Chuck Lever <chuck.lever@oracle.com>
wrote:

>
> > On May 11, 2017, at 7:56 AM, David Noveck <davenoveck@gmail.com> wrote:
> >
> > The following is the second iteration of my attempt to provide a draft
> charter to be "whacked" (as Beepy put it) on the working group list so all
> comments are appreciated.  However, if someone would like to present an
> alternate draft, that's OK too.  We do need some sort of draft to work from
> for a discussion in Prague.  Without it, a discussion in Prague is not
> going to arrive at a useful charter candidate.
> >
> > This has the following changes from the initial draft.  If you object to
> any of these changes, let me know right away:
> >       • Deletion of References to FedFS, per Chuck's comments.
> >       • Inclusion of other ONC components in the Maintenance section,
> per Chuck's comments.
> >       • Deletion of the out-of-date sections RFC5664bis and NFSv4.2.
> >       • Deletion (for now) of the section NFSv4 Multi-Domain Access for
> FedFS.  Unlike the previously mentioned sections, this could come back,
> probably in the form NFSv4 Multi-Domain Access if someone (e.g. Andy)
> provides a draft charter section.
> >       • Added a reference within the Maintenance section, to the ability
> of technical updates to NFSv4 versions to include limited XDR changes.
> >       • A start at a draft Milestones section (see below).  This is very
> limited since most WG documents are past WGLC right now.  I've made some
> reasonable assumptions regarding migration-issues.  When -13 is published,
> the way forward in this area will clearer and the list could be updated to
> include some expected documents to address the issues described in the
> Informational document.  BTW, I'm assuming there will be a need for WGLC
> for that document as a means of establishing consensus on a way forward for
> those issues even though I believe there is no point in publishing that
> document as an RFC.
> >       • In order to help deal with our  limited set of current
> milestones, I've followed Spencer's suggestion and adapted the material he
> cited from the TCPM charter.
> > Draft Charter for Working Group (Iteration Two)
> > NFS Version 4 is the IETF standard for file sharing. To maintain NFS
> Version 4's utility and currency, the working group is chartered to
> maintain the existing NFSv4.0, NFSv4.1, NFSv4.2, protocols and related
> specifications of ONC components such as those defining RPC, XDR, and
> RPCSECGSS. In addition, extensions will be developed, as necessary, to
> correct problems with the protocols as currently specified, to accommodate
> needed file system semantics, and to make significant performance
> improvements.
> >
> > Maintenance
> >
> > The working group has found that as NFSv4 implementations mature and
> deployments continue, clarifications to existing RFCs are needed. These
> clarifications assist vendors in delivering quality and interoperable
> implementations. The working group is chartered with the vetting of the
> issues and determining correctness of submitted errata. In addition, some
> areas may need more concentrated work to correct the specifications already
> published or to deal with unanticipated interactions between features. In
> the cases in which the required changes are inappropriate for the errata
> system, the working group will assist in publication of best practices RFCs
> or of RFCs that provide editorial modification or technical updates to
> original RFCs.  Once, the new NFSv4 versioning framework is approved, such
> technical updates to NFSv4 versions could include limited XDR changes.
> >
> > Extension
> >
> > The NFSv4 protocol is designed to allow extension by the addition of new
> operations or new attributes, the creation of minor versions, and the
> definition of new pNFS mapping types.  The working group will discuss
> proposals for such extensions and assure they have adequate technical
> review including discussion of their interaction with existing features
> before adopting them as working group items and helping to draft
> specification documents. Siniilarly, associated ONC protocol components
> that have a versioning/extension  framework can be suitably extended to
> accommodate new security requirements, and to make significant performance
> improvements.
> >
> > Performance Challenges
>
> Opportunities? Just a thought.
>
>
> > The increase of network bandwidths and the reduction of latencies
> associated with network traffic and access to persistent storage have
> created challenges for remote file access protocols which need to meet
> increasingly demanding performance expectations.  Some work already done in
> this area includes the respecification of RPC-over-RDMA Version One and the
> pNFS SCSI layout.  It is lexpected that further work in this area will be
> required.  This might take the form of further RPC-over-RDMA versions,
> adaptation of the SCSI layout to NVMe, or the development of an
> RDMA-oriented pNFS layout type.  The working group needs to discuss these
> alternatives, and possibly others, and develop the most promising ones.
>
> Specific milestones should include:
>
>  - Trunking (multi-pathing)
>  - NVMe layout type
>  - RDMA layout type
>  - flexfile layout type
>
> These are either far along, or there are identified authors and energy
> and the work is well-scoped. Other work items are less mature.
>
> I don't think the focus of this section should be strictly on RDMA.
> We've introduced performance features in other areas of the stack besides
> pNFS and RDMA. For example, READ_PLUS, S2SC, and ALLOCATE are intended to
> help performance. One of the performance issues we chronically face is
> that NFS itself is still chatty (eg. Tom's suggestion about reducing the
> round-trip overhead of OPEN with delegation).
>
> There is no mention of making NFS into a premier storage technology for
> supporting virtualization. RDMA helps there, as do the new features in
> NFSv4.2. New security models are needed to properly handle multi-tenancy,
> for example. But we've moved ahead in this area for years (NFSv4.2)
> without mention in the WG charter.
>
>
> > Milestones (Preliminary draft)
> >
> > Because the previous charter was at variance with the work the group was
> actually doing, the list of pending milestones that can determined now is
> quite limited.  To accommodate this situation and in light of the fact that
> maintenance activities are inherently unpredictable, new milestones that
> fall within the scope specified within the charter can be added after
> working group consensus on acceptance and approval by the responsible Area
> Director.
> >
> > Date               Milestone
> >
> > Nov. 2017      Publication of RFC5666bis as a Proposed Standard
> >
> > Nov. 2017      Publication of a Proposed Standard describing
> bidirectional operation for RPC-over-RDMA
> >
> > Jan. 2018       Publication of RFC5667bis as a Proposed Standard.
> >
> > Feb. 2018       Publication of a Proposed Standard describing NFSv4
> versioning/extension framework.
> >
> > Feb. 2018       Publication of a Proposed Standard describing the umask
> extension to NFSv4.2.
> >
> > Feb. 2018       Publication of a Proposed Standard describing the xattr
> extension to NFSv4.2.
> >
> > March 2018    WGLC for draft-ietf-nfsv4-migration-issues (Informational)
> >
> >
> >
> > _______________________________________________
> > nfsv4 mailing list
> > nfsv4@ietf.org
> > https://www.ietf.org/mailman/listinfo/nfsv4
>
> --
> Chuck Lever
>
>
>
>