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

dhawal bhagwat <dhawal@netapp.com> Wed, 27 October 2010 21:56 UTC

Return-Path: <Dhawal.Bhagwat@netapp.com>
X-Original-To: nfsv4@core3.amsl.com
Delivered-To: nfsv4@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30B1E3A67F7 for <nfsv4@core3.amsl.com>; Wed, 27 Oct 2010 14:56:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.186
X-Spam-Level:
X-Spam-Status: No, score=-9.186 tagged_above=-999 required=5 tests=[AWL=1.413, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 54Lilxn6hUUu for <nfsv4@core3.amsl.com>; Wed, 27 Oct 2010 14:56:54 -0700 (PDT)
Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by core3.amsl.com (Postfix) with ESMTP id 0AEE43A67ED for <nfsv4@ietf.org>; Wed, 27 Oct 2010 14:56:53 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.58,248,1286175600"; d="scan'208";a="473926641"
Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 27 Oct 2010 14:58:44 -0700
Received: from sacrsexc2-prd.hq.netapp.com (sacrsexc2-prd.hq.netapp.com [10.99.115.28]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id o9RLwiWB023088; Wed, 27 Oct 2010 14:58:44 -0700 (PDT)
Received: from btcrsexc1-prd.hq.netapp.com ([10.73.251.109]) by sacrsexc2-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 Oct 2010 14:58:44 -0700
Received: from BTCMVEXC1-PRD.hq.netapp.com ([10.73.251.107]) by btcrsexc1-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 28 Oct 2010 03:28:39 +0530
Received: from cyclnb08.eng.btc.netapp.in ([10.72.8.58]) by BTCMVEXC1-PRD.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 28 Oct 2010 03:28:39 +0530
Date: Thu, 28 Oct 2010 03:28:35 +0530
From: dhawal bhagwat <dhawal@netapp.com>
To: Trond Myklebust <trond.myklebust@fys.uio.no>
In-Reply-To: <1287431593.3646.23.camel@heimdal.trondhjem.org>
Message-ID: <alpine.LRH.2.00.1010280220330.11213@plpyao08.rat.ogp.argncc.va>
References: <20101018174520.EB8BA3A6B8B@core3.amsl.com> <C9B236F2-1F42-4070-A083-1A776B5C9C92@netapp.com> <1287431593.3646.23.camel@heimdal.trondhjem.org>
User-Agent: Alpine 2.00 (LRH 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
X-OriginalArrivalTime: 27 Oct 2010 21:58:39.0220 (UTC) FILETIME=[1CAC2340:01CB7622]
Cc: nfsv4@ietf.org
Subject: Re: [nfsv4] I-D Action:draft-ietf-nfsv4-ipv4v6-00.txt
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nfsv4>
List-Post: <mailto:nfsv4@ietf.org>
List-Help: <mailto:nfsv4-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Oct 2010 21:56:56 -0000

>} Date: Mon, 18 Oct 2010 15:53:13 -0400
>} From: Trond Myklebust <trond.myklebust@fys.uio.no>
>} To: Thomas Haynes <thomas@netapp.com>
>} Cc: nfsv4@ietf.org
>} Subject: Re: [nfsv4] I-D Action:draft-ietf-nfsv4-ipv4v6-00.txt
>} 
>} On Mon, 2010-10-18 at 14:28 -0500, Thomas Haynes wrote:
>} 
>} > 
>} > A larger question on the draft as a whole would be whether we could
>} > add some
>} > additional operations to NFSv4.2 to get rid of the guessing. I.e.,
>} > could a client
>} > send a server a list of IPv4 and IPv6 addresses that it is using and
>} > in return the
>} > server respond with the equivalence addresses that it is using?
>} > 
>} 
>} Why does the server need this information? The NFSv4.1 protocol does not
>} provide for server-initiated callbacks. All communication channels (i.e.
>} TCP connections) are initiated by the client in NFSv4.1.
>} 
>} Furthermore, EXCHANGE_ID already provides a mechanism to allow the
>} client to discover that 2 IP addresses point to the same server. This
>} mechanism even works independently of the actual transport mechanism
>} used, so it will work with RDMA and other possible future transport
>} mechanisms too.
>} 
>} > One issue I can see is that the machines might be on different subnets
>} > that use the
>} > same IP addresses. I.e., 192.168.2.14 on the filer's e0a might be a
>} > different private subnet
>} > than the 192.168.2.15 on the client's e1.
>} 
>} This is why relying on advertising of private nets via RPCBIND is bad.

Is this for RPCBIND to worry about?  Shouldn't setups like the one 
described above be separated into different IP spaces?  Within the same IP 
space, the above I believe is a incorrect network config -- how would 
hosts in one of those subnets, route to those in the other subnet?

If private subnets are properly configured, will there be a problem with 
RPCBIND advertising private addresses?

For IPv6 however, there is the issue of RPCBIND advertising IPv6 
link local addresses across links -- that is for RPCBIND to explicitly 
take care of.  We have talked of this issue in the other draft 
(draft-ietf-nfsv4-ipv6-00.txt).

thanks,

-{db}.


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