Re: [nfsv4] FedFS: Comment about fedfsFslPort

[Chuck Lever <[e-mail]>]

On Oct 20, 2011, at 12:37 PM, James Lentini wrote:

> 
> I understand your concern now. Point taken: when an FSL contain a DNS 
> name and port number, NFS does not allow the DNS name and port pair to 
> be included in a referral.
> 
> I think there are two separate issues here: (a) what is the format of 
> server's name in an NFS referral? and (b) how does a FedFS fileserver 
> populate a referral's server name from an FSL that includes more 
> information than the referral format supports? One example of (b) is 
> the case we've been discussing of a DNS name and port, but there are 
> others.
> 
> With regards to (a), the specifications define different formats for 
> the server's name.
> 
> NFSv4.0 (RFC 3530) states that the server's name in an fs_locations 
> referral is either a DNS name or IP address, but NO port. The relevant 
> text from page 60:
> 
>   An entry in the server array is an UTF8 string and represents one 
>   of a traditional DNS host name, IPv4 address, or IPv6 address
> 
> NFSv4.0bis (draft-ietf-nfsv4-rfc3530bis-15) matches NFSv4.0. It states 
> that the server's name in an fs_locations referral can be a DNS name 
> or IP address with NO port. The relevant text from page 97:
> 
>   An entry in the server array is a UTF-8 string and represents one 
>   of a traditional DNS host name, IPv4 address, IPv6 address, or an 
>   zero-length string.  A zero-length string SHOULD be used to 
>   indicate the current address being used for the RPC call.
> 
> NFSv4.1 (RFC 5661) states that the server's name in an fs_locations 
> can be a DNS name or IP address with optional port. The relevant text 
> from page 258:
> 
>   An entry in the server array is a UTF-8 string and represents one 
>   of a traditional DNS host name, IPv4 address, IPv6 address, or a 
>   zero-length string.  An IPv4 or IPv6 address is represented as a 
>   universal address (see Section 3.3.9 and [15]), minus the netid, 
>   and either with or without the trailing ".p1.p2" suffix that 
>   represents the port number.  If the suffix is omitted, then the 
>   default port, 2049, SHOULD be assumed.  A zero-length string SHOULD 
>   be used to indicate the current address being used for the RPC 
>   call.
> 
> When read literally, NFSv4.1 prescribes a more restrictive server name 
> for the more descriptive fs_locations_info referral. That's 
> counter-intuitive to me. RFC 5661 states that the server name in a 
> fs_locations_info referral can ONLY contain an IP address and optional 
> port (no DNS name). The relevant text from page 265:
> 
>   o  The server string (fls_server).  For the case of the replica
>      currently being accessed (via GETATTR), a zero-length string MAY
>      be used to indicate the current address being used for the RPC
>      call.  The fls_server field can also be an IPv4 or IPv6 address,
>      formatted the same way as an IPv4 or IPv6 address in the "server"
>      field of the fs_location4 data type (see Section 11.9).
> 
> NFSv4.2 (draft-ietf-nfsv4-minorversion2-05) uses the same formats at 
> NFSv4.1.
> 
> My summary of a referral's server format is:
> 
>           | fs_locations                    | fs_locations_info
> --------------------------------------------------------------------
> NFSv4.0    | DNS name, IP                    | N/A
> ---------------------------------------------------------------------
> NFSv4.0bis | DNS name, IP                    | N/A
> --------------------------------------------------------------------
> NFSv4.1    | DNS name, IP (w/ optional port) | IP (w/ optional port)
> --------------------------------------------------------------------
> NFSv4.2    | DNS name, IP (w/ optional port) | IP (w/ optional port)
> 
> Note that some of these formats do not support all of the information 
> in an NFS FSL.
> 
> With regards to question (b), there are at least the following 
> approaches to dealing with the problem of populating a referral's 
> server name from an FSL that includes more information than the 
> referral format supports:
> 
> 1. The fileserver could follow the advice given in Section 2.8.3 of 
>   draft-ietf-nfsv4-federated-fs-protocol-11 on "Generating A Referral 
>   from Fileset Locations" and "convert or reduce the FSL record's 
>   contents in a manner appropriate to the referral format". 
> 
>   I'd classify translating the DNS name to an IP address when an FSL 
>   contains both a DNS name and port as an example of a conversion. As 
>   you've noted below, there are drawbacks to this approach.
> 
>   My approach would have been to drop the port and return the 
>   DNS name unaltered in referral types that don't support both a DNS 
>   name and port.
> 
>   Given that we pictured different approaches to the conversion 
>   problem is a bad sign.
> 
> 2. Define the NFS FSL's server name format to exactly match the NFS 
>   referral format as you've proposed below. That is appealing, but 
>   as you can see from my summary above, there isn't a single common 
>   format. 

