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

> On Dec 16, 2019, at 9:36 AM, Tom Talpey <[email protected]> wrote:
> 
> 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?

I will review the titles of the sub-sections here.


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

OK. Are you requesting a change to this paragraph?


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

You might have misread this paragraph. I don't think there's a need
for any new requirements: the paragraph states if the first word in
the buffer is not the RPC-over-RDMA Format Identifier, then the
receiver ignores the CM private data.

No other scanning is necessary, it's a fail-safe design since the
CM private data contains only hints.


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

Would "perform sanity checks on the content" be preferable?


--
Chuck Lever



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