Subject: [nfsv4] Soliciting Agenda items for IETF 87 NFSv4 working group meeting

From: Spencer Shepler <[email-masked]>
Date: Tue, 14 May 2013 18:54:02 +0000

In preparation in meeting the deadline for meeting requests as posted here (http://www.ietf.org/meeting/cutoff-dates-2013.html#IETF87),
Please send me your ideas and commitments to the agenda.

Given that June 3rd is a Monday, please attempt to submit your agenda items by May 31st to allow for roll-up, etc.

Spencer

---

From: "Noveck, David" <[email-masked]>
Date: Tue, 14 May 2013 22:09:14 -0400

I'll get a rough outline to you ASAP and certainly within a few weeks.

We've had previous discussion about people's need to schedule their travel plan's early enough to accommodate corporate travel approval and the further nightmare of airline booking.  We had figured two months before the meeting for this, which would require a go/don't-go decision by 5/28.

Can we assume that we will be meeting at IETF87?   It appears from the discussion so far that we will have lots of things to discuss, but I'd like to be sure about our plans to meet before I start making plans to travel.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Spencer Shepler
Sent: Tuesday, May 14, 2013 2:54 PM
To: [email-masked]
Subject: [nfsv4] Soliciting Agenda items for IETF 87 NFSv4 working group meeting

Spencer

---

From: Spencer Shepler <[email-masked]>
Date: Wed, 15 May 2013 05:11:52 +0000

David,

We can move the deadline for agenda items 5/28 if you like an there are no other objections.

Everyone requesting a timeslot for the next meeting should respond to me on this thread with their topic, I-D (if applicable), and time needed.  This doesn't need to be to the entire list but can be.

Spencer

From: Noveck, David [mailto:[email-masked]]
Sent: Tuesday, May 14, 2013 7:09 PM
To: Spencer Shepler; [email-masked]
Subject: RE: [nfsv4] Soliciting Agenda items for IETF 87 NFSv4 working group meeting

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Spencer Shepler
Sent: Tuesday, May 14, 2013 2:54 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [nfsv4] Soliciting Agenda items for IETF 87 NFSv4 working group meeting

Spencer

---

From: Benny Halevy <[email-masked]>
Date: Wed, 15 May 2013 08:25:46 +0300

On Wed, May 15, 2013 at 8:11 AM, Spencer Shepler <[email-masked]> wrote:
> Everyone requesting a timeslot for the next meeting should respond to me on
> this thread with their topic, I-D (if applicable), and time needed.  This

I'd like to discuss the flexible files layout (a.k.a. nfs-objects).
Time needed: 15-20 minutes.

Thanks,

Benny

> doesn’t need to be to the entire list but can be.
>
>
>
> Spencer
>
>
>
> I’ll get a rough outline to you ASAP and certainly within a few weeks.
>
>
>
> We’ve had previous discussion about people’s need to schedule their travel
> plan’s early enough to accommodate corporate travel approval and the further
> nightmare of airline booking.  We had figured two months before the meeting
> for this, which would require a go/don’t-go decision by 5/28.
>
>
>
> Can we assume that we will be meeting at IETF87?   It appears from the
> discussion so far that we will have lots of things to discuss, but I’d like
> to be sure about our plans to meet before I start making plans to travel.
>
>
>
> In preparation in meeting the deadline for meeting requests as posted here
> (http://www.ietf.org/meeting/cutoff-dates-2013.html#IETF87),
>
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4
>

---

From: Chuck Lever <[email-masked]>
Date: Wed, 15 May 2013 10:27:20 -0400

On May 15, 2013, at 1:11 AM, Spencer Shepler <[email-masked]> wrote:

> Everyone requesting a timeslot for the next meeting should respond to me on this thread with their topic, I-D (if applicable), and time needed.  This doesn’t need to be to the entire list but can be.

A FedFS document status update might be interesting to some.  Would take about 15 minutes.

The recent FedFS related e-mail threads seemed to have died, and may need some attention before them.

> We’ve had previous discussion about people’s need to schedule their travel plan’s early enough to accommodate corporate travel approval and the further nightmare of airline booking.  We had figured two months before the meeting for this, which would require a go/don’t-go decision by 5/28.
>  
> Can we assume that we will be meeting at IETF87?   It appears from the discussion so far that we will have lots of things to discuss, but I’d like to be sure about our plans to meet before I start making plans to travel.
>  

-- 
Chuck Lever
chuck[dot]lever[at]oracle[dot]com

---

From: Chuck Lever <[email-masked]>
Date: Wed, 15 May 2013 10:32:05 -0400

> Everyone requesting a timeslot for the next meeting should respond to me on this thread with their topic, I-D (if applicable), and time needed.  This doesn’t need to be to the entire list but can b…

I've been encouraged to request a time slot to discuss "what to do about end-to-end [data integrity support] now".  Perhaps this falls under the rubric of NFSv4.3, but I think in the short term it would be more appropriate to discuss prototyping opportunities first before we slot end-to-end into a particular NFSv4 minor version.

Meanwhile, I have some writing that I want to boil down into a concrete protocol proposal.  I can't promise it will appear as an I-D by 7/7, given a full plate, but I will try.

---

From: Spencer Shepler <[email-masked]>
Date: Wed, 15 May 2013 15:45:31 +0000

For the FedFS documents, they are with the IETF Editor at this point and are awaiting the completion of rfc3530bis.
Not sure what else we will cover for those documents proper.

You have raised issues and this will require additional document work at this point, right?  I am expecting either a new I-D to describe the issues and methods of workaround or new work to correct.  Am I off base?

We can place something on the agenda but it will be about the new work at this point - not just general status; we can cover general status on the working group alias unless we need to drive open issues to closure via face-to-face.

Spencer

From: Chuck Lever [mailto:[email-masked]]
Sent: Wednesday, May 15, 2013 7:27 AM
To: Spencer Shepler
Cc: Noveck, David; [email-masked]
Subject: Re: [nfsv4] Soliciting Agenda items for IETF 87 NFSv4 working group meeting

On May 15, 2013, at 1:11 AM, Spencer Shepler <[email-masked]<mailto:[email-masked]>> wrote:

David,

Spencer

From: Noveck, David [mailto:[email-masked]<http://emc.com>]
Sent: Tuesday, May 14, 2013 7:09 PM
To: Spencer Shepler; [email-masked]<mailto:[email-masked]>
Subject: RE: [nfsv4] Soliciting Agenda items for IETF 87 NFSv4 working group meeting

Spencer

_______________________________________________
nfsv4 mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/nfsv4

---

From: Spencer Shepler <[email-masked]>
Date: Wed, 15 May 2013 15:52:47 +0000

Chuck,

I went back and reviewed your presentation from Paris.

My brief comments about the idea are as follows:

-          T10 mechanism are identified as one method to build upon; would be helpful to understand if this is the only method available or if other mechanisms may allow for a better fit for NFSv4 usage (assuming that the T10 mechanisms are not a good fit).

-          If there is migration/replication occurring for the files in such a way that the file content is covered via integrity on one file server and not cover on another, is this a failure?  Should the application be able to apply prescriptive guidance to avoid this?  Administrative control?  Is this even an issue?

More generally, this functionality seems well aligned to a simple, new pNFS layout type that would let the client opt-in for the support and let the server control things like migration or change in integrity type while the file is open.  Using a pNFS layout could introduce new operations in support of integrity and would provide a timeline outside of a general minor version update.  Just a thought - at a minimum, this could be used for prototyping and deployment.

Spencer

From: Chuck Lever [mailto:[email-masked]]
Sent: Wednesday, May 15, 2013 7:32 AM
To: Spencer Shepler
Cc: Noveck, David; [email-masked]
Subject: Re: [nfsv4] Soliciting Agenda items for IETF 87 NFSv4 working group meeting

David,

Spencer

Spencer

---

From: Chuck Lever <[email-masked]>
Date: Wed, 15 May 2013 11:58:04 -0400

> Not sure what else we will cover for those documents proper.

I was expecting to discuss the new issues and what we plan to do to address them, but...

> You have raised issues and this will require additional document work at this point, right?  I am expecting either a new I-D to describe the issues and methods of workaround or new work to correct.…

I think you asked on the e-mail list for consensus on how to proceed, and received no replies.  We need to close that loop before I can define exactly what is going to be delivered.

> We can place something on the agenda but it will be about the new work at this point – not just general status; we can cover general status on the working group alias unless we need to drive open issues to closure via face-to-face.

Agreed, thanks for clarifying.

---

From: Chuck Lever <[email-masked]>
Date: Wed, 15 May 2013 12:59:29 -0400

> -          T10 mechanism are identified as one method to build upon; would be helpful to understand if this is the only method available or if other mechanisms may allow for a better fit for NFSv4…

I think T10 should be allowed (to support SCSI pNFS layouts), but we will need to accommodate other types of integrity metadata.  For example, we may want to support a mechanism where a cryptographic checksum is applied to detect active third-party data tampering while the data is on durable storage (such tampering would also be able to update a regular CRC on those blocks).

> -          If there is migration/replication occurring for the files in such a way that the file content is covered via integrity on one file server and not cover on another, is this a failure?  Sh…

I think migration is interesting, but out of scope for NFS end-to-end (in the same sense that server-to-server copy mechanisms are out of scope; they are the business of the servers involved, not of the server-to-client relationship with which NFS itself is concerned).

Administrative tools on the two sides of the file system transition can, and probably should, enforce a migration ban when either the data transfer mechanism or the destination fileserver does not support Protection Information.

> More generally, this functionality seems well aligned to a simple, new pNFS layout type that would let the client opt-in for the support and let the server control things like migration or change in integrity type while the file is open.  Using a pNFS layout could introduce new operations in support of integrity and would provide a timeline outside of a general minor version update.  Just a thought – at a minimum, this could be used for prototyping and deployment.

For a SCSI block device, this could require little or no protocol change, since a SCSI initiator should be able to use the T10 PI capability already available in SBC-3 and later.

However, when a block DS goes offline and clients fail over to the MDS using NFS, PI must be communicated via native NFS, it seems to me.  That is the work I'd like to specify.

Keep in mind I've had little contact with pNFS, so I could be ignorant about an obvious way to make this work.

---

From: "Noveck, David" <[email-masked]>
Date: Wed, 15 May 2013 13:04:49 -0400

As I said:

>We had figured two months before the meeting for this, which would require a go/don't-go decision by 5/28.

Given that need, I don't see how moving the deadline to 5/28 helps things all that much.  Wih the original 5/31 date you acknowledged a lead time before a 6/3 decision.

> Can we assume that we will be meeting at IETF87?   It appears from the discussion so far that
> we will have lots of things to discuss, but I'd like to be sure about our plans to meet before I start
> making plans to travel.

As I recall, when this whole don't-assume-we're meeting thing came up, you agreed to give people notice in time for them to make travel plans.  Is that assurance now inoperative or can we simply decide that we will meet t IETF87 and let travel booking activities begin?

From: Spencer Shepler [mailto:[email-masked]]
Sent: Wednesday, May 15, 2013 1:12 AM
To: Noveck, David; [email-masked]
Subject: RE: [nfsv4] Soliciting Agenda items for IETF 87 NFSv4 working group meeting

David,

Spencer

Spencer

---

From: Spencer Shepler <[email-masked]>
Date: Wed, 15 May 2013 17:07:39 +0000

My comments are inline below...

From: Chuck Lever [mailto:[email-masked]]
Sent: Wednesday, May 15, 2013 9:59 AM
To: Spencer Shepler
Cc: Noveck, David; [email-masked]
Subject: Re: [nfsv4] Soliciting Agenda items for IETF 87 NFSv4 working group meeting

On May 15, 2013, at 11:52 AM, Spencer Shepler <[email-masked]<mailto:[email-masked]>> wrote:

Chuck,

[Spencer] Ah, this is a good use case and agree that having a variety of checksum methods would be useful.

Administrative tools on the two sides of the file system transition can, and probably should, enforce a migration ban when either the data transfer mechanism or the destination fileserver does not support Protection Information.
[Spencer] I would see a value of this is to provide application level to storage at rest integrity.  The application should get what it wants with respect to the integrity if it is a value the application is attempting to deliver.  Whether it is in the protocol or not, I don't have a strong opinion but we should include this as a primary use case and determine what should be in place to allow for the administrative direction to the file server.

Keep in mind I've had little contact with pNFS, so I could be ignorant about an obvious way to make this work.
[Spencer] I am imagining a new layout type that is similar to pNFS files but is on a separate RPC program number so it would be allow to define new operations and thus enabled to innovate outside of the requirement of a new minor version for example.  I think the integrity work is a great example of how layouts would enable timely delivery of the functionality.

Spencer

Spencer

From: Chuck Lever [mailto:[email-masked]<http://oracle.com>]
Sent: Wednesday, May 15, 2013 7:32 AM
To: Spencer Shepler
Cc: Noveck, David; [email-masked]<mailto:[email-masked]>
Subject: Re: [nfsv4] Soliciting Agenda items for IETF 87 NFSv4 working group meeting

David,

Spencer

Spencer

---

From: Spencer Shepler <[email-masked]>
Date: Wed, 15 May 2013 17:12:04 +0000

My suggestion of 5/31 was to account for the fact that the 6/3 closure of submitted meetings may close more quickly than people expect (UTC 24:00) was accounting for the timezone shift that will occur (and the weekend).

Given that we have 2 agenda items at this point, no, I wouldn't assume that we are meeting.

If the agenda fills out before 5/28, then we can make the call earlier.  So 5/28 is the "the decision will be made no later than" date.

Spencer

From: Noveck, David [mailto:[email-masked]]
Sent: Wednesday, May 15, 2013 10:05 AM
To: Spencer Shepler; [email-masked]
Subject: RE: [nfsv4] Soliciting Agenda items for IETF 87 NFSv4 working group meeting

From: Spencer Shepler [mailto:[email-masked]]
Sent: Wednesday, May 15, 2013 1:12 AM
To: Noveck, David; [email-masked]<mailto:[email-masked]>
Subject: RE: [nfsv4] Soliciting Agenda items for IETF 87 NFSv4 working group meeting

David,

Spencer

Spencer

---

From: "faibish, sorin" <[email-masked]>
Date: Wed, 15 May 2013 13:36:54 -0400

+pNFS Lustre layout. I posted a new updated version addressing most of the complains from Atlanta. I will send an email to start discussion soon. Thanks

./Sorin

Sent from my iPhone

On May 15, 2013, at 1:30 PM, "Spencer Shepler" <[email-masked]<mailto:[email-masked]>> wrote:

Given that we have 2 agenda items at this point, no, I wouldn’t assume that we are meeting.

If the agenda fills out before 5/28, then we can make the call earlier.  So 5/28 is the “the decision will be made no later than” date.

Spencer

As I said:

>We had figured two months before the meeting for this, which would require a go/don’t-go decision by 5/28.

Given that need, I don’t see how moving the deadline to 5/28 helps things all that much.  Wih the original 5/31 date you acknowledged a lead time before a 6/3 decision.

> we will have lots of things to discuss, but I’d like to be sure about our plans to meet before I start
> making plans to travel.

As I recall, when this whole don’t-assume-we’re meeting thing came up, you agreed to give people notice in time for them to make travel plans.  Is that assurance now inoperative or can we simply decide that we will meet t IETF87 and let travel booking activities begin?

David,

Spencer

Spencer

---

From: Spencer Shepler <[email-masked]>
Date: Wed, 15 May 2013 17:43:36 +0000

How much time do you need, Sorin.

I will await your email thread to draw out further discussion topics.

Spencer

From: faibish, sorin [mailto:[email-masked]]
Sent: Wednesday, May 15, 2013 10:37 AM
To: Spencer Shepler
Cc: Noveck, David; [email-masked]
Subject: Re: [nfsv4] Soliciting Agenda items for IETF 87 NFSv4 working group meeting

./Sorin

Sent from my iPhone

Spencer

David,

Spencer

Spencer

---

From: "Noveck, David" <[email-masked]>
Date: Wed, 15 May 2013 13:51:43 -0400

Maybe I'm using an automatic weapon on a dead horse here, but ...

First of all, I hope any PETA people will note that the horse is already dead.

I don't believe that the fact that that there nobody able and willing to do RPCSEC_GSSv3 indicates that there is no interest in or energy for doing this or other new work beyond what is within the existing confines of v4.2,

I agree with Spencer that a new mapping type might be good as a prototyping vehicle.  I think this is a good way of laying temporary track to deal with the fact that we have a stuck train (my metaphor, for which Spencer is not responsible).

Ultimately we cannot avoid at least a small amount of work in the base protocol.  As it now seems that mention of v4.3 "ist streng verboten" let me note that the basic problem is that currently layouts are optional and can always be recalled.  So it seems that some future minor version would have to provide a way of dealing with this issue.  Some possibilities:

*         Use of READ_PLUS and WRITE_PLUS with enums for including protection information.

*         New READ_PI and WRITE_PI ops.

*         A statement allowing mapping types to excuse themselves from the layout-are-optional model.  Presumably the client would have to be aware of this and accept it.

From: Spencer Shepler [mailto:[email-masked]]
Sent: Wednesday, May 15, 2013 11:53 AM
To: Chuck Lever
Cc: Noveck, David; [email-masked]
Subject: RE: [nfsv4] Soliciting Agenda items for IETF 87 NFSv4 working group meeting

Chuck,

Spencer

David,

Spencer

Spencer

---

From: Spencer Shepler <[email-masked]>
Date: Wed, 15 May 2013 18:15:01 +0000

The way I was thinking of the new layout type is this:

The integrity capability is going to be new/optional to begin with so that a new pNFS layout type to include the functionality is no different.

The layout doesn't need to go to an array of data servers (just stating the obvious) but can stay with the MDS and the pNFS layout is a method of launching a new protocol extension in a standard way.  The server and client can agree not to recall the pNFS layout given that it is just a method of introducing this level of indirection to provide new operation types.   A long way of saying I am not sure I see a reason the base protocol has to be updated to support the functionality.

Just running a thought experiment.

Spencer

From: Noveck, David [mailto:[email-masked]]
Sent: Wednesday, May 15, 2013 10:52 AM
To: Spencer Shepler; Chuck Lever
Cc: [email-masked]
Subject: RE: [nfsv4] Soliciting Agenda items for IETF 87 NFSv4 working group meeting

Chuck,

Spencer

David,

Spencer

Spencer

---

From: "Noveck, David" <[email-masked]>
Date: Wed, 15 May 2013 14:56:00 -0400

Running thought experiments does not consensus from anyone, thankfully.

From: Spencer Shepler [mailto:[email-masked]]
Sent: Wednesday, May 15, 2013 2:15 PM
To: Noveck, David; Chuck Lever
Cc: [email-masked]
Subject: RE: [nfsv4] Soliciting Agenda items for IETF 87 NFSv4 working group meeting

Spencer

Cc: [email-masked]<mailto:[email-masked]>

Chuck,

Spencer

David,

Spencer

Spencer

---

From: Chuck Lever <[email-masked]>
Date: Wed, 15 May 2013 15:01:44 -0400

On May 15, 2013, at 1:51 PM, "Noveck, David" <[email-masked]> wrote:

> Maybe I’m using an automatic weapon on a dead horse here, but …
>  
> I don’t believe that the fact that that there nobody able and willing to do RPCSEC_GSSv3 indicates that there is no interest in or energy for doing this or other new work beyond what is within the existing confines of v4.2,
>  
> Ultimately we cannot avoid at least a small amount of work in the base protocol.

One reason a base-protocol change might be a better long-term choice is that we want to avoid creating new layouts for each new small feature, which would cause a quickly diverging tree of layout types "has this feature, does not have this one."

I agree in general that though we can do what we like in a lab environment, we can't avoid prototyping in the base protocol, especially when a consensus arises that a new feature will become part of the base NFS protocol and we wish to proceed with standardization.

> As it now seems that mention of v4.3 “ist streng verboten” let me note that the basic problem is that currently layouts are optional and can always be recalled.  So it seems that some future minor version would have to provide a way of dealing with this issue.  Some possibilities:
> ·         Use of READ_PLUS and WRITE_PLUS with enums for including protection information.

The original thought for communicating Protection Information was to use READ_PLUS and WRITE_PLUS.  We introduced extensibility mechanisms in these operations in NFSv4.2 expressly for this kind of feature.  I was planning to build end-to-end on this new extensibility capability.

Moreover, I don't envision a long list of new operations for handling PI.  A PI read mechanism, a PI write mechanism, a new GETATTR capability ("what integrity mechanisms do you support, server?") and a handful of new error codes are probably all that is needed to support a variety of integrity mechanisms.

Although I agree it would be interesting to explore the use of a new pNFS layout for prototyping, building the infrastructure for a new layout type and a separate RPC program number to handle these simple changes seems like overkill.

> ·         New READ_PI and WRITE_PI ops.
> ·         A statement allowing mapping types to excuse themselves from the layout-are-optional model.  Presumably the client would have to be aware of this and accept it.

I'm still not understanding something.  If a SCSI DS fails and a client wants to continue writing with PI, a simple failover could not work.  The MDS presumably would have to know about the DS failure and recall the existing block layout, then offer a "new PI-enabled" layout to the client.  Correct?

---

From: "Matt W. Benjamin" <[email-masked]>
Date: Wed, 15 May 2013 15:07:58 -0400 (EDT)

If a layouts are the preferred delivery mechanism for a growing list of features, that suggests that greater consideration for how layouts may be composed will be important.

My own intuition is that deferring the problem to final integration with a standard might shortchange discussion on how to lower cost of integration, semantics, of multiple layouts, that should be given careful consideration earlier rather than later.

Matt

----- "Chuck Lever" <[email-masked]> wrote:

> On May 15, 2013, at 1:51 PM, "Noveck, David" < [email-masked] >
> wrote:
> 
> 
> 
> 
> 
> I don’t believe that the fact that that there nobody able and willing
> to do RPCSEC_GSSv3 indicates that there is no interest in or energy
> for doing this or other new work beyond what is within the existing
> confines of v4.2,
> 
> I agree with Spencer that a new mapping type might be good as a
> prototyping vehicle. I think this is a good way of laying temporary
> track to deal with the fact that we have a stuck train (my metaphor,
> for which Spencer is not responsible).
> 
> One reason a base-protocol change might be a better long-term choice
> is that we want to avoid creating new layouts for each new small
> feature, which would cause a quickly diverging tree of layout types
> "has this feature, does not have this one."
> 
> 
> I agree in general that though we can do what we like in a lab
> environment, we can't avoid prototyping in the base protocol,
> especially when a consensus arises that a new feature will become part
> of the base NFS protocol and we wish to proceed with standardization.
> 
> 
> 
> 
> 
> 
> 
> As it now seems that mention of v4.3 “ist streng verboten” let me note
> that the basic problem is that currently layouts are optional and can
> always be recalled. So it seems that some future minor version would
> have to provide a way of dealing with this issue. Some possibilities:
> The original thought for communicating Protection Information was to
> use READ_PLUS and WRITE_PLUS. We introduced extensibility mechanisms
> in these operations in NFSv4.2 expressly for this kind of feature. I
> was planning to build end-to-end on this new extensibility capability.
> 
> 
> Moreover, I don't envision a long list of new operations for handling
> PI. A PI read mechanism, a PI write mechanism, a new GETATTR
> capability ("what integrity mechanisms do you support, server?") and a
> handful of new error codes are probably all that is needed to support
> a variety of integrity mechanisms.
> 
> 
> Although I agree it would be interesting to explore the use of a new
> pNFS layout for prototyping, building the infrastructure for a new
> layout type and a separate RPC program number to handle these simple
> changes seems like overkill.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> · A statement allowing mapping types to excuse themselves from the
> layout-are-optional model. Presumably the client would have to be
> aware of this and accept it.
> 
> 
> I'm still not understanding something. If a SCSI DS fails and a client
> wants to continue writing with PI, a simple failover could not work.
> The MDS presumably would have to know about the DS failure and recall
> the existing block layout, then offer a "new PI-enabled" layout to the
> client. Correct?
> 
> 
> 
> 
> 
> 
> 
> 
> 
> From: Spencer Shepler [mailto:sshepler@ microsoft.com ]
> - T10 mechanism are identified as one method to build upon ; would be
> helpful to understand if this is the only method available or if other
> mechanisms may allow for a better fit for NFSv4 usage (assuming that
> the T10 mechanisms are not a good fit).
> - If there is migration/replication occurring for the files in such a
> way that the file content is covered via integrity on one file server
> and not cover on another, is this a failure? Should the application be
> able to apply prescriptive guidance to avoid this? Administrative
> control? Is this even an issue?
> 
> More generally, this functionality seems well aligned to a simple, new
> pNFS layout type that would let the client opt-in for the support and
> let the server control things like migration or change in integrity
> type while the file is open. Using a pNFS layout could introduce new
> operations in support of integrity and would provide a timeline
> outside of a general minor version update. Just a thought – at a
> minimum, this could be used for prototyping and deployment.
> 
> Spencer
> 
> 
> 
> 
> From: Chuck Lever [ mailto:[email-masked] ]
> On May 15, 2013, at 1:11 AM, Spencer Shepler < [email-masked]
> > wrote:
> 
> 
> 
> 
> 
> 
> 
> David,
> 
> 
> 
> Everyone requesting a timeslot for the next meeting should respond to
> me on this thread with their topic, I-D (if applicable), and time
> needed. This doesn’t need to be to the entire list but can be.
> 
> 
> 
> I've been encouraged to request a time slot to discuss "what to do
> about end-to-end [data integrity support] now". Perhaps this falls
> under the rubric of NFSv4.3, but I think in the short term it would be
> more appropriate to discuss prototyping opportunities first before we
> slot end-to-end into a particular NFSv4 minor version.
> 
> 
> 
> Meanwhile, I have some writing that I want to boil down into a
> concrete protocol proposal. I can't promise it will appear as an I-D
> by 7/7, given a full plate, but I will try.
> 
> 
> 
> 
> 
> 
> 
> Spencer
> 
> 
> 
> 
> From: Noveck, David [mailto:david.noveck@ emc.com ]
> We’ve had previous discussion about people’s need to schedule their
> travel plan’s early enough to accommodate corporate travel approval
> and the further nightmare of airline booking. We had figured two
> months before the meeting for this, which would require a go/don’t-go
> decision by 5/28.
> 
> 
> 
> discussion so far that we will have lots of things to discuss, but I’d
> like to be sure about our plans to meet before I start making plans to
> travel.
> 
> 
> 
> 
> From: [email-masked] [ mailto:[email-masked] ] On
> Behalf Of Spencer Shepler
> In preparation in meeting the deadline for meeting requests as posted
> here ( http://www.ietf.org/meeting/cutoff-dates-2013.html#IETF87 ),
> 
> Given that June 3 rd is a Monday, please attempt to submit your agenda
> items by May 31 st to allow for roll-up, etc.
> 
> 
> 
> Spencer
> 
> 

-- 
Matt Benjamin
The Linux Box
206 South Fifth Ave. Suite 150
Ann Arbor, MI  48104

http://linuxbox.com

tel.  734-761-4689 
fax.  734-769-8938 
cel.  734-216-5309

---

From: Spencer Shepler <[email-masked]>
Date: Thu, 16 May 2013 00:53:38 +0000

My suggestion, Chuck, of using a pNFS layout for this work was not to use data-servers via block mode.
The MDS and DS in my mind would be the same server and the pNFS layout is being used to introduce the new functionality and thus is a files-like layout type that uses the T10 mechanisms (and others) as a way to communicate integrity data.

Spencer

From: Chuck Lever [mailto:[email-masked]]
Sent: Wednesday, May 15, 2013 12:02 PM
To: Noveck, David
Cc: Spencer Shepler; [email-masked]
Subject: Re: [nfsv4] Soliciting Agenda items for IETF 87 NFSv4 working group meeting

On May 15, 2013, at 1:51 PM, "Noveck, David" <[email-masked]<mailto:[email-masked]>> wrote:

As it now seems that mention of v4.3 "ist streng verboten" let me note that the basic problem is that currently layouts are optional and can always be recalled.  So it seems that some future minor version would have to provide a way of dealing with this issue.  Some possibilities:
*         Use of READ_PLUS and WRITE_PLUS with enums for including protection information.

From: Spencer Shepler [mailto:[email-masked]<http://microsoft.com>]
Sent: Wednesday, May 15, 2013 11:53 AM
To: Chuck Lever
Cc: Noveck, David; [email-masked]<mailto:[email-masked]>
Subject: RE: [nfsv4] Soliciting Agenda items for IETF 87 NFSv4 working group meeting

Chuck,

Spencer

David,

Spencer

Spencer

---

From: Chuck Lever <[email-masked]>
Date: Wed, 15 May 2013 21:46:01 -0400

Comments inline.

--
Chuck Lever
[email-masked]

> The MDS and DS in my mind would be the same server and the pNFS layout is being used to introduce the new functionality and thus is a files-like layout type that uses the T10 mechanisms (and others…

I recognize that we are talking about different approaches to prototyping this feature, so let me explain my thinking.

Having an application use case or two to drive our prototype is key.

An ongoing issue with this work is how applications will communicate PI data to their local NFS client.  There is no POSIX API today I am aware of that an application can use to perform read and write operations with PI data.

And, there are also no good mechanisms for conveying T10 PI data through a page cache via a standard VFS/VM.  A type 1 Protection Information field stores an LBA in its reference tag.  There's no practical way to get server storage LBAs to an application running on a client.

Thus our guess is that the first users of an NFS end-to-end capability will be non-traditional NFS clients such as hypervisors and user space database clients, and that they will prefer staying with a block I/O paradigm (although not necessarily a SCSI transport), and probably will want to take advantage of the performance benefits that existing pNFS layouts offer.

Storage reliability in these two use cases is key.  We want to consider not just the details of how the PI bits are moved across the wire, but what happens when one of the myriad things that can go wrong does go wrong.  Where NFS files come into play in a block situation is MDS fallback.

We also need to understand exactly how a protection field is filled in by an application running on a host that is not directly attached to the storage, and whether that is a useful way to protect against the kind of integrity threats that I/O faces with NFS.  An NFS file can be used to back a virtual block device, and the type 1 LBA information can be computed as an offset from the beginning of the file.  Or we may prefer a protection type that uses a sequence number instead of LBAs in the reference tag, to catch a client that is misordering pages or writes.

Given the block-centric nature of T10, I expect that eventually byte-stream-oriented NFS will require its own protection envelope and protect types, and NFS I/O requests will be transitioned on each end of its envelope into a different protection envelope (the server may very well use DIX from host to controller and T10 PI from controller to durable storage, for example).

I think even the block world has given up on the idea that an application in user space can fill in the reference and application tags correctly.  We will very likely abandon that idea for NFS as well.

---

From: Marc Eshel <[email-masked]>
Date: Fri, 17 May 2013 12:23:09 -0700

I would like to add a 20 minutes presentation to the agenda to propose a 
more coherent data caching for NFS.

The objective of this presentation will be to talk about how to improve 
NFS client caching for NFS4.3. I would like to find out from the group if 
one, others see this as a useful  objective, and two, if extending the 
delegations feature is the right approach. I will post another email with 
more detail for post meeting discussion.
Marc.

From:   Spencer Shepler <[email-masked]>
To:     "Noveck, David" <[email-masked]>, "[email-masked]" 
<[email-masked]>, 
Date:   05/14/2013 10:12 PM
Subject:        Re: [nfsv4] Soliciting Agenda items for IETF 87 NFSv4 
working group   meeting
Sent by:        [email-masked]

David,
 
We can move the deadline for agenda items 5/28 if you like an there are no 
other objections.
 
Everyone requesting a timeslot for the next meeting should respond to me 
on this thread with their topic, I-D (if applicable), and time needed. 
This doesn?t need to be to the entire list but can be.
 
Spencer
 
From: Noveck, David [mailto:[email-masked]] 
Sent: Tuesday, May 14, 2013 7:09 PM
To: Spencer Shepler; [email-masked]
Subject: RE: [nfsv4] Soliciting Agenda items for IETF 87 NFSv4 working 
group meeting
 
I?ll get a rough outline to you ASAP and certainly within a few weeks.
 
We?ve had previous discussion about people?s need to schedule their travel 
plan?s early enough to accommodate corporate travel approval and the 
further nightmare of airline booking.  We had figured two months before 
the meeting for this, which would require a go/don?t-go decision by 5/28.
 
Can we assume that we will be meeting at IETF87?   It appears from the 
discussion so far that we will have lots of things to discuss, but I?d 
like to be sure about our plans to meet before I start making plans to 
travel.
 
From: [email-masked] [mailto:[email-masked]] On Behalf Of 
Spencer Shepler
Sent: Tuesday, May 14, 2013 2:54 PM
To: [email-masked]
Subject: [nfsv4] Soliciting Agenda items for IETF 87 NFSv4 working group 
meeting

Given that June 3rd is a Monday, please attempt to submit your agenda 
items by May 31st to allow for roll-up, etc.
 
Spencer

---

From: "Matt W. Benjamin" <[email-masked]>
Date: Fri, 17 May 2013 15:36:29 -0400 (EDT)

I think this would be very interesting.

----- "Marc Eshel" <[email-masked]> wrote:

> I would like to add a 20 minutes presentation to the agenda to propose
> a more coherent data caching for NFS.
> 
> The objective of this presentation will be to talk about how to
> improve NFS client caching for NFS4.3. I would like to find out from
> the group if one, others see this as a useful objective, and two, if
> extending the delegations feature is the right approach. I will post
> another email with more detail for post meeting discussion.
> Marc.
> 
> 
> 
> From: Noveck, David [ mailto:[email-masked] ]

http://linuxbox.com

tel.  734-761-4689 
fax.  734-769-8938 
cel.  734-216-5309

---

From: Marc Eshel <[email-masked]>
Date: Fri, 17 May 2013 17:21:31 -0700

I meant to say, I will send an email to the list soon for pre-meeting 
discussion.
Marc.

"Matt W. Benjamin" <[email-masked]> wrote on 05/17/2013 12:36:29 PM:

> From: "Matt W. Benjamin" <[email-masked]>
> To: Marc Eshel/Almaden/IBM@IBMUS, 
> Cc: [email-masked], [email-masked], Spencer Shepler 
> <[email-masked]>
> Date: 05/17/2013 12:38 PM
> > needed. This doesn?t need to be to the entire list but can be.
> > 
> > Spencer
> > 
> > We?ve had previous discussion about people?s need to schedule their
> > travel plan?s early enough to accommodate corporate travel approval
> > months before the meeting for this, which would require a go/don?t-go
> > decision by 5/28.
> >

---

From: Spencer Shepler <[email-masked]>
Date: Sat, 18 May 2013 00:41:16 +0000

I have this on the list, Marc.

Spencer

From: Marc Eshel [mailto:[email-masked]]
Sent: Friday, May 17, 2013 5:22 PM
To: Matt W. Benjamin
Cc: [email-masked]; [email-masked]; Spencer Shepler
Subject: Re: [nfsv4] Soliciting Agenda items for IETF 87 NFSv4 working group meeting

I meant to say, I will send an email to the list soon for pre-meeting discussion.
Marc.

"Matt W. Benjamin" <[email-masked]<mailto:[email-masked]>> wrote on 05/17/2013 12:36:29 PM:

> From: "Matt W. Benjamin" <[email-masked]<mailto:[email-masked]>>
> Cc: [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>, Spencer Shepler
> <[email-masked]<mailto:[email-masked]>>
> ----- "Marc Eshel" <[email-masked]<mailto:[email-masked]>> wrote:
>
> > From: Spencer Shepler <[email-masked]<mailto:[email-masked]>>
> > To: "Noveck, David" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>"
> > <[email-masked]<mailto:[email-masked]>>,
> > Sent by: [email-masked]<mailto:[email-masked]>
> >
> >
> >
> >
> >
> > David,
> >
> > needed. This doesn't need to be to the entire list but can be.
> >
> > Spencer
> >
> > We've had previous discussion about people's need to schedule their
> > travel plan's early enough to accommodate corporate travel approval
> > months before the meeting for this, which would require a go/don't-go
> > decision by 5/28.
> >
> > discussion so far that we will have lots of things to discuss, but I'd
> > From: [email-masked]<mailto:[email-masked]> [ mailto:[email-masked] ] On
> http://linuxbox.com<http://linuxbox.com/>
>
> tel.  734-761-4689
> fax.  734-769-8938
> cel.  734-216-5309
>

---

From: David Quigley <[email-masked]>
Date: Wed, 22 May 2013 14:56:17 -0400

On 05/15/2013 13:51, Noveck, David wrote:
> Maybe I'm using an automatic weapon on a dead horse here, but …
>
> I don't believe that the fact that that there nobody able and willing
> Ultimately we cannot avoid at least a small amount of work in the
> base protocol. As it now seems that mention of v4.3 "ist streng
> verboten" let me note that the basic problem is that currently 
> layouts
> are optional and can always be recalled. So it seems that some future
> minor version would have to provide a way of dealing with this issue.
> Some possibilities:
>
> FROM: Spencer Shepler [mailto:[email-masked]]
> SENT: Wednesday, May 15, 2013 11:53 AM
> TO: Chuck Lever
> CC: Noveck, David; [email-masked]
> SUBJECT: RE: [nfsv4] Soliciting Agenda items for IETF 87 NFSv4
> working group meeting
>
> Chuck,
>
> - T10 mechanism are identified as one method to build upon; would be
> More generally, this functionality seems well aligned to a simple,
> new pNFS layout type that would let the client opt-in for the support
> and let the server control things like migration or change in
> integrity type while the file is open. Using a pNFS layout could
> introduce new operations in support of integrity and would provide a
> timeline outside of a general minor version update. Just a thought -
> at a minimum, this could be used for prototyping and deployment.
>
> Spencer
>
> FROM: Chuck Lever [mailto:[email-masked]]
> SENT: Wednesday, May 15, 2013 7:32 AM
> TO: Spencer Shepler
> CC: Noveck, David; [email-masked]
> SUBJECT: Re: [nfsv4] Soliciting Agenda items for IETF 87 NFSv4
> working group meeting
>

I can say 100% that I have interest in RPCSECGSS_V3 the only problem is 
I'm not paid anymore to do any work on NFSv4. Any work I do in this 
space is 100% on my own time and my time is becoming increasingly 
scarce. Within the next couple months it will hopefully become almost 
non-existent but for good reasons. I will be glad to read the document 
and give feedback as necessary but I can't commit at all to any 
engineering effort on my part. I have code and if people want to analyze 
it and see if it matches the spec all the better. I know Bruce asked to 
see the code and I have unfortunately not had a chance to send it out 
yet but if anyone at any of the storage vendors want this to happen 
putting together a small group of engineers might be worth the money to 
get it done.

Dave

---

From: "Noveck, David" <[email-masked]>
Date: Wed, 29 May 2013 12:15:17 -0400

> If the agenda fills out before 5/28, then we can make the call earlier.  So 5/28 is the
>"the decision will be made no later than" date.

Given that it is now later than the abovementioned "the decision will be made no later than" date, what is Spencer's decision regarding requesting a meeting slot at IETF87?

I am confused because:

*         I haven't seen any decision announced, although it is possible that I have missed it.

*         It seems to me that there is plenty to discuss and we could have a productive face-to-face discussion in Berlin, making the apparent lack of any announcement even harder to understand.

From: Spencer Shepler [mailto:[email-masked]]
Sent: Wednesday, May 15, 2013 1:12 PM
To: Noveck, David; [email-masked]
Subject: RE: [nfsv4] Soliciting Agenda items for IETF 87 NFSv4 working group meeting

Spencer

David,

Spencer

Spencer

---

From: Spencer Shepler <[email-masked]>
Date: Wed, 29 May 2013 16:18:03 +0000

Sorry for the delay, David.  See my other thread that is working to close on the agenda.

Spencer

From: Noveck, David [mailto:[email-masked]]
Sent: Wednesday, May 29, 2013 9:15 AM
To: Spencer Shepler; [email-masked]
Cc: Martin Stiemerling ([email-masked]); [email-masked]
Subject: RE: [nfsv4] Soliciting Agenda items for IETF 87 NFSv4 working group meeting

I am confused because:

Spencer

David,

Spencer

Spencer