Very recently Tom Haynes proposed (on this list) updating 3530bis to allow a universal address with port to be used in fs_locations4.  See:

  http://www.ietf.org/mail-archive/web/nfsv4/current/msg10307.html

and a few subsequent comments on this from me.

>   The format could be the lowest common denominator (only IP 
>   addresses with no port are allowed across all the different 
>   referral formats), but the loss of expressivity would be 
>   disappointing.
> 
> Here's a strawman proposal for how to address these issues:
> 
> - Remove the fedfsFslPort from the fedfsFsl object
> 
> - Define a new fedfsNfsFslPort type with the same format as the 
>  fedfsFslPort and add it to the fedfsNfsFsl object 
> 
> - Remove the fedfsFslHost from the fedfsFsl object 
> 
> - Define a new fedfsFslNfsHost type with the same format as the 
>  current fedfsFslHost and add it to to the fedfsNfsFsl object
> 
> - Explicitly define the conversion rules for all of the combinations 
>  of fedfsNfsFslHost and fedfsNfsFslPort with NFS referral types

This is going in the right direction, in my opinion.  But I think we can define fedfsFslNfsHost to contain universal addresses with port numbers and leave off fedfsNfsFslPort, if 3530bis allows universal addresses in the fls_server field.

In the event we can't put a universal address with a port into fedfsNfsFslHost, I'm not comfortable with simply "dropping the port number" for fs_locations4.  During a referral or migration, a 3530(nonbis)-compliant client won't ever be able to connect to a server that uses a port other than 2049.  Such records would therefore be useless to the client.  Thus perhaps it would be better to have the server simply drop such records entirely for NFSv4.0?

