Subject: RE: [nfsv4] comments on draft-welch-pnfs-ops-00.txt

From: "Yoder, Alan" <[email-masked]>
Date: Tue, 16 Nov 2004 10:03:27 -0800

In other venues, protocols that do for block 
protocols what pNFS does for NFS are being
worked on.  The folks I've talked to call
these "SAN Filesystems".  

If anyone wants these efforts to be merged, 
I'd think they ought to be talking to 
the SAN Filesystem people too, not just the 
folks here.

Personally, I'd argue against trying to merge
them, on the grounds that that is the job of
a management layer.  SNIA is going to wrap a
management layer around parallel access 
protocols no matter whether there is one big
one or N little ones.  The time it takes to
do this will be about the same in either case.
And since N little IETF protocols can be developed
in parallel in less time than one big one, that
argues that you'll get a better time to market
for the whole package by keeping pNFS small.

Alan

===============================================================
Alan G. Yoder                                    [email-masked]
Technical Staff                          
Network Appliance, Inc.                            408-822-6919
===============================================================  

> -----Original Message-----
> From: Nicolas Williams [mailto:[email-masked]] 
> Sent: Monday, November 15, 2004 8:58 PM
> To: Brent Welch
> Cc: Mike Eisler; [email-masked]
> Subject: Re: [nfsv4] comments on draft-welch-pnfs-ops-00.txt
> 
> 
> On Mon, Nov 15, 2004 at 07:12:12PM -0800, Brent Welch wrote:
> > Let me try some simple logic.
> > 
> > My kitten has green eyes.  Therefore all kittens have green eyes.
> > 
> > Block storage protocols are insecure, 
> > therefore all storage protocols are insecure.
> 
> NFSv4 is not a block storage protocol.  Neither will pNFS be 
> one either.
> 
> You're comparing kittens to fully grown dogs.
> 
> Or is pNFS an improvement on block storage?  I don't see it that way.
> Perhaps you do and can persuade us of this view?  I do see pNFS as an
> improvement on _NFS_.
> 
> Seriously, figure out what security (and operational) properties you
> want a pNFS to provide, figure out what you can get with each storage
> protocol option and let's see where this goes.
> 
> Also, do we really have enough info right now to figure out 
> that, yeah,
> pNFS w/ iSCSI can be made to work w/o mods to deployed iSCSI boxes?  I
> suspect the answer is "no."  Further, I suspect the answer is 
> that mods
> will be needed.  Finally, I'd much rather see a pNFS solution that has
> security properties that truly are comparable to NFSv4's.
> 
> > I would like to table all discussion of block protocol security
> > as being out of scope.  I think it clouds the issue and gets in
> > the way of working out an acceptable pNFS extension.
> 
> We're not trying to improve block storage protocols, but 
> we're trying to
> come up with a parallelized NFS protocol -- a much, _much_ different
> beast that block storage protocols.
> 
> So what's in scope is: what sort of protocol should pNFS 
> clients use to
> talk to the storage.
> 
> And BTW, I've yet to argue that iSCSI needs improvements.
> 
> > I am trying to communicate three points:
> > 
> > 1. pNFS can use NFSv4 as the storage protocol, and should be just
> > as secure as NFSv4.  I think REQUIREing that NFSv4 be implemented
> > by all clients as one of their possible storage protocols is OK,
> > and makes perfect sense.
> 
> This is my position.  (Though some client<->storage extensions may be
> needed for some things, for all I know.)
> 
> > 2. pNFS should allow different storage protocols.  These 
> are OPTIONAL
> > storage protocols.  This is important to me because my preferred
> > storage protocol is object storage (iSCSI/OSD).  And, there 
> are others
> > for whom other storage protocols are important (legacy NFS servers,
> > PVFS implementations, block storage on a SAN).  Harking back to the
> > alice in wonderland logic above, it should be OK to allow other
> > storage protocols w/out compromising pNFS when used with NFSv4 
> > or some other secure storage protocol.  Please don't 
> misinterpret this.
> > OF COURSE if a customer chooses to use an insecure storage protocol
> > they are taking a risk.  But, that doesn't mean all customers are
> > taking the same risk because they don't have to use or provide those
> > insecure storage protocols in their environment.
> 
> Perhaps this will fly past the IESG, perhaps not.  I think we should
> inquire with them at some point (and their answer may be that 
> they can't
> yet answer so you just have to try to deliver a document to them and
> see).  Of course, first we need WG consensus on this.
> 
> > 3. Object storage has a secure protocol, but it does place a
> > demand on the pNFS client to NFSv4 server communication.
> > This is worth debating. It requires that capabilities and signing
> > keys be returned to the client over a secure channel so they cannot
> > be snooped.
> 
> NFSv4 as the storage protocol is like an OSD that knows how 
> to evaluate
> ACLs.  Alternatives include a pNFS-server<->storage protocol that
> enables a client to do X, and your capabilities token approach is a
> third approach.
> 
> Cheers,
> 
> Nico
> -- 
> 
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nfsv4
> 

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: Craig Everhart <[email-masked]>
Date: Thu, 18 Nov 2004 22:32:05 -0500

> worked on.  The folks I've talked to call

Right.

> the SAN Filesystem people too, not just the

Who else needs to be told?

My day job is working on a SAN file system, so at least
some of the SAN Filesystem people are here.

> for the whole package by keeping pNFS small.

Are you saying that nfsv4 isn't the right group to
be discussing this, that it's not properly an IETF
thing?

I don't believe that the pNFS effort has imagined that there
would be one big protocol, but rather a smaller one with
a choice of third-party data access protocols.  Perhaps, as
discussion has happened here, use of one of those protocols would
be required for conformance.  I don't really say it that
way; here's why.  The pNFS effort was doing a couple of
things: one of them was to define new third-party data
transports as NFS extensions, but equally (or, from my
own point of view, more so) it was trying to integrate
third-party transport mechanisms into NFS, allowing
NFS to be the client-server protocol that could be used
as part of a SAN Filesystem (as you name it).  I'm
myself very interested in an NFS client being able to
do block SCSI over FC to a storage device.  But the particular
protocol that could be used to talk to a storage device is
more likely to be chosen in advance by whoever deploys the
storage device.  It could be that a single machine could
talk block SCSI over FC to one device, OBS SCSI to another
device, and one or two variants of sub-file that we see
being discussed on the list to a third or fourth device.
But it may not be likely that *all* those protocols will
be deployed at a given client, and it's not likely that their
definitions and interoperability stories will mature at the
same rate.  So what we had discussed as a possibility was
thinking of the pNFS extension to NFS as a single entity with
multiple sub-types.  The sub-types could progress towards
interoperability status independently, while at least one
of them would be required in order to allow the production
of "working code" for pNFS.  That is, pNFS proper, dealing
with layouts and such, doesn't care which sub-type is in use,
as long as there is one that is implemented by the particular
client and the particular third-party storage (storage system
or OBS disk or "data server" via NFS).

So some folks are saying that the best way to achieve this
is to pick one sub-type and consider that alone for pNFS first,
then strive to add other sub-types only after pNFS is much
further along.  But doing this risks consensus over the choice
of one of the variants, and it's also a recipe for
substantial delay for the less-preferred sub-types.

Would it be unprecedented to have a handful of possible
sub-types and require one or more of them, but no matter which,
to test pNFS implementations?  I remember the early IP
specification RFC, followed by a few on "IP on Experimental
Ethernet" and "IP on Chaosnet" kinds of stacking discussions,
but they may not be that helpful as models--we're not really
doing stacking, but we have a variety of embeddings for the
protocol.