Re: [Gen-art] [nfsv4] Genart last call review of draft-ietf-nfsv4-flex-files-15

Thomas Haynes <loghyr@primarydata.com> Fri, 22 December 2017 23:02 UTC

Return-Path: <loghyr@primarydata.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DE66126D05 for <gen-art@ietfa.amsl.com>; Fri, 22 Dec 2017 15:02:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=primarydata.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 SoiLhhA6N70n for <gen-art@ietfa.amsl.com>; Fri, 22 Dec 2017 15:02:10 -0800 (PST)
Received: from us-smtp-delivery-194.mimecast.com (us-smtp-delivery-194.mimecast.com [216.205.24.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3EF3126D0C for <gen-art@ietf.org>; Fri, 22 Dec 2017 15:02:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=primarydata.com; s=mimecast20170802; t=1513983729; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references; bh=3x4O+RsF1+VDn0885RVU4GwMEWXywAgP08edS7ZAkqg=; b=aPCibKIBoQ78ybzeQ6Pfq1UszC6TWwIxFoyJReTI0eLY9pbwliT+9+37Blz87UjHYsmnhqyGpy8c1Mcyg89upuz3teosjRwRbNNBIrEyU+Gy1TqUOtDj7g8KkXvmzixup+a28FOfqQSSCnS5Aq7R/gywN55qRqc8Bjt7XX8tsSk=
Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01lp0182.outbound.protection.outlook.com [216.32.180.182]) (Using TLS) by us-smtp-1.mimecast.com with ESMTP id us-mta-148-eA50II4AND68bZj2MoZqNw-1; Fri, 22 Dec 2017 18:00:08 -0500
Received: from BY2PR1101MB1093.namprd11.prod.outlook.com (10.164.166.21) by BY2PR1101MB1095.namprd11.prod.outlook.com (10.164.166.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.345.14; Fri, 22 Dec 2017 23:00:05 +0000
Received: from BY2PR1101MB1093.namprd11.prod.outlook.com ([10.164.166.21]) by BY2PR1101MB1093.namprd11.prod.outlook.com ([10.164.166.21]) with mapi id 15.20.0345.013; Fri, 22 Dec 2017 23:00:05 +0000
From: Thomas Haynes <loghyr@primarydata.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>
CC: General area reviewing team <gen-art@ietf.org>, "draft-ietf-nfsv4-flex-files.all@ietf.org" <draft-ietf-nfsv4-flex-files.all@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "nfsv4@ietf.org" <nfsv4@ietf.org>
Thread-Topic: [nfsv4] Genart last call review of draft-ietf-nfsv4-flex-files-15
Thread-Index: AQHTekX7QtUlQgrsUEm9fFxB51sgcqNOl5iAgAEvTACAADXDgA==
Date: Fri, 22 Dec 2017 23:00:04 +0000
Message-ID: <AA6D36B3-FF05-44BB-8189-18542ADA9E99@primarydata.com>
References: <151385190310.12830.12244028318485947459@ietfa.amsl.com> <20EB69D5-DCDE-4E99-98AE-B84299D48964@primarydata.com> <7594FB04B1934943A5C02806D1A2204B6C0D66B5@ESESSMB109.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B6C0D66B5@ESESSMB109.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [63.157.6.18]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BY2PR1101MB1095; 20:0NTj7uN57ob3i4zdxRF87Ew+AfZM1JfwW4Au8VQ8JJbG0gDBynUSW0GpbmTE6qxk1tUWbZzjs9FUWHyVHLwNGZSadPav0caqPQxV4ZjiC4JGXOXHbvXnz7QUm7aQsdSaBSv4sU6qoVvPEdh7OnHnPwPZJd1CyvZ4SM5Mg1tTFFQ=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 0d9e917c-cb24-459a-ca31-08d5498fbda3
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4603075)(4627115)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060); SRVR:BY2PR1101MB1095;
x-ms-traffictypediagnostic: BY2PR1101MB1095:
x-microsoft-antispam-prvs: <BY2PR1101MB10954946E92C9327848C6BE4CE020@BY2PR1101MB1095.namprd11.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(37575265505322)(158342451672863);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(3231023)(944501049)(10201501046)(6041268)(20161123564045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(2016111802025)(20161123560045)(20161123562045)(6072148)(6043046)(201708071742011); SRVR:BY2PR1101MB1095; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:BY2PR1101MB1095;
x-forefront-prvs: 05299D545B
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39830400003)(396003)(39380400002)(376002)(366004)(346002)(199004)(189003)(38564003)(24454002)(33656002)(6246003)(36756003)(53936002)(305945005)(3846002)(478600001)(6116002)(8676002)(14454004)(7736002)(4326008)(81156014)(25786009)(229853002)(2906002)(81166006)(106356001)(102836004)(8936002)(6512007)(105586002)(5660300001)(77096006)(6486002)(97736004)(6916009)(3660700001)(6506007)(6436002)(86362001)(76176011)(54906003)(53546011)(2900100001)(59450400001)(66066001)(68736007)(99286004)(82746002)(3280700002)(230783001)(316002)(2950100002)(83716003)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR1101MB1095; H:BY2PR1101MB1093.namprd11.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
x-microsoft-antispam-message-info: eQhQmeJBYQZpf65kCqeklUd9A7Lxn43fFmjiGdQ+Jl6YAui80RwzWG4h0/35KFICNe3h4yqqO3bfZfCKwR9qWA==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-ID: <7F4DBAB81A934646AE36E36A815BFB63@namprd11.prod.outlook.com>
MIME-Version: 1.0
X-OriginatorOrg: primarydata.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 0d9e917c-cb24-459a-ca31-08d5498fbda3
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Dec 2017 23:00:04.9353 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 03193ed6-8726-4bb3-a832-18ab0d28adb7
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR1101MB1095
X-MC-Unique: eA50II4AND68bZj2MoZqNw-1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: base64
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/OtlaamMAS5PZcKxD-i5i-wvAo_8>
Subject: Re: [Gen-art] [nfsv4] Genart last call review of draft-ietf-nfsv4-flex-files-15
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Dec 2017 23:02:11 -0000


