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

[Thomas Haynes <[e-mail]>]

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?

Tom