Subject: [nfsv4] AD evaluation of draft-ietf-nfsv4-mv0-trunking-update-01

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 22 Oct 2018 13:37:04 -0500

As usual for NFCv4 drafts, this one's in good shape. I do have comments,
but they're mostly about making the document more accessible for people who
don't understand NFSv4 as well as the working group does.

I'll let you folks work through my comments, and then request Last Call.

Thanks,

Spencer

==

Try not to laugh, but the past two or three IESGs have been very sensitive
about the privacy implications of "location" in drafts we've been
reviewing, across a wide range of contexts. It might be helpful to think
about using "file system location" in the Abstract, and in the
Introduction, on first use. So, saying something like

OLD

The location-related attribute in NFS version 4.0, fs_locations, informs
clients about alternate locations of file systems.

NEW

   The file system location-related attribute in NFS version 4.0,
fs_locations,

   informs clients about alternate locations of file systems.

might head off at least one or two conversations with SECDIR and the IESG
in general. To be clear, I don't think you have a problem, I just think you
could make it obvious on first use that you don't have a problem :-)

I have only a hand-waving understanding of what trunking means in NFSv4,
which shouldn't be a problem, except that this draft doesn't include a
definition of trunking, until I get down to new text that's being added to
RFC 7530. I see

 Trunking:  A situation in which multiple physical addresses are
     connected to the same logical server.

in https://tools.ietf.org/html/rfc7931, but I don't see RFC 7931 listed as
a reference on first use (assuming that RFC is the canonical definition of
trunking). So I'd suggest either providing a short definition, or adding
something like "defined in [RFC7931]" on first use of the term.

The last sentence in this text,

 o The combination of a server network address and a particular
     connection type is referred to as a "server endpoint".  Using
     different connection types typically results in the use of
     different ports.  However, the use of different ports by multiple
     connections to the same network address is not the essence of the
     distinction between the two endpoints used.

wasn't helpful for me. I was expecting the last sentence to be followed by
a statement about what "the essence of the distinction" actually was. Is
this a good place for you to say more about that, or to provide a reference
to someplace where that's explained?

You might have cleared this next one up as well, when you provide a
reference or definition for "trunking", but when I saw this text,

 o Two network addresses connected to the same server are said to be
     server-trunkable.

I wondered if there were other kinds of trunking in NFSv4 - and "server
trunking" isn't defined in RFC 7931, either. So I'm wondering if they're
synonyms - in which case, I'd pick one, or if they're not - in which case,
I'd use the appropriate term consistently. But right now, I don't know
whether there's a difference between "trunking" and "server trunking".

I found Section 3.3. Document Goals to be really helpful in understanding
what you're doing. Perhaps this material could appear earlier in the
document?

I like your organization of Section 4, with things like

 o Section 5 replaces Section 8.1 of [RFC7530], entitled "Location
     Attributes".  This section has been reorganized and extended to
     explicitly allow the use of fs_locations to provide trunking-
     related information that appropriately interacts with the
     migration, replication and referral features of fs_locations.
     Terminology used to describe the interactions is added.

