Re: Proposed updates to draft-ietf-nfsv4-rpcrdma-cm-pvt-data

On 12/15/2019 3:48 PM, Chuck Lever wrote:
> As a result of expert review, changes are needed to Section 4.1.2
> to clarify the purpose and implementation guidance of the Format
> Identifier field.
> 
> I propose that the new Section read (in its entirety):
> 
> 
> 4.1.2.  Amongst Implementations of Other Upper-Layer Protocols

That first word is a very odd one in a section title. Would
"Interoperability With" be more meaningful?

>     The Format Identifier field in the message format defined in this
>     document is provided to enable implementations to distinguish RPC-
>     over-RDMA version 1 Private Data from private data inserted at layers
>     below RPC-over-RDMA version 1.  An example of a layer below RPC-over-

"Below" is problematic here. The RFC6581 MPA enhanced connection
processing can insert private data at the start of the field, and
it is "below" RPC in the stack, but the peer's RFC6581 processing
strips it off. Therefore, of RPC is the "lowest upper layer" in
such a stack, there is no issue.

However, there might well be other lower layers, with different
behaviors, injecting their own private data payloads. Or indeed,
upper layers. And these payloads may choose to append, or prepend
to the buffer.

>     RDMA version 1 that makes use of CM Private Data is iWARP, via the
>     MPA enhancement described in [RFC6581].
> 
>     During connection establishment, an implementation of the extension
>     described in this document checks the Format Identifier field before
>     decoding subsequent fields.  If the RPC-over-RDMA version 1 CM
>     Private Data Format Identifier is not present as the first 4 octets,

So, just to be clear - this introduces a new requirement on other
layers over the same connection. They MUST NOT inject private data
at the beginning of the buffer, or if they do, they MUST strip it
off.

>     an RPC-over-RDMA version 1 receiver MUST ignore the CM Private Data,
>     behaving as if no RPC-over-RDMA version 1 Private Data has been
>     provided (see above).

And, if the prior requirement is not made, then the RPC layer needs
to scan the prvate data rather carefully to see if the identifier,
and the payload associated with it, is present somewhere in the
private data.

>     Because the Format Identifier field is newer than some other
>     potential users of private data (such as iWARP), there is a risk that
>     a lower layer might inject its own private data with a payload
>     somehow containing the identifier of RPC-over-RDMA version 1.  It is

Well, *and* not strip it off. This could happen if the peer implemented
a lower layer that wasn't recognized by the receiver, and the data
simply passed up. See previous paragraph.

>     recommended that RPC-over-RDMA version 1 implementations perform
>     additional checks on the content of received CM private data before
>     making use of it.

"Additional checks" is pretty vague. Are there any specific requirements?

Tom.

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