Re: [nfsv4] FedFS: Comment about fedfsFslPort

[James Lentini <[e-mail]>]

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. 

   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

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