but when the reader hits Section 5 in this document, that section is a
drop-in replacement for Section 8.1 of RFC 7530, which is a little
disorienting. Perhaps doing something like retitleing the sections, such as
(if I'm doing this right)

OLD

5.  Location Attributes (as updated)

NEW

5.  Updated Section 8.1 of [RFC7530], entitled "Location Attributes"

would help the reader keep track of what's going into RFC 7530 when looking
at that text. The same comment applies for "to be added" sections.

I'm thinking the current text is more confusing because most drafts like
this that I've seen either indent the new text, or provide OLD/NEW blocks,
that make it easier for the reader to identify what they need to know about
what's being updated, and the actual resulting text block.

I'm also thinking this will make text like

  See Sections 6.5 and 6.6 of the current document for details.

in the new text less ambiguous, but do the right thing.

This is mostly an accommodation to people who don't know this stuff as well
as you do, but that includes most of the review team members and IESG
members who will be looking at this draft on the way to publication.

In this text,

6.3.  Location Attributes and Connection Type Selection (to be added)

  Because of the need to support multiple connections, clients face the
  issue of determining the proper connection type to use when
  establishing a connection to a server network address.  The
  fs_locations attribute provides no information to support connection
  type selection.  As a result, clients supporting multiple connection
  types need to attempt to establish a connection on various connection
  types until the one preferred by the client is successfully
  established.

is there any guidance you can give for ordering connection attempts, or is
this entirely dependent on the environment the client is accessing?

---

From: Chuck Lever <[email-masked]>
Date: Mon, 22 Oct 2018 14:54:50 -0400

> On Oct 22, 2018, at 2:37 PM, Spencer Dawkins at IETF <[email-masked]> wrote:
> 
> As usual for NFCv4 drafts, this one's in good shape. I do have comments, but they're mostly about making the document more accessible for people who don't understand NFSv4 as well as the working group does. 
> 

Thanks for the quick turnaround, Spencer D.

We've struggled with the issues of how to present significant updates to
existing RFCs, and you spotted some of the same areas we've been massaging.

Overall I don't have any objections to these changes, but the terminology
is shared with nfsv4-migration-update (which was the basis for this document)
and mv1-msns-update. I would prefer that Dave, as lead author of those two
documents, make an initial response especially on the terminology that is in
common between the mv0 and mv1 documents.

> ==
> 
> Try not to laugh, but the past two or three IESGs have been very sensitive about the privacy implications of "location" in drafts we've been reviewing, across a wide range of contexts. It might be helpful to think about using "file system location" in the Abstract, and in the Introduction, on first use. So, saying something like 
> 
> OLD
> 
>    The location-related attribute in NFS version 4.0, fs_locations,
>    The file system location-related attribute in NFS version 4.0, fs_locations,
> might head off at least one or two conversations with SECDIR and the IESG in general. To be clear, I don't think you have a problem, I just think you could make it obvious on first use that you don't have a problem :-)
> 
> I have only a hand-waving understanding of what trunking means in NFSv4, which shouldn't be a problem, except that this draft doesn't include a definition of trunking, until I get down to new text that's being added to RFC 7530. I see 
> 
> in https://tools.ietf.org/html/rfc7931, but I don't see RFC 7931 listed as a reference on first use (assuming that RFC is the canonical definition of trunking). So I'd suggest either providing a short definition, or adding something like "defined in [RFC7931]" on first use of the term. 
> 
> wasn't helpful for me. I was expecting the last sentence to be followed by a statement about what "the essence of the distinction" actually was. Is this a good place for you to say more about that, or to provide a reference to someplace where that's explained?
> 
> You might have cleared this next one up as well, when you provide a reference or definition for "trunking", but when I saw this text,
> 
> I wondered if there were other kinds of trunking in NFSv4 - and "server trunking" isn't defined in RFC 7931, either. So I'm wondering if they're synonyms - in which case, I'd pick one, or if they're not - in which case, I'd use the appropriate term consistently. But right now, I don't know whether there's a difference between "trunking" and "server trunking". 
> 
> I found Section 3.3. Document Goals to be really helpful in understanding what you're doing. Perhaps this material could appear earlier in the document?
> 
> but when the reader hits Section 5 in this document, that section is a drop-in replacement for Section 8.1 of RFC 7530, which is a little disorienting. Perhaps doing something like retitleing the sections, such as (if I'm doing this right)
> 
> OLD
> 
> would help the reader keep track of what's going into RFC 7530 when looking at that text. The same comment applies for "to be added" sections.
> 
> I'm thinking the current text is more confusing because most drafts like this that I've seen either indent the new text, or provide OLD/NEW blocks, that make it easier for the reader to identify what they need to know about what's being updated, and the actual resulting text block. 
> 
> This is mostly an accommodation to people who don't know this stuff as well as you do, but that includes most of the review team members and IESG members who will be looking at this draft on the way to publication. 
> 
> In this text,
> 
> is there any guidance you can give for ordering connection attempts, or is this entirely dependent on the environment the client is accessing?

--
Chuck Lever

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 22 Oct 2018 13:58:22 -0500

Hi, Chuck,

> existing RFCs, and you spotted some of the same areas we've been massaging.

That's encouraging - you guys are the pros!

> common between the mv0 and mv1 documents.

Sure. I'm heavily in "do the right thing" mode, and that sounds right to me.

Spencer (D, and I forgot that on my first note)

>
>
> > ==
> >
> > Try not to laugh, but the past two or three IESGs have been very
> sensitive about the privacy implications of "location" in drafts we've been
> > might head off at least one or two conversations with SECDIR and the
> IESG in general. To be clear, I don't think you have a problem, I just
> think you could make it obvious on first use that you don't have a problem
> :-)
> >
> > in https://tools.ietf.org/html/rfc7931, but I don't see RFC 7931 listed
> as a reference on first use (assuming that RFC is the canonical definition
> of trunking). So I'd suggest either providing a short definition, or adding
> > wasn't helpful for me. I was expecting the last sentence to be followed
> by a statement about what "the essence of the distinction" actually was. Is
> > I found Section 3.3. Document Goals to be really helpful in
> understanding what you're doing. Perhaps this material could appear earlier
> in the document?
> >
> > would help the reader keep track of what's going into RFC 7530 when
> looking at that text. The same comment applies for "to be added" sections.
> >
> > This is mostly an accommodation to people who don't know this stuff as
> well as you do, but that includes most of the review team members and IESG
> > is there any guidance you can give for ordering connection attempts, or
> is this entirely dependent on the environment the client is accessing?
>
> --
> Chuck Lever
>
>
>
>

