Subject: [nfsv4] FedFS: Comment about fedfsFslPort

From: Chuck Lever <[email-masked]>
Date: Mon, 3 Oct 2011 12:22:17 -0400

A FedFS FSL record, which stores location information about one replica of a fileset, has an optional attribute called "fedfsFslPort".  This attribute records the IP port number of the file server that contains this replica.  See section 4.2.1.10 of the NSDB protocol draft.

When an NFS file server resolves a junction, it converts FSL records to an fs_locations or fs_locations_info attribute to return to NFS clients.  RFC 5661 shows that server names in an fs_locations attribute are stored in a utf8str_cis type string.  Section 11.10.1 of RFC 5661 describes the fsl_server field this way:

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

RFC 3530bis15 is more specific:

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

This description precludes the inclusion of a port number in this string.  There is no other port number field in the fs_locations4 or fs_locations_info4 data structures.  How will an NFS file server communicate the data in the fedfsFslPort attribute to NFS clients?

The fedfsFslPort attribute is part of the base fedfsFsl object class, but is optional.  Because this port number is not able to be used by at least one file system (NFS), I suggest that keeping fedfsFslPort in the main fedfsFsl object class is not appropriate.  I propose a schema change such that the fedfsFslPort attribute be moved to object classes which inherit from fedfsFsl, where the underlying file system protocol can actually use a port number.

Thus fedfsFslPort then would not appear in either the fedfsFsl object class, or the fedfsNfsFsl object subclass.  But it may appear in some other (yet to be defined) subclass of fedfsFsl which supports a file system protocol that can make use of an IP port number.

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

---

From: Thomas Haynes <[email-masked]>
Date: Mon, 3 Oct 2011 11:42:10 -0500

This is fixable in 3530bis.

5661 states:

   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.

We could modify 3530bis with these additional sentences:

   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.

So all existing implementations that match RFC 3530 would by default
be using port 2049. Those that conform to 3530bis could add the
port numbers.

On Oct 3, 2011, at 11:22 AM, Chuck Lever wrote:

> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4

---

From: <[email-masked]>
Date: Mon, 3 Oct 2011 12:50:26 -0400

If we can fix this in rfc3530bis, we should.

I'm assuming that if we can fix this in rfc3530bis, we could also address it in v4.1.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas Haynes
Sent: Monday, October 03, 2011 12:42 PM
To: Chuck Lever
Cc: [email-masked]
Subject: Re: [nfsv4] FedFS: Comment about fedfsFslPort

5661 states:

   An entry in

---

From: Chuck Lever <[email-masked]>
Date: Mon, 3 Oct 2011 13:31:08 -0400

> be using port 2049. Those that conform to 3530bis could add the

The problem is legacy clients don't expect a universal address with a port.  At the least, you should require NFSv4.0 servers to leave off the ".p1.p2" if the port is 2049.  NFSv4.1 clients already expect a port might appear, so no change is needed there.

---

From: Trond Myklebust <[email-masked]>
Date: Mon, 03 Oct 2011 13:49:46 -0400

> be using port 2049. Those that conform to 3530bis could add the

BTW: Section 3.1 currently says:

   Historically, NFS version 2 and version 3 servers have resided on
   port 2049.  The registered port 2049 [RFC3232] for the NFS protocol
   should be the default configuration.  Using the registered port for
   NFS services means the NFS client will not need to use the RPC
   binding protocols as described in [RFC1833]; this will allow NFS to
   transit firewalls.

shouldn't that 'should' be a 'SHOULD'?

Cheers
  Trond
-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
[email-masked]
www.netapp.com

---

From: Chuck Lever <[email-masked]>
Date: Tue, 11 Oct 2011 18:46:49 -0400

> The problem is legacy clients don't expect a universal address with a port.  At the least, you should require NFSv4.0 servers to leave off the ".p1.p2" if the port is 2049.  NFSv4.1 clients already…

Another observation:

Even with the above proposed changes to 3530bis, a port number can accompany only a universal address, never a hostname.  In other words, if an administrator wants to specify DNS hostnames for a referral, that necessarily means that port numbers cannot be supported for that referral.

But that also suggests that fedfsFslPort is unneeded for NFS: a port number can only be expressed in the server field of fs_location4 (or the fls_server field of fs_locations_server4), and only if that field is expressing an IP address and not a DNS hostname.

To say it another way, what value would I choose to set the fedfsFslPort field?  If fedfsFslHost is a DNS hostname, the fedfsFslPort field can't be communicated to NFS clients during a referral; thus fedfsFslPort is ignored.  If fedfsFslHost expresses a universal address, it already may contain a port number, so there is no need for a separate field in the FSL to express a port number.

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.