> On Dec 22, 2017, at 11:47 AM, Christer Holmberg <christer.holmberg@ericsson.com>; wrote:
> 
> Hi Thomas,
> 
> ...
> 
>>> Q1:
>>> 
>>> The Abstract says:
>>> 
>>>  "The flexible file layout type is defined in this
>>>  document as an extension to pNFS which allows the use of storage
>>>  devices in a fashion such that they require only a quite limited
>>>  degree of interaction with the metadata server, using already
>>>  existing protocols."
>>> 
>>> …and the Introduction says:
>>> 
>>>  "There are different layout types for different storage
>>>  systems and methods of arranging data on storage devices.  This
>>>  document defines the flexible file layout type used with file-based
>>>  data servers that are accessed using the Network File System (NFS)
>>>  protocols: NFSv3 [RFC1813], NFSv4.0 [RFC7530], NFSv4.1 [RFC5661], and
>>>  NFSv4.2 [RFC7862].”
>>> 
>>> But, there is no text about the existing file layout type, and how 
>>> this file layout types will improve things.
>> 
>> It does not have to improve things, it is just a different layout type.
> 
> But, shouldn't there be any description about the difference between the existing file layout type? Is there some specific scenario in mind? Is there some characteristic(s) specific to the flexible file layout type?
> 
> I assume there was *SOME* reason for defining the flexible file layout type - other than just defining a new layout type for the sake of it :)


The old type did not allow you to use NFSv3 to access the storage devices.

Which is covered here:

   This
   document defines the flexible file layout type used with file-based
   data servers that are accessed using the Network File System (NFS)
   protocols: NFSv3 [RFC1813], NFSv4.0 [RFC7530], NFSv4.1 [RFC5661], and
   NFSv4.2 [RFC7862].

DISCLAIMER: I am too close to this document and after RFC 7530 and RFC 7862, I tend to be terse.

In general, a new layout type is created to access the storage devices via a
different protocol than provided by existing layout types. See RFC 8154 and
draft-hellwig-nfsv4-rdma-layout-00.

I’ll add some text to make apparent the desire is to access non-NFSv4 storage devices.





> 
>>> The Abstract mentions impacts on the interactions with the metadata server, but there is no text about that 
>>> in the Introduction.
>> 
>> There is, but perhaps the relationship needs to be explained.
>> 
>> The entire second paragraph is about the interactions with the metadata server.
> 
> If that is specific to the flexible file layout type, I think it should be explicitly stated.
> 
>>> I think a few sentences in the Introduction, describing the high-level 
>>> advantages and changes that the flexible file layout type brings, 
>>> would be good.
>>> 
>>> Also, the Abstract mentions client mirroring, but there is nothing 
>>> about that in the Introduction.
>>> 
>> 
>> Both of these were on purpose - I wanted to introduce the terms in Section 1.1 before using them.
> 
> That is fine.
> 
>> I’ll add the high-level summary, including client side mirroring.
> 
> Thanks!
> 
> 
>>> Q2:
>>> 
>>> Is section 2 specific to the flexible file layout type, or is it about 
>>> pNFS in general? I think it would good to have a sentence describing 
>>> the scope of the section.
>> 
>> It starts out general for all pNFS and covered more specifically in [pNFSLayouts].
>> 
>> And having said that, I disagree with it immediately.
> 
> Disagree with what? My suggestion to have a sentence describing the scope?

No, hah! My statement of "It starts out general for all pNFS and covered more specifically in [pNFSLayouts].”



> 
>> I can point the reader to [pNFSLayouts] and paint the scope as to how FlexFiles will address this issue.
> 
> Thanks!
> 
> Regards,
> 
> Christer
>