Re: [nfsv4] FedFS: Comment about fedfsFslPort

[James Lentini <[e-mail]>]

As I just mentioned in a follow up with Chuck, there should be no 
reason to do a translation of a DNS name.

On the subject of generating referrals from FSL records, draft 
draft-ietf-nfsv4-federated-fs-protocol-11 provides advice on this 
topic in section 2.8.3.

On Wed, 19 Oct 2011, Spencer Shepler wrote:

> 
> Not sure my perception is accurate but having a hostname specified
> and allowing the server to do the translation for the client via
> the location attributes could be an advantage (or danger).
> The server's physical interfaces may be changing dynamically
> and having to update the FSL contents based on that seems unlikely.
> 
> Allowing the server to apply a policy of sorts when the translation
> of hostname to locations list may be more resilient and provide
> less administrative overhead.
> 
> Spencer
> 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On Behalf Of
> > Chuck Lever
> > Sent: Wednesday, October 19, 2011 1:56 PM
> > To: James Lentini
> > Cc: Robert Thurlow; [e-mail]
> > Subject: Re: [nfsv4] FedFS: Comment about fedfsFslPort
> > 
> > 
> > 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.  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.
> > 
> > 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.
> > 
> > Thoughts?
> > 
> > --
> > Chuck Lever
> > chuck[dot]lever[at]oracle[dot]com
> > 
> > 
> > 
> > _______________________________________________
> > nfsv4 mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/nfsv4
> 
>