Subject: [nfsv4] Comments on RFC5716 "Requirements for Federated File Systems"

From: "Nordgren, Bryce L -FS" <[email-masked]>
Date: Mon, 23 Apr 2012 21:05:41 +0000

Hello,

I think I may have a federated filesystem use case (and indeed may have an argument that this use case is common) which does not fit into RFC5716. Yet I also think this use case is what RFC5716 is striving to address. I'll use grid technologies (SAML-based) for an example.

Posit a geographically and organizationally distributed team of collaborators. The collaborators have nothing to do with the IT department of their respective organizations, however the organizations have joined a common identity federation (e.g., InCommon), and/or a number of other federations (DataONE, Open Science Grid, TeraGrid, etc.) The collaborators need to provision a project workspace (e.g., a "Virtual Research Environment" in gCube speak, or a "Site" in Sharepoint-speak) into which they can assemble existing datasets as well as create new ones. However, since some of the initial resources may very large, and/or stored in a repository outside the federation. It is much preferred to just link to the data, so as to avoid unnecessary copies.

The reasons I think this scenario falls outside the bounds of RFC5716 are (and please correct me if I am wrong):

1] Misalignment between "identity federation" and "data federation" boundaries. I took RFC5716 to silently assume that there is only one "identity+data" federation, whereas it seems to me that joining a single identity federation has enabled participation in many data federations.
2] Given that users can participate in multiple "data federations" provided that their organization has joined a common identity federation, an organization should be capable of deploying a single "external storage resource" which can be leveraged by any of the authorized members of any authorized federation. The alternative is to provide separate resources for each federation, requiring users to copy data just to get it in the same working environment. It seems to me that requirement R15: "It MUST be possible for the federation (again, which federation?) to project a namespace with a common root" may require that admins offer one-resource-per-federation.
3] Reliance on administrators to manage junctions. All administrators everywhere will hate you for this. :) Every single distributed team is going to have to do this, opening the floodgates of "can you link to this file for me" requests.
4] A Fileset is a directory tree-instead of individual files. This effectively excludes resources residing in non-hierarchical stores (Amazon S3, Ceph RADOS, Openstack Swift...) While I'm sure it is possible to "name the bucket" using a junction, users are going to want to specify the interesting files in the bucket. Next generation federated filesystems need to be cloud friendly.
5] I did not see where RFC5716 required all of the stores contributing content to the virtual filesystem to implement the same data access protocol. It seems like it should be possible to accommodate federation members implementing CIFS, NFS, and SRMv2.2 but also those exposing resources using FTP and HTTP. Content external to the federation (on a public web-facing repository, for instance) should also be fair game, albeit read-only. In this case, RFC5716 would impose a homogeneous interface on a view of heterogeneous resources, where the server(s) could take care of the translation.

A final observation: Two expired internet drafts (https://datatracker.ietf.org/doc/draft-ietf-nfsv4-federated-fs-admin/ and https://datatracker.ietf.org/doc/draft-ietf-nfsv4-federated-fs-protocol/) deal with the notion of a nameserver database and the administration interface. I have not read these yet, as I have been digesting RFC5716. However, it seems these services provide control over a multi-layered namespace, which is more or less the function of the Resource Naming Service v1.1 specification (GFD-171: http://www.opengridforum.org/documents/GFD.171.pdf). I looked for a "related work" section to quickly give me an idea of how the two are related, but didn't see one. I did see a load of what I'd consider to be implementation details: LDAP Schema for a NSDB constructed via LDAPv3, etc.  Might it be worthwhile to define RPC bindings against the GFD-171 abstract specification as an alternative to the LDAP implementation? Perhaps in a different ID/RFC?

Thanks for your patience.
Bryce

This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately.

---

From: Spencer Shepler <[email-masked]>
Date: Tue, 24 Apr 2012 06:11:25 +0000

From: [email-masked] [mailto:[email-masked]] On Behalf Of Nordgren, Bryce L -FS
Sent: Monday, April 23, 2012 2:06 PM
To: [email-masked]
Subject: [nfsv4] Comments on RFC5716 "Requirements for Federated File Systems"

A final observation: Two expired internet drafts (https://datatracker.ietf.org/doc/draft-ietf-nfsv4-federated-fs-admin/ and https://datatracker.ietf.org/doc/draft-ietf-nfsv4-federated-fs-protocol/) deal with the notion of a nameserver database and the administration interface. I have not read these yet, as I have been digesting RFC5716.

Note that these drafts are not expired but are in IESG review in preparation for publication as RFCs.

I will let the authors of those drafts respond to your input and observations.

Spencer