Re: [nfsv4] Fwd: I-D Action: draft-ietf-nfsv4-rfc5667bis-06.txt

David Noveck <davenoveck@gmail.com> Fri, 24 February 2017 22:30 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 22F5E12953F for <nfsv4@ietfa.amsl.com>; Fri, 24 Feb 2017 14:30:36 -0800 (PST)
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 skxagum3qqLJ for <nfsv4@ietfa.amsl.com>; Fri, 24 Feb 2017 14:30:33 -0800 (PST)
Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (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 447A9129534 for <nfsv4@ietf.org>; Fri, 24 Feb 2017 14:30:33 -0800 (PST)
Received: by mail-oi0-x22c.google.com with SMTP id s205so17439263oif.3 for <nfsv4@ietf.org>; Fri, 24 Feb 2017 14:30:33 -0800 (PST)
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=AbKL2fqgd50C9ljomHmN1U5UgegPrdSzWGmGF91DiIs=; b=iiAq1FTGdbgfVjzdG+nBQ8pPumSYomfujwOzVTBED5rtg7QH3ZT+pExgbZoOloEPGU DeJW+a2nzAmKpIOgrwZUJj158ThOu0JieP9H5qy7IRJr6J38J/dtbLjmdEIo/kQU/D5n yFq7QgSF22SQHBT1ZgqTGjEHoT66vODWQUyU6tUKmpYwpHz1q13xH7SMMorki4U85Zwd 1g8iLKkFULfWOHEiK5URhV0NNAhNAj44l7QYfrv3zxL9rquvH4w7g06rxtuWnh8uFY3A 8JpFoQ7CoC072ch5AB2CrBB/IXCtx+0Xu+PRi62uZhKmy4NzuYMWJZV1uLK/KtKHOr1h geUg==
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=AbKL2fqgd50C9ljomHmN1U5UgegPrdSzWGmGF91DiIs=; b=qLEeXXgsz5nAgOiMpz0zcqZ8tEuCBbbHdT0hkRPC8MsJ35rBfMzpuNUxYzi+W/obzT Fg6cCoCQ3348u1mCcZ2+hbs2SvYoJdAjsS/7VUfuJZLmS82orOpCITIl6Z8fDFb2MinD PQL/Gf/DqKILSI8tW1hRU4+ANmO/C1dSvm88ZB0CvBUoIyBk2sxNNgEDYX0CoIjCyFaH j8OyScEob/pt1w7vt7FCL3H+vVE6ACTnllfJ0GaflxoeWAgfxSlVCNUUfzIgM0UugcN/ np9rvvAXtg1Whk5KVaNaghGiePspvX4rmQTgWWF2x4jBO+AofUcHkbwNH1t1HeuF7xmH bNgA==
X-Gm-Message-State: AMke39lWZ/ej/wAAbDcr7Zyx+JQafae9wWO9RJrRJDQIoN40g9ughFUJya6lB/5jAquIqx78ktJZjsIc9lLfVA==
X-Received: by 10.202.169.80 with SMTP id s77mr2611607oie.165.1487975432433; Fri, 24 Feb 2017 14:30:32 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.137.200 with HTTP; Fri, 24 Feb 2017 14:30:32 -0800 (PST)
In-Reply-To: <AFA0676A-8E7F-41E3-A86F-94A12B3FFC27@oracle.com>
References: <148795501607.13909.7567389046439387731.idtracker@ietfa.amsl.com> <AFA0676A-8E7F-41E3-A86F-94A12B3FFC27@oracle.com>
From: David Noveck <davenoveck@gmail.com>
Date: Fri, 24 Feb 2017 17:30:32 -0500
Message-ID: <CADaq8jexw+XtVY9ibzD7c1CXrhBp=_6E5ss4nNcvwkRGoC-Epg@mail.gmail.com>
To: Chuck Lever <chuck.lever@oracle.com>
Content-Type: multipart/alternative; boundary="001a113cd7da15ba1005494e47e0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/De-NfbFKCna2oaZLGpDAF7LYg6M>
Cc: NFSv4 <nfsv4@ietf.org>
Subject: Re: [nfsv4] Fwd: I-D Action: draft-ietf-nfsv4-rfc5667bis-06.txt
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.17
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: Fri, 24 Feb 2017 22:30:36 -0000

Let's start with the most controversial area and try to put that aside for
the moment.  Chuck and I continue to have different opinions about the
appropriate way for ULBs (all of which that exist are in the current
document) to deal with the fact that, NFS-over-RDMA is no longer solely
represented by Version One.  Chuck and I have had extensive discussions and
decided that we could not resolve this in a reasonable time.   As a result,
I accepted Chuck's decision to proceed with rfc5667bis on a
Version-One-only basis and agreed to review -06 on that basis.

Others in the working group are free to take a different view but I feel
that it would not be helpful to delay rfc5667bis because of this issue.
The working group reached consensus on the original versions these
documents about a decade ago and only now are we reaching an equivalent
state with the revived documents.  Further transport versions are needed to
get us to the protocol we want, but the working group has put a priority on
reviving Version One and I would urge people not to add unnecessarily to
the delay in getting that part of our work done.

Later, I will be submitting a draft-dnoveck-nfsv4-nfsulb that illustrates
how a more transport-generic NFS ULB might be written.  Chuck and I have
repeatedly disagreed about how difficult (or even possible) it was to do
this.  It is hard to discuss this sort of issue in the abstract.  However,
once we have a document to look at and review, the working group can see
for itself whether this is a viable approach and decide if it might be more
appropriate in the long term, as the transport is extended.  This document
is based on rfc5667bis so that Chuck would normally be listed as a
co-author, but Chuck has decided against that.  I hope he will reconsider.









On Fri, Feb 24, 2017 at 12:00 PM, Chuck Lever <chuck.lever@oracle.com>
wrote:

>
>
> > Begin forwarded message:
> >
> > From: internet-drafts@ietf.org
> > Subject: [nfsv4] I-D Action: draft-ietf-nfsv4-rfc5667bis-06.txt
> > Date: February 24, 2017 at 8:50:16 AM PST
> > To: <i-d-announce@ietf.org>
> > Cc: nfsv4@ietf.org
> >
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> > This draft is a work item of the Network File System Version 4 of the
> IETF.
> >
> >        Title           : Network File System (NFS) Upper Layer Binding
> To RPC-Over-RDMA Version One
> >        Author          : Charles Lever
> >       Filename        : draft-ietf-nfsv4-rfc5667bis-06.txt
> >       Pages           : 19
> >       Date            : 2017-02-24
> >
> > Abstract:
> >   This document specifies Upper Layer Bindings of Network File System
> >   (NFS) protocol versions to RPC-over-RDMA Version One.  Upper Layer
> >   Bindings are required in order to enable RPC-based protocols such as
> >   NFS to use Direct Data Placement on RPC-over-RDMA Version One.  This
> >   document obsoletes RFC 5667.
> >
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-nfsv4-rfc5667bis/
> >
> > There's also a htmlized version available at:
> > https://tools.ietf.org/html/draft-ietf-nfsv4-rfc5667bis-06
> >
> > A diff from the previous version is available at:
> > https://www.ietf.org/rfcdiff?url2=draft-ietf-nfsv4-rfc5667bis-06
> >
> >
> > Please note that it may take a couple of minutes from the time of
> submission
> > until the htmlized version and diff are available at tools.ietf.org.
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > _______________________________________________
> > nfsv4 mailing list
> > nfsv4@ietf.org
> > https://www.ietf.org/mailman/listinfo/nfsv4
>
>
> Changes since -05:
>
> Dave Noveck observed that my stated goal was "some
> degree of transport version agnosticism" but there
> is still inconsistent language throughout the document.
> I've been struggling with how to discuss certain
> mechanisms, such as short Reply chunk retry, without
> the mention of version-specific transport protocol
> elements.
>
> Thus I've decided to reverse course and explicitly
> state this document applies to RPC-over-RDMA Version
> One, though not explicitly exclude the use of the ULB
> by future versions or extensions.
>
>   o A ULB sometimes has to discuss in detail how a ULP
>     might use a transport. For example, it might need
>     to refer to a specific error code or transport
>     mechanism that is available only in some particular
>     transport versions. That's challenging to do when
>     using only abstract terms.
>
>   o It is not possible to predict how future transports
>     might innovate. Specificity in the text of a ULB can
>     make it difficult to apply easily to later versions
>     of a transport, or its extensions.
>        + For instance, there are a couple places (like
>          dealing with READ_PLUS replies, or how to handle
>          multiple Write chunks) where there is a very
>          transport-specific mechanism described. We could
>          have some innovation in the future to help deal
>          with these situations.
>
>    o The change in direction resolves some subtle issues
>      about how cross-citation will work when defining a
>      transport version or extension and possibly a ULB to
>      go with it. It appears more straightforward to me to
>      provide a basic ULB that future transport and
>      extensions can point to and say either:
>        + That ULB rule can be re-used, or
>        + That ULB rule can be re-used with these changes
>          or exceptions, or
>        + This is the new ULB rule that must be used for
>          this new mechanism
>
> This might be a controversial change, but I feel the
> document is more clear now while still enabling its use
> for future transports and their extensions.
>
> Karen Deitke had questions about whether chunk reduction
> can be used with Long messages. The recent removal of "MUST
> ignore subsequent chunks" seems to have opened a little
> gap. I've added some language which I hope closes that gap.
>
> While working with IANA on rfc5666bis, Tom Talpey noticed
> that the official IANA registration of the nfsrdma ports
> references RFC 5666, but should reference the NFS ULB. RFC
> 5667 doesn't have an IANA Considerations section, and the
> mention of nfsrdma in RFC 5666 is as an example. Thus the
> IANA registry citation needs to be corrected, and one of
> these documents needs to have an official specification
> of nfsrdma. To make the IANA registry and the updated
> documents consistent, I've updated the IANA Considerations
> sections in both rfc5666bis and rfc5667bis.
>
> Karen and Dave both suggested a reorganization of the
> discussion of short Reply chunk retry.
>
> A very recent discussion on linux-nfs@vger.kernel.org
> brought up the question of whether the language of RFC
> 5661 Section 2.9.1 forecloses on the use of RPC-over-RDMA
> with NFS version 4, because of version 4's tighter
> requirements for transport-level congestion avoidance.
> Of special concern was RoCEv2, which is implemented over
> UDP on IP. A section has been introduced to discuss this,
> and summarize the Working Group's (hopefully) approval of
> the use of RPC-over-RDMA for NFS version 4 deployments.
>
>
> --
> Chuck Lever
>
>
>
> _______________________________________________
> nfsv4 mailing list
> nfsv4@ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4
>