---

From: "Everhart, Craig" <[email-masked]>
Date: Tue, 11 Oct 2011 20:19:13 -0400

+1

---

From: Robert Thurlow <[email-masked]>
Date: Wed, 12 Oct 2011 16:41:48 -0600

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

Agreed.

Rob T

---

From: James Lentini <[email-masked]>
Date: Wed, 19 Oct 2011 14:54:18 -0400 (EDT)

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.

-james

---

From: Chuck Lever <[email-masked]>
Date: Wed, 19 Oct 2011 12:10:03 -0700

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

---

From: Chuck Lever <[email-masked]>
Date: Wed, 19 Oct 2011 13:55:42 -0700

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

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?

---

From: Spencer Shepler <[email-masked]>
Date: Wed, 19 Oct 2011 21:01:49 +0000

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

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Chuck Lever
> Sent: Wednesday, October 19, 2011 1:56 PM
> To: James Lentini
> Cc: Robert Thurlow; [email-masked]
> >>>> 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.
> >>
> >> objectclass makes sense to me. Subclasses of fedfsFsl should include
> >> a port when necessary.
> >>
> > 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?
> 
> 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

---

From: James Lentini <[email-masked]>
Date: Thu, 20 Oct 2011 10:17:04 -0400 (EDT)

On Wed, 19 Oct 2011, Chuck Lever wrote:

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

---

From: James Lentini <[email-masked]>
Date: Thu, 20 Oct 2011 10:20:48 -0400 (EDT)

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.

---

From: Chuck Lever <[email-masked]>
Date: Thu, 20 Oct 2011 08:58:06 -0700

Hi James-

> section 4.2.1.2 of draft-ietf-nfsv4-federated-fs-protocol-11 for the 

Got it.

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

---

From: James Lentini <[email-masked]>
Date: Thu, 20 Oct 2011 15:37:57 -0400 (EDT)

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:

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

---

From: Chuck Lever <[email-masked]>
Date: Thu, 20 Oct 2011 14:14:18 -0700

>           | fs_locations                    | fs_locations_info

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.

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

---

From: James Lentini <[email-masked]>
Date: Fri, 21 Oct 2011 17:22:24 -0400 (EDT)

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

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

That exchange seems to have concluded that the universal address 
format is incompatible with legacy clients. I think the lack of a 
common server name format for the various referral flavors needs to be 
addressed.

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

I read Tom Haynes's proposal to not include legacy clients that don't 
understand universal addresses. Therefore, 3530bis changes wouldn't be 
relevant here. There will still be multiple formats.

With its current definition, an NFS FSL can express all the server 
name formats allowed in the various referral flavors, and anticipates 
one that is not supported yet: DNS name with port. Removing the 
fedfsNfsFslPort from the NFS FSL would eliminate the ability to 
express a DNS name with port address. That seems shortsighted to me. 
My preference would be to keep the current definition.

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

I agree. Dropping the entire record is a perfectly reasonable 
approach.

Would a table of explicit rules like the one below address this?

  NFS FSL Contains   |  Referral Allows  |  Drop?
----------------------------------------------------
  IP                 |  IP               |  No
----------------------------------------------------
  IP with port       |  IP               |  Yes
----------------------------------------------------
  IP                 |  IP with port     |  No
----------------------------------------------------
  IP with port       |  IP with port     |  No
----------------------------------------------------
  DNS name           |  DNS name         |  No
----------------------------------------------------
  DNS name with port | DNS name          |  Yes

---

From: Chuck Lever <[email-masked]>
Date: Sat, 22 Oct 2011 11:59:23 -0400

> relevant here. There will still be multiple formats.

Another way to look at it is that 3530 servers can't tell whether they are talking to a 3530 or a 3530bis client, so there's no way to know if the client can understand a referral containing a universal address.  If that is the case, we may never be able to use universal addresses reliably in fs_locations4.

>  NFS FSL Contains   |  Referral Allows  |  Drop?

This is critical for maximal interoperability, so it is a good idea, I think, to lay it out in the NSDB protocol draft.  You might want to mention the case where there is no usable location to return via an fs_locations4 request.

A similar conversion table for fs_locations_info4 could be helpful as well.  Instead of dropping, a name lookup would be required on the file server for the cases where a DNS hostname and a non-2049 port is specified in the NFS FSL.  It bears mentioning in the draft that the table above applies to fs_locations4 for NFSv4.0, but the fs_locations_info4 rules apply to fs_locations4 for 5661 clients.  Confusing.