> Opinions?
> 
> Sorry for the wordy email,
> -james
> 
> On Thu, 20 Oct 2011, Chuck Lever wrote:
> 
>> Hi James-
>> 
>> On Oct 20, 2011, at 7:17 AM, James Lentini wrote:
>> 
>>> 
>>> 
>>> On Wed, 19 Oct 2011, Chuck Lever wrote:
>>> 
>>>> 
>>>> On Oct 19, 2011, at 12:10 PM, Chuck Lever wrote:
>>>> 
>>>>> 
>>>>> On Oct 19, 2011, at 11:54 AM, James Lentini wrote:
>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On Wed, 12 Oct 2011, Robert Thurlow wrote:
>>>>>> 
>>>>>>> Chuck Lever wrote:
>>>>>>> 
>>>>>>>> Thus there's no need for a separate FSL field to express a port value for
>>>>>>>> NFS referrals.  Regardless of whether 3530bis is changed as proposed, I
>>>>>>>> think we should remove the fedfsFslPort field, and leave that detail to the
>>>>>>>> subclasses of fedfsFsl where it is meaningful.
>>>>>>> 
>>>>>>> Agreed.
>>>>>> 
>>>>>> Removing the optional fedfsFslPort attribute from the fedfsFsl 
>>>>>> objectclass makes sense to me. Subclasses of fedfsFsl should include a 
>>>>>> port when necessary.
>>>>>> 
>>>>>> However, I believe that an NFS FSL should include a port attribute.
>>>>>> 
>>>>>> As defined in RFC 5661, NFSv4.1 allows for modified universal 
>>>>>> addresses to be included in a referral (see RFC 5661's definition of 
>>>>>> the fls_server field in Section 11.10.1).
>>>>>> 
>>>>>> As defined in Section 4.2.1.2 of 
>>>>>> draft-ietf-nfsv4-federated-fs-protocol-11, the format of the 
>>>>>> fedfsFslHost attribute does not allow universal addresses or port 
>>>>>> values to be specified.
>>>>>> 
>>>>>> The combination of a fedfsFslHost and fedfsFslPort (renamed to be a 
>>>>>> fedfsNfsFslPort?) provide enough information to generate the modified 
>>>>>> universal addresses used in NFSv4.1 referrals.
>>>>> 
>>>>> My concern about this is that now the file server would have to 
>>>>> perform a DNS lookup to discover the address that is bound to the 
>>>>> fedfsFslHost.  Can we guarantee that the client would get the same 
>>>>> results from a DNS lookup, given that hostname?  Does that matter?
>>>> 
>>>> I'll go a little further here, based on recent implementation 
>>>> experience.
>>>> 
>>>> The intent as I understand it is that an NFS FSL stores information 
>>>> that the file server translates to either fs_locations4 or 
>>>> fs_locations_info4.  The challenge of this translation has been 
>>>> dealing with information in an NFS FSL that is stored differently or 
>>>> is semantically different than what's in fs_locations{_info}4.
>>>> 
>>>> This includes not just fedfsFslPort.  fs_locations4, for instance 
>>>> has the possibility of transmitting a list of servernames that share 
>>>> the same export path.  The NFS FSL, however, stores a single server 
>>>> name and a single export path.
>>>> 
>>>> And before you mentioned it today, I didn't realize that 
>>>> fedfsFslHost could express only a DNS hostname, and not IP or 
>>>> universal addresses.  /me slaps forehead.  
>>> 
>>> Actually a fedfsFslHost can store a DNS name, IPv4 address, or IPv6 
>>> address.
>>> 
>>> The fedfsFslHost attribute's format is defined by its superior 
>>> attribute's format, the fedfsNetAddr, which "is the locative name of a 
>>> network service in either IPv4, IPv6, or DNS name notation. See 
>>> section 4.2.1.2 of draft-ietf-nfsv4-federated-fs-protocol-11 for the 
>>> full definition.
>> 
>> Got it.
>> 
>>>> This is another translation complication for file server 
>>>> implementors.  IMO we would be better off if NFS FSLs were a closer 
>>>> match to fs_locations{_info}4.
>>> 
>>> I don't see any need to do a translation.
>> 
>> Your proposal adds a new translation requirement by specifying the 
>> FslPort in a separate field, and requiring that the file server 
>> perform a DNS lookup to construct a universal address in order to 
>> communicate the port number to clients.  (Understood that this would 
>> only be necessary if FslPort contains a port number other than 
>> 2049).  The natural way to express server names for NFS, codified in 
>> RFC 5661, includes a universal address, and the server name data can 
>> be multi-valued.
>> 
>> My quibble is not with the richness of the NFS FSL, but rather that 
>> this information is expressed in a particular way in existing NFS 
>> implementations, and we are not providing the same way to express it 
>> in FedFS.  Is there a strong reason for this?  Are we for instance 
>> trying to address some deficiency in the fs_locations_info4 data?
>> 
>> I continue to believe the FSL subclasses, on principal, should 
>> reflect the data and types in native file system referral 
>> information as closely as possible, and currently the NFS FSL does 
>> not.  The file server may _choose_ to implement some dynamic policy 
>> with this data, but I don't think it should be limited to that: it 
>> should also be allowed to simply copy the information from the NFS 
>> FSL and stuff it into the fs_locations_info4 struct, in all cases.  
>> That would be the least surprising/confusing behavior to admins.
>> 
>> I'm willing to concede on the multi-valued server name point, as an 
>> FSL is supposed to represent a single location.  Noted, however, 
>> that a file server MAY convert multiple FSLs that vary only in their 
>> server name field by compressing this FSL list to a single 
>> fs_locations_info4 record with a list of server names.  Right?  Are 
>> there exceptions?
>> 
>>>> As an example, we could also move fedfsFslHost to the NFS FSL, and 
>>>> allow the NFS version of this attribute to be multi-valued and 
>>>> contain the full range of string values that are allowed in the 
>>>> fls_server field in fs_locations_info4.  I think that would be more 
>>>> natural for administrators who have already set up NFS referrals 
>>>> using other administrative interfaces native to their platform.
>>>> 
>>>> More generally, I don't think we should assume that the data in 
>>>> "FslHost" will be the same type for every network file system, and 
>>>> that this information, therefore, is also specific to subclasses of 
>>>> fedfsFsl.
>> 
>> --
>> Chuck Lever
>> chuck[dot]lever[at]oracle[dot]com
>> 
>> 
>> 
>> 

--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com