Re: [nfsv4] Review of draft-ietf-nfsv4-rfc5667bis-09

[David Noveck <[e-mail]>]

>
> We could do something clever like add these limits to the
> RDMA CM private data.
>

I don't think this is all that "clever".  Calling it "clever' may strengthen
the perception that is a hack, which I don't think it is.  On the plus
side,
it is a reasonable extension of a mechanism that already exists
(i.e. there is running code) and could be reasonably extended.

> Please, no.

If this extension were to be made, it would be done after the existing
I-D becomes a working group draft.   I think your general
objections to this way of passing information can be made as that
issue is considered.

> Placing a message in that data is in itself a protocol,

Agreed

> and the size and support for that data is implementation defined,
>in the RDMA layer.

That's an issue already deal with in the existing I-D.  If
the implementation
does not support this or the size limits are too restrictive, a deafault is
used.  In the event of an extension, the same would apply.  There would
have to be defaults to deal with the case in which extended message is too
long
to be sent.

> If such a parameter exchange is required

The question is not whether it is "required" or "REQUIRED" :-).  The real
question is whether anyone wants to bother to author the needed document.
In other words, I'm looking for volunteers.

> (and remember it needs to go both ways)

I don't see that.  To me, this something that the responder need to
inform the requester of, so that the requester can do the appropriate
thing to avoid getting a mysterious error.

I'm assuming that there is no real need for this on the callback path,
although
there might eventually be.

> just define it as a full-blown negotiation,

I'm not sure there is a place for an actual negotiation, even though many
things
where there is no actual negotiation are described that way.  To me, the
appropriate  approach is for the responder to make its final/only offer on a
take-it-or-leave-it-basis.  that's as close to "negotiation" as it gets.

> at the RPC-RDMA,

This could be done using the framework for transport properties defined in
draft-cel-nfsv4-rpcrdma-version-two-03.


> or better, the NFS layer.

I think this the best choice because the extension mechanism is furthest
along;

   - draft-cel-nfsv4-rpcrdma-version-two is an I-D and moving it to be a WG
   document has even been discussed yet
   - draft-cel-nfsv4-rpcrdma-cm-pvt-msg is an I-D and while there has been
   a discussion of making it a WG document, it still might controversial.
   - draft-ietf-nfsv4-versioning-09 has been through WGLC and is 14 days
   into AD Evaluation.  The fastest way of making this extension available is
   by defining an NFSv4.2 extension referencing the versioining draft
   normatively extension, this doesn't help v4.0 clients.  Sigh!


> There are already some RDMA
> values exchanged in the NFSv4.1 Session establishment, which could
> be extended.

I don't think you can extend this without creating CREATE_SESSION2,
CREATE_SESSION_PLUSPLUS, or, my favorite CREATE_SESSION_2017.

Again, we need a volunteer.  If you think we need this, the way to make it
happen
is to submit and I-D and try to make it happen.


On Thu, Apr 27, 2017 at 11:46 AM, Tom Talpey <[e-mail]> wrote:

> On 4/27/2017 11:35 AM, Chuck Lever wrote:
>
>> We could do something clever like add these limits to the
>> RDMA CM private data.
>>
>
> Please, no. Placing a message in that data is in itself a protocol,
> and the size and support for that data is implementation defined,
> in the RDMA layer.
>
> If such a parameter exchange is required (and remember it needs to
> go both ways), just define it as a full-blown negotiation, at the
> RPC-RDMA, or better, the NFS layer. There are already some RDMA
> values exchanged in the NFSv4.1 Session establishment, which could
> be extended.
>
> Tom.
>
>
> _______________________________________________
> nfsv4 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nfsv4
>