Re: [nfsv4] Benjamin Kaduk's Discuss on draft-ietf-nfsv4-rfc5661sesqui-msns-03: (with DISCUSS and COMMENT)

Benjamin Kaduk <kaduk@mit.edu> Mon, 13 January 2020 23:00 UTC

Return-Path: <kaduk@mit.edu>
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 619C512004C; Mon, 13 Jan 2020 15:00:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 Qpi1Se7JDiLM; Mon, 13 Jan 2020 14:59:59 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E20612001B; Mon, 13 Jan 2020 14:59:57 -0800 (PST)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 00DMxoV5011517 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 13 Jan 2020 17:59:52 -0500
Date: Mon, 13 Jan 2020 14:59:50 -0800
From: Benjamin Kaduk <kaduk@mit.edu>
To: David Noveck <davenoveck@gmail.com>
Cc: draft-ietf-nfsv4-rfc5661sesqui-msns@ietf.org, Magnus Westerlund <magnus.westerlund@ericsson.com>, The IESG <iesg@ietf.org>, NFSv4 <nfsv4@ietf.org>, "nfsv4-chairs@ietf.org" <nfsv4-chairs@ietf.org>
Message-ID: <20200113225950.GJ66991@kduck.mit.edu>
References: <157665795217.30033.16985899397047966102.idtracker@ietfa.amsl.com> <CADaq8jegizL79V4yJf8=itMVUYDuHf=-pZgZEh-yqdT30ZdJ5w@mail.gmail.com> <CADaq8jcURAKZsNvs17MhNFT7eBNtkvOdrur5hHY2J1gXH7QdsA@mail.gmail.com> <20200113225411.GI66991@kduck.mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200113225411.GI66991@kduck.mit.edu>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/8IMbax4QrCbEn9f_9dp9hTOM_Q8>
Subject: Re: [nfsv4] Benjamin Kaduk's Discuss on draft-ietf-nfsv4-rfc5661sesqui-msns-03: (with DISCUSS and COMMENT)
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.29
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: Mon, 13 Jan 2020 23:00:04 -0000

Replying to myself: I wrote this in multiple sittings and somehow thought
the point I wanted to revise was in the other fork of the thread.

On Mon, Jan 13, 2020 at 02:54:11PM -0800, Benjamin Kaduk wrote:
> Hi David,
> 
> Trimming lots of good stuff here as well...
> 
> On Thu, Jan 02, 2020 at 10:09:02AM -0500, David Noveck wrote:
> > On Wed, Dec 18, 2019 at 3:32 AM Benjamin Kaduk via Datatracker <
> > noreply@ietf.org> wrote:
> > 
> > > Benjamin Kaduk has entered the following ballot position for
> > > draft-ietf-nfsv4-rfc5661sesqui-msns-03: Discuss
> 
> > >
> > > I note inline (in what is probably too many places; please don't reply
> > > at all of them!) some question about how clear the text is that a file
> > > system migration is something done at a per-file-system granularity, and
> > > that migrating a client at a time is not possible.
> > 
> > 
> > It might be possible but doing so is not a goal of this specfication.
> > 
> > I'm not sure how to address your concern.   I don't know why anyone would
> > assume that migrating entire clients is a goal of this specification.   As
> > far as
> > I can see, when the word "migration" is used it is always in connection with
> > migrating a file system.   Is there some specific place where you think
> > this
> > issue is likely to arise?
> 
> I think I garbled my point; my apologies.
> To give a semi-concrete example, suppose I have clients A and B that are
> accessing filesystem F on server X, and filesystem F is also available on
> server Y.  If X decides that it needs to migrate access to F away from X
> (e.g., for maintenance), then the "file system migration event" involves
> telling both A and B to look to Y for access to F, at basically the same
> time.  If X tries to tell only A but not B to access F via Y but lets B
> continue to access F at X, then I think there can be some subtle
> consistency issues.
> 
> In some sense, this is easy to consider as a dichotomy between "migration
> is for server maintenance" vs. "migration is for load balancing".  Assuming
> I understand correctly (not a trivial assumption!), there was never any
> intent to use these mechanisms for load balancing, and if we can explicitly
> disclaim such usage, then we don't have to try to reason through any
> potential subtle consistency issues.

Some of your later replies in the "comment-section" thread make me think
that my understanding, quoted above, is incorrect.  That is, that it's okay
for X to tell A to migrate to Y for filesystem F while X continues to serve
F to B.  In particular, the updated text about server reclaim behavior (and
knowing what specific clientids might be reclaiming) seems to address the
main "subtle consistency issues" that I can think of right now.

Sorry about that.

-Ben