Re: [nfsv4] I-D Action:draft-ietf-nfsv4-ipv4v6-00.txt

>} Date: Mon, 18 Oct 2010 22:45:56 -0500
>} From: Thomas Haynes <thomas@netapp.com>
>} To: Trond Myklebust <trond.myklebust@fys.uio.no>
>} Cc: nfsv4@ietf.org, Nicolas Williams <Nicolas.Williams@oracle.com>
>} Subject: Re: [nfsv4] I-D Action:draft-ietf-nfsv4-ipv4v6-00.txt
>} 
>} 
>} On Oct 18, 2010, at 3:28 PM, Trond Myklebust wrote:
>} 
>} > On Mon, 2010-10-18 at 15:19 -0500, Nicolas Williams wrote:
>} >> On Mon, Oct 18, 2010 at 02:28:05PM -0500, Thomas Haynes wrote:
>} >>> Minor nits:
>} >> 
>} >>> Finally, it is understated, so I think you should bring more attention
>} >>> to it, but the problem you deal with in Section 6 applies to symmetric
>} >>> single stack mode topologies as well. I.e., all current multi-homed
>} >>> IPv4 deployments.
>} >> 
>} >> Yes.  This should be solved in NFSv4.2 if at all possible.  Some
>} >> suggestions for how to solve this problem:
>} >> 
>} >> - have an operation by which the server can list its IP addresses to
>} >>   the client
>} >> 
>} >> - have a server UUID
>} >> 
>} >> - both of the above, so that clients could ID servers by {server-
>} >>   address-list, server-UUID}, which is bound to be unique for all
>} >>   servers, even when private addresses overlap.
>} >> 
>} >>   If two servers claim to speak NFS on {1.2.3.4, 10.20.30.40} and
>} >>   {1.2.3.5, 10.20.30.40} respectively, then they are necessarily
>} >>   different servers, even if they should both happen to claim the same
>} >>   UUID.  The servers might use 10.20.30.40 on distinct subnets for
>} >>   backup purposes.
>} >> 
>} >> This would improve server multi-homing support in NFSv4.  Clients could
>} >> avoid creating same-client conflicts by referring to the same server via
>} >> different addresses.
>} > 
>} > As I said earlier, this too is a problem that was supposed to be
>} > resolved by the introduction of EXCHANGE_ID in NFSv4.1. So what is the
>} > hole in the current spec that causes the multi-homed server issue to be
>} > broken?
>} > 
>} > Trond
>} > 
>} 
>} Trond,
>} 
>} Sorry, I was just reacting to the presentation in the draft. But that raises
>} another question, why doesn't the draft address NFSv4.1 and EXCHANGE_ID?

Our focus in the draft was problems we faced when doing our implementation 
- which covered NFSv3 and v4.  And how to solve those problems for v3 and 
v4.  If any of the problems have been solved in v4.1, those can be noted 
as such, but solutions for v3 and v4 would still be useful, we think.

thanks,

-{db}.


>} 
>} Tom
>} 
>} _______________________________________________
>} nfsv4 mailing list
>} nfsv4@ietf.org
>} https://www.ietf.org/mailman/listinfo/nfsv4
>} 
>}