---

From: David Noveck <[email-masked]>
Date: Mon, 22 Oct 2018 22:49:58 -0400

Let m try to clarify some things about trunking in NFSv4.   There are two
types of trunking in NFSv4.1 which are defined in RFC5661.   These are
server trunking and session trunking.  In both cases you have multiple
network addresses connected to the same server.  They differ only in how
they relate to the session feature of NFSv4.1.  Two session-trunkable
ddresses can be used together to access a single session while
server-trunkable addresses cannot and can support distinct sessions
connected to a single server and sharing a clientid.

Trunking was not explcitly mentioned in RFC7530, so the first mention of
trunking with regard to NFSv4.0 was in RFC7931.   Since there are no
sessions in NFSv4.0 it is closest to server-trunking in NFSv4.1 and we had
been calling it server trunking but we might consider a different term
since it is distinct from both NFSv4.1 server trunking and NFSv4.1 session
trunking.

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 23 Oct 2018 23:12:55 -0500

Hi, David,

> since it is distinct from both NFSv4.1 server trunking and NFSv4.1 session
I'm glad my question wasn't totally thick. I'll let you guys figure out
what the right thing to do is (on this, and on other comments).

Thanks for helping me understand what was going on.

Spencer

---

From: [email-masked] (J. Bruce Fields)
Date: Fri, 26 Oct 2018 13:39:13 -0400

On Mon, Oct 22, 2018 at 10:49:58PM -0400, David Noveck wrote:
> server trunking and session trunking.

Right, except RFC 5661 calls the former "client ID trunking".  Sounds
like we just need some minor fixes to make the jargon consistent.

--b.

> In both cases you have multiple

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

---

From: Chuck Lever <[email-masked]>
Date: Fri, 26 Oct 2018 15:01:10 -0400

Hi Spencer D -

> On Oct 22, 2018, at 2:37 PM, Spencer Dawkins at IETF <[email-masked]> wrote:

[ ... snipped ... ]

> is there any guidance you can give for ordering connection attempts, or is this entirely dependent on the environment the client is accessing?

Good question.

Connections can be tried one at a time, or a clever implementation
might try to establish all connection types at once and which ever
completes first is the one the client continues to use. Some
implementations prefer RDMA over TCP, but that can be a poor choice
if the RDMA fabric is 25Gb but the TCP network is 100GbE.

It seems to us this is a matter of implementation quality rather
than an interoperability concern, so no mention of ordering was
made here.

Does anyone with an existing multi-transport implementation disagree
with this?

--
Chuck Lever