Re: [nfsv4] FedFS: Comment about fedfsFslPort

[James Lentini <[e-mail]>]

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.

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

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