[nfsv4] preliminary review of draft-cel-nfsv4-reminv-design

[David Noveck <[e-mail]>]

The first issue concerns the structure rpcrdma2_chunk_lists.  Although this
structure is defined in draft-cel-nfsv4-rpcrdma-version-two-01, there is
nothing that uses it.  The structure that RDMA_MSG and RDMA_NOMSG include
is rpcrdma2_chunks, which is not defined in the XDR.  It appear that this
issue has existed since draft-cel-nfsv4-rpcrdma-version-two-00.

Although that issue can and should be fixed, I think we need to have a more
complete discussion of the extension model for version two and for
RPC-over-RDMA as a whole in the near term.

As I understand things, the original intention was that Version Two be a
compatible extension of Version One.  Now, with the inclusion on the
direction indication added in -01, and now the R-key proposed in
reminv-design, Version One and Version Two messages will be
OTW-incompatible, and I think are better off with a model in which Version
Two consists of  subset which equal to Version One and a set of additions,
primarily optional.  I think we should diverge from that model only if the
benefits are sufficiently important to justify this discontinuity.

With these changes, the implementation barrier to convert a Version One
implementation to be compatible Version Two becomes significant.  I think
we would be better off, if most Version One implementations could be made
compatible with very easily, making the decision to do so more or less
automatic.

To get back to remote invalidation, I would prefer your section 3.3 as a
baseline to be made accessible with no XDR changes in the base Version
Two.  The additional functionality provided by 3.4, while desirable, is not
of sufficient benefit to justify a non-compatible XDR change.  I feel that
this functionality should be available as an OPTIONAL extension.

When I say that it should be an "OPTIONAL Extension", I don't mean to imply:

   - That it needs to be implemented as a subcase of RDMA_OPTIONAL.
   - That it should be documented in a separate document, as opposed to
   being documented (eventually) in draft-ietf-nfsv4-rpcrdma-version-two.

What I do mean is that we should define new message type for extensions (so
that we maintain Version One as a subset of  Version Two) and that we
should (not "SHOULD" :-) make these new message types "OPTIONAL" (in the
RFC2119 sense).  I can see, if there is sufficient reason, making an
extension REQUIRED, but I don't see a reason to change an existing message
type in an incompatible way.

One way to do this is to define new message types RDMA_MESSAGEX and
RDMA_NOMSGX which include direction and rdma_handle but there are other
ways to do this.  To make it easier to determine whether support for
OPTIONAL message types is present, we could define a transport
characteristic/attribute that provides a bit mask of supported message
types.