Subject: [nfsv4] Migration, replication, referral items for v4.1

From: "Noveck, Dave" <[email-masked]>
Date: Tue, 7 Mar 2006 09:06:22 -0500

This note discusses potential v4.1 work items in the areas of migration,
replication, and referral.  These items all derive from the following
documents:
 
     draft-ietf-nfsv4-referrals-00, which is a working group document.  
     This document supplements RFC3530 by explicitly discussing 
     referrals and how they work in NFSv4.   This document also 
     addresses a number of ambiguities and contradictions of the 
     treatment of migration and replication in RFC3530, as they relate 
     to referrals. 
 
     draft-noveck-nfsv4-migrep-00 , which is a recent individual draft 
     by Carl Burnett and me.  This document consists (beyond the 
     introduction) of three sections, each of which will be dealt with 
     separately below.
 
The referrals document has gone through a number of revisions and there
doesn't seem to have been any recent controversy about it.  There has
been implementation work based on it.  I think it is appropriate to fold
this work into the new v4.1 spec.  Is there anyone who knows of any 
remaining issues with regards to this material?
 
The first of the sections in the new individual draft deals with some
similar issues of ambiguities and contradictions in RFC3530.  These 
are not limited to things related to referrals as in the working group
document.  My expectation is that this material which attempts to 
clarify ambiguities and contradictions should go into v4.1 on the same
basis as the referrals material.  I'd like to ask people to look at the
the first section of the individual draft so that we can resolve any
issues that people have going forward and start drafting a new chapter
on migration, replication and referrals, for the v4.1 spec.
 
The second section concerns some additional recommended attributes
related to migration and replication.  The purpose of these is to give
the client more information about the various possible sources for a
given filesystem, including more information about server preferences to
guide client choice of replicas, and information about the continuity of
(or lack thereof) of metadata between various pairs of replicas.  Some
of this includes support which allow multiple replicas to serve data
concurrently rather serially, allowing multipathing and clustered
(metadata) fs support.  
 
So I think that for this material we need to decide whether v4.1 is the
appropriate vehicle, or whether we want to defer this.  It is also 
possible that we might want to do some subset in v4.1 and defer others.
I know there are people who want various parts of this but we need to
have the discussion about whether this belongs in v4.1.  I think the 
decision will turn on whether there is sufficient interest in building
implementations, as opposed to people merely thinking it is a good idea,
or even worse, an "interesting" one.
 
The third part of the individual draft deals with ideas toward an
alternate
approach to a heterogeneous migration protocol.  The response has been
pretty lukewarm and in any case, this material is not a candidate for
inclusion in v4.1. 
 
I'd like to get the required discussion as soon as we can.  I think
there
is a non-trivial amount of work in drafting a new chapter to replace
chapter 6 in RFC 3530 and that work can't proceed very far until we
get to consensus about what is and isn't going to be in v4.1 as far as
this area goes.

Maybe we should schedule some time for discussion of these issues in 
Dallas. 

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

---

From: "Everhart, Craig" <[email-masked]>
Date: Thu, 16 Mar 2006 18:15:07 -0500

I have to think that next week's meetings should just move on the words
about referrals, refining the specifications.  This includes section 2.*
of draft-noveck-nfsv4-migrep-00.  Of course, these are
tiny changes to semantics that still have to be described in the 4.1
document words.

The location4_info structure is also quite useful.  NFS clients have had
to do a lot of guessing, and falling back to least-common-denominator
semantics for failover events.

I would like to see the fs4_status field (section 3.2.4) extended to
include another definition of currency (call it a "fs4_status.age"
field), which is an indication of how out-of-date the filesystem
currently is with respect to its  ultimate data source (in case of
cascading data updates).  This complements the location4_server.currency
(section 3.2.2, page 19) information in the following way:
location4_server.currency can offer a bound for how out of date the data
in a file system might typically get, and this hypothetical
fs4_status.age would give a bound on how out of date that data actually
is.  Like location4_server.currency, it could be an int32_t.  Negative
values imply no information given; a zero means that this data is known
current; a positive value means that this data is known to be no older
than fs4_status.age seconds with respect to the ultimate data source.

		Craig

> -----Original Message-----
> From: Noveck, Dave 
> Sent: Tuesday, March 07, 2006 9:06 AM
> To: [email-masked]
> Subject: [nfsv4] Migration, replication, referral items for v4.1
> 
> This note discusses potential v4.1 work items in the areas of 
> migration, replication, and referral.  These items all derive 
> from the following
> documents:
>  
> The referrals document has gone through a number of revisions 
> and there doesn't seem to have been any recent controversy 
> about it.  There has been implementation work based on it.  I 
> think it is appropriate to fold this work into the new v4.1 
> spec.  Is there anyone who knows of any remaining issues with 
> regards to this material?
>  
> The first of the sections in the new individual draft deals 
> with some similar issues of ambiguities and contradictions in 
> RFC3530.  These are not limited to things related to 
> referrals as in the working group document.  My expectation 
> is that this material which attempts to clarify ambiguities 
> and contradictions should go into v4.1 on the same basis as 
> the referrals material.  I'd like to ask people to look at 
> the the first section of the individual draft so that we can 
> resolve any issues that people have going forward and start 
> drafting a new chapter on migration, replication and 
> referrals, for the v4.1 spec.
>  
> The second section concerns some additional recommended 
> attributes related to migration and replication.  The purpose 
> of these is to give the client more information about the 
> various possible sources for a given filesystem, including 
> more information about server preferences to guide client 
> choice of replicas, and information about the continuity of 
> (or lack thereof) of metadata between various pairs of 
> replicas.  Some of this includes support which allow multiple 
> replicas to serve data concurrently rather serially, allowing 
> multipathing and clustered
> (metadata) fs support.  
>  
> So I think that for this material we need to decide whether 
> v4.1 is the appropriate vehicle, or whether we want to defer 
> this.  It is also possible that we might want to do some 
> subset in v4.1 and defer others.
> I know there are people who want various parts of this but we 
> need to have the discussion about whether this belongs in 
> v4.1.  I think the decision will turn on whether there is 
> sufficient interest in building implementations, as opposed 
> to people merely thinking it is a good idea, or even worse, 
> an "interesting" one.
>  
> The third part of the individual draft deals with ideas 
> toward an alternate approach to a heterogeneous migration 
> protocol.  The response has been pretty lukewarm and in any 
> case, this material is not a candidate for inclusion in v4.1. 
>  
> I'd like to get the required discussion as soon as we can.  I 
> think there is a non-trivial amount of work in drafting a new 
> chapter to replace chapter 6 in RFC 3530 and that work can't 
> proceed very far until we get to consensus about what is and 
> isn't going to be in v4.1 as far as this area goes.
> 
> Maybe we should schedule some time for discussion of these 
> issues in Dallas. 
> 
>  
>