Re: [nfsv4] Benjamin Kaduk's No Objection on draft-ietf-nfsv4-rpcrdma-cm-pvt-data-07: (with COMMENT)

[Chuck Lever <[e-mail]>]

> On Mar 1, 2020, at 12:24 PM, Tom Talpey <[e-mail]> wrote:
> 
> On 2/20/2020 11:51 AM, Benjamin Kaduk wrote:
>> Hi Chuck,
>> On Thu, Feb 20, 2020 at 10:13:26AM -0500, Chuck Lever wrote:
>>> Hi Ben, thanks for your comments! Responses and questions below.
>>> 
>>> 
>>>> On Feb 19, 2020, at 8:10 PM, Benjamin Kaduk via Datatracker <[e-mail]> wrote:
>>>> 
>>>> Benjamin Kaduk has entered the following ballot position for
>>>> draft-ietf-nfsv4-rpcrdma-cm-pvt-data-07: No Objection
>>>> 
>>>> When responding, please keep the subject line intact and reply to all
>>>> email addresses included in the To and CC lines. (Feel free to cut this
>>>> introductory paragraph, however.)
>>>> 
>>>> 
>>>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>>>> for more information about IESG DISCUSS and COMMENT positions.
>>>> 
>>>> 
>>>> The document, along with other ballot positions, can be found here:
>>>> https://datatracker.ietf.org/doc/draft-ietf-nfsv4-rpcrdma-cm-pvt-data/
>>>> 
>>>> ...
>>>> Section 6
>>>> 
>>>>   The RPC-over-RDMA version 1 protocol framework depends on the
>>>>   semantics of the Reliable Connected (RC) queue pair (QP) type, as
>>>>   defined in Section 9.7.7 of [IBA].  The integrity of CM Private Data
>>>> 
>>>> It's interesting to see such a reference to [IBA], when IIUC the RFC
>>>> 8166 protocol is not limited to Infiniband as the underlying transport.
>>> 
>>> Correct, RPC/RDMA can operate on iWARP and RoCE as well. However:
>>> 
>>>  - both of those RDMA fabric types also support RC QPs, and
>>>  - [IBA] appears to be the only publication where "RC QP type"
>>>    is defined, though I could be wrong.
>>> 
>>> I don't read this text as suggesting that RPC/RDMA cannot operate
>>> on those alternate fabrics, but perhaps I am "too close to the
>>> code".
>> I don't read it that way, either; I was just noting that it was surprising
>> that this is the only reference available.  If it is, then it is, though,
>> so no need to change anything.
> 
> The term "RC" or "Reliable Connected" is an InfiniBand-specific term.
> The iWARP protocol has neither a datagram nor unreliable mode, therefore
> it is an "RC" transport by definition, in InfiniBand-speak.
> 
> I do agree that referring normatively to the IB Architecture is odd,
> and perhaps unnecessary. Alternatively, the sentence could be relaxed
> to avoid this IB-specific term, and describe the situation in an
> informative way. "Supports RC-type Infiniband and iWARP Queue Pairs."

No objection to that phrasing, and that certainly explains why RFC 8166
does not refer directly to RC.


> There is a document describing the iWARP consumer-visible semantics,
> in 2003's https://tools.ietf.org/html/draft-hilland-rddp-verbs-00
> However, this document was never adopted as an RDDP work item, and
> was not developed further. It is nonetheless an excellent reference
> and is frequently referred to.
> 
> Tom.

--
Chuck Lever