Re: [nfsv4] 4.0 trunking

David Noveck <davenoveck@gmail.com> Thu, 08 September 2016 00:15 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 23BD112B0D7 for <nfsv4@ietfa.amsl.com>; Wed, 7 Sep 2016 17:15:01 -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 yKEAdCg6Rbrn for <nfsv4@ietfa.amsl.com>; Wed, 7 Sep 2016 17:14:59 -0700 (PDT)
Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (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 71D8C12B0A7 for <nfsv4@ietf.org>; Wed, 7 Sep 2016 17:14:59 -0700 (PDT)
Received: by mail-oi0-x229.google.com with SMTP id m11so49440415oif.1 for <nfsv4@ietf.org>; Wed, 07 Sep 2016 17:14:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Wun44736PdyYBqiyFxEWT0KpIwh/+4AiNJcOan8ROvg=; b=Hnu3fLgTdUpZJPnBz6+SJd4xdg6rQPTb1CwBPLP0xeM3orbt+r927rn6MnUQgTzGsY puYaiySzWdAQVv0YQPkm2AkNty+uZSlevAcjbN5neuECcKO+dsS1T/BUEFjjib+8skT1 NaiBQMmEm/y1cIlLLFiZnsMCAgM2YjQnmUG+e3chh/qqlISi8b2ii6rrRi78PXrX3S4p I42drLfo0vTpHryEibZahjsT/fdkpMKfyrD+BdoaICWcaSWHgtKb0Fg9BGE/LAi4BWh9 sy+vy5/1se9g8ZFuQC8kEuyQpM7ff/gY8t+6v5K9uM6n+gaY7CUxUoLxONQx96aJ+Mhs 76tg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Wun44736PdyYBqiyFxEWT0KpIwh/+4AiNJcOan8ROvg=; b=YxbepXm8C6G324Q170ATGfUBLGAwHpXDX4Z1JjejV5Tq7arWJnOb3dSpKbWRXszMPi YavHaNyC04Ax++EKTsD2Van02/svLmX3I4A25YJx+mg0V1L/f2W/Qzt6qh5QlkYq2cCl 5gZcUrbY8RuQFWVime6q47ccNxS4z3Rq5CWp2nTYk22fGsfLIEhB0lLTDop3JV31MIIO 6vWV1Owdt+gqaPpIi5uL0NUwpkfO2nXEFtO3i+rKoWP6KBhFewIugXU0XoYoia13db+F rkYr1TSW0jpCMfW9ZP92+7ScdYODuy2i8HL0+NC+7cv4WMyN1PlvLFDcGqeyN+hpB433 WR9g==
X-Gm-Message-State: AE9vXwN+f8A3xmxKsLR1xJxr1PnGKiFi1m6Gsk2kLQU6Bw0wRqVAc2eyFbK6Xe0hv88ruoC6ekxWANU+nlZAqg==
X-Received: by 10.157.27.234 with SMTP id v39mr11605825otv.4.1473293698737; Wed, 07 Sep 2016 17:14:58 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.192.10 with HTTP; Wed, 7 Sep 2016 17:14:58 -0700 (PDT)
In-Reply-To: <20160907212039.GA6847@fieldses.org>
References: <20160907212039.GA6847@fieldses.org>
From: David Noveck <davenoveck@gmail.com>
Date: Wed, 07 Sep 2016 20:14:58 -0400
Message-ID: <CADaq8jfiRU7DTRYXGHZvMALAZWeRjhqcpo8Si3_diMt_5dNSMw@mail.gmail.com>
To: "J. Bruce Fields" <bfields@fieldses.org>
Content-Type: multipart/alternative; boundary="001a1141921a902ade053bf3eb47"
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/2JruswE-2s89YPcV1yDCDp29O-w>
Cc: "nfsv4@ietf.org" <nfsv4@ietf.org>
Subject: Re: [nfsv4] 4.0 trunking
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: Thu, 08 Sep 2016 00:15:01 -0000

> But I can't find any further discussion of how a client might make that
> determination.  Am I overlooking it?

It's actually in section 5.8 of RFC7931.

I've only been keeping draft-ietf-nfsv4-migration-issues alive because of
the section dealing with issues relating to v4.1.  Otherwise, I would have
let the thing expire.  The next time I update this, I'll probably collapse
sections 4 and 5 to a short section saying that all the
v4.0 issues were addressed by publication of RFC7931.

> (It appears that the Linux client is trying to do that by sending
> a setclientid_confirm to server1 using the (clientid,verifier)
> returned from a setclientid reply from server2.  That doesn't look
> correct to me.)

It seems kind of weird but the idea is that if you get the same clientid
from two server IP address they are probably connected to the same server
(i.e are trunked), but there is a chance that having the same clientid is a
coincidence,  The idea is that if these are the same server using the
verifier will work but if they are different servers it won't work but will
be harmless.


On Wed, Sep 7, 2016 at 5:20 PM, J. Bruce Fields <bfields@fieldses.org>
wrote:

> In
> https://tools.ietf.org/html/draft-ietf-nfsv4-migration-
> issues-10#section-5.4.2
>
>         In the face of possible trunking of server IP addresses, the
>         client will use the receipt of the same clientid4 from multiple
>         IP-addresses, as an indication that the two IP- addresses may be
>         trunked and proceed to determine, from the observed server
>         behavior whether the two addresses are in fact trunked.
>
> But I can't find any further discussion of how a client might make that
> determination.  Am I overlooking it?
>
> (It appears that the Linux client is trying to do that by sending a
> setclientid_confirm to server1 using the (clientid,verifier) returned
> from a setclientid reply from server2.  That doesn't look correct to
> me.)
>
> --b.
>