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

["Noveck, Dave" <[e-mail]>]

> 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.

I'd been assuming that this would happen, although as you indicate,
the actual decision will probably be made in Dallas.  

> Of course, these are
> tiny changes to semantics that still have to be described in the 
> 4.1 document words.

I think we need to take what's in the two drafts (working group 
document for referrals, section 2.* of draft-noveck-nfsv4-migrep-00)
and use it to update the v4.1 draft.  While there will be an 
opportunity to review that stuff after it is incorporated into the
v4.1 draft, I think that the more review we get of this material 
before that happens, the smoother things will go.  So keep those 
cards and letters coming folks.

My view of the required drafting work for referrals is that beyond
the detail work that you mention, the bigger job is drafting of
a replacement for RFC3530 chapter 6, as a whole.  I think that 
with referrals and the other implementation work that has been done,
our understanding of this area has changed quite a bit and the best way
to proceed is to draft a new chapter that reflects our understanding
today, taking and modifying material as needed from the existing 
chapter 6 of RFC3530.  

Unless Spencer wants to fight me over it, I was thinking of trying
to get started on that pretty soon.  What has been holding me up is 
the issue of deciding what we want to do about location_info, which 
you mention below.  That's another thing that needs to be addressed 
in Dallas.

> 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 think we have a situation where migration and replication failover
implementation has lagged, but now that implementation is proceeding, 
we are seeing some of the weaknesses of what is in RFC3530.  In 
many cases, it is not that what is in RFC3530 being totally unusable,
but rather that handling is much less effective than one would like.  
One example is the loss by the client of any valid change attribute 
information (since this is server-specific) when shifting from server 
to server.  Having the client always reget this information can be 
done, but doing so when you really don't need to is a problem.  Having 
more information on alternate locations can prevent that, as well
as support more intelligent location selcction.

> 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.

I think this probably would be useful.

I think we should come out of the Dallas meeting with at least 
provisional answers to the following three questions:

     Should we pursue the new attributes in section 3.* of 
     draft-noveck-nfsv4-migrep-00.txt for v4.1?

     If so, what needs to be deleted?

     If so, what needs to be added?

I'm also looking for detailed review, corrections, clarifications, 
but as we go look toward next week's meetings, I think we need to
focus on answering those three questions, in order to enable the 
drafting work on the referral/replication/migration portion of 
the v4.1 spec to proceed.







-----Original Message-----
From: Everhart, Craig 
Sent: Thursday, March 16, 2006 6:15 PM
To: Noveck, Dave; [e-mail]
Subject: RE: [nfsv4] Migration, replication, referral items for v4.1


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: [e-mail]
> 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:
>  
>      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
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/nfsv4
> 

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