Subject: [nfsv4] Notes from NFSv4 design discussion on March 22, 2016

From: Spencer Shepler <[email-masked]>
Date: Wed, 23 Mar 2016 22:17:49 +0000

See below: all mistakes are mine - clarifications back to the WG alias.

Attendees:

-        Spencer

-        Tom Talpey

-        Dave Noveck

-        Chuck Lever

-        Alex McDonald

-        Bill Simpson

-        Brian Pawlowski

-        Matt Benjamin

-        Robert Fair

Agenda:
- Agenda bashing
- Define a process for rfc5667 document updates
- Identify and discuss remaining controversies in rfc5666bis
- Agree on a plan for getting rfc5666bis through WGLC
- Assess post-rfc5666bis extensions for RPC-over-RDMA (more detail based on input from Bill)

Item 1: Define a process for rfc5667 document updates

-        Discuss the RFC5667 updates

-        Options discussed in Dallas:

o   Update of section 5

o   Approach for rfc5666

-        Chuck's preference is to replace RFC5667

o   Bill, Spencer is supportive, Tom's comments are that NFS protocol is changing and a "bis" document may be problematic to keep current or in alignment with current use cases

o   Chuck mentions that the proposed rfc5667bis would cover all "proposed" NFSv4 I-Ds (would cover 4.0, 4.1, and 4.2)

o   Agreed that rfc5667bis would include up to and including 4.2

-        Items to take care of with an rfc5667bis

o   This update applies only to version of RPC over RDMA but need to ensure language is "appropriate" for future version usage

o   V2/V3 inline threshold updates

o   Section 5 update (NFSv4 compound) update the incomplete discussion such that it is a complete description and normative in its language

o   Bi-directional RPC topic needs to be covered for NFSv4.1

o   Obsolete the current 5667

-        Timeline for the RFC5667bis

o   Based on other work in this area

o   Start this before the Berlin IETF

o   Some discussion of working to get 5667bis out "soon" so that it happens before 5666...

Item 2: Identify and discuss remaining controversies in rfc5666bis

-        Chuck's current status is that all issues should be addressed and included in the document

-        To the point of removing text to remove either potential review items or to remove contentious items

-        Items in the current -04 version that require additional discussion

o   Bill is opposed to the inclusion of section 9.3 in the bis...

o   If section is removed, need to restructure slightly to assist with what "makes an RPC over RDMA" version so that it is clear for future work.

-        Section 9 will be

o   "what makes a version"

-        5.1.4 will need update/removal (take the XDR "back a step" to revert the extensibility items)

-        Other items...

-        Inclusion of RPCSEC_GSS discussion and support...

o   Rough consensus is that this needs to be addressed in the I-D before WG last call

o   <lot of discussion / clarification on topic at hand>

o   Tom asked that a brief review be made for other ways to address the problem

o   Tom to identify possible attack vectors on the steering tag...

-        Proposal: copy bi-directional RPC sections into the 5666bis and Chuck is considering I-D submission to IESG at the same time

o   Remove section 7 and move it to the separate, existing document - will co-publish

-        Make above set of changes and submit at -05

-

Item 3: Plan for rfc5666bis last call

-        Start with a 3 week review cycle for the WG and ensure that everyone has time for review

-        Do we take the other two documents at the same time...?

-        We can do that but Chuck will have potentially more work to align with the desire to have a "align last-call"

-        Chuck will aspire to align the documents for a single set for review.

Item 4: Assess post-rfc5666bis extensions for RPC-over-RDMA

-        Extensibility: ability to add feature but without a version change (inline threshold and ....)

-        Are there features that are outside of extensibility that requires something "larger" and no specific cases were identified.

-        A couple of examples of ideas to evaluate:

o   MSGP

o   Possible discovery of larger inline thresholds (larger than 4K, in this case)

o   Possible support for discovery of remote invalidation capability.

o   Possible support for push-mode (RDMA Writes to server)

-        Version 2 is the extensibility model (that is the proposal from Bill - and this was generally acceptable to those in the discussion)

-        Spencer suggests that we identify one or two "must have" features for extensibility to encourage WG "commitment" to the work and to move it forward effectively; have a clear path to "complete" and then lock the scope/plan

-

---

From: Chuck Lever <[email-masked]>
Date: Thu, 24 Mar 2016 11:12:36 -0400

> On Mar 23, 2016, at 6:17 PM, Spencer Shepler <[email-masked]> wrote:
> 
>  
> See below: all mistakes are mine – clarifications back to the WG alias.
>  
>  
>  
>  
> Attendees:
> -        Spencer
> -        Tom Talpey
> -        Dave Noveck
> -        Chuck Lever
> -        Alex McDonald
> -        Bill Simpson
> -        Brian Pawlowski
> -        Matt Benjamin
> -        Robert Fair
>  
> Agenda:
> - Agenda bashing
> -        Chuck’s preference is to replace RFC5667
> o   Bill, Spencer is supportive, Tom’s comments are that NFS protocol is changing and a “bis” document may be problematic to keep current or in alignment with current use cases
> o   Chuck mentions that the proposed rfc5667bis would cover all “proposed” NFSv4 I-Ds (would cover 4.0, 4.1, and 4.2)
> o   This update applies only to version of RPC over RDMA but need to ensure language is “appropriate” for future version usage
> o   Some discussion of working to get 5667bis out “soon” so that it happens before 5666…
>  
> -        Chuck’s current status is that all issues should be addressed and included in the document
> o   Bill is opposed to the inclusion of section 9.3 in the bis…
> o   If section is removed, need to restructure slightly to assist with what “makes an RPC over RDMA” version so that it is clear for future work.
> -        Section 9 will be
> o   “what makes a version”
> -        5.1.4 will need update/removal (take the XDR “back a step” to revert the extensibility items)
> -        Other items…
> -        Inclusion of RPCSEC_GSS discussion and support…
> o   Tom to identify possible attack vectors on the steering tag…
> o   Remove section 7 and move it to the separate, existing document – will co-publish
> -        Do we take the other two documents at the same time…?
> -        We can do that but Chuck will have potentially more work to align with the desire to have a “align last-call”
> -        Extensibility: ability to add feature but without a version change (inline threshold and ….)
> -        Are there features that are outside of extensibility that requires something “larger” and no specific cases were identified.
> -        Version 2 is the extensibility model (that is the proposal from Bill – and this was generally acceptable to those in the discussion)
> -        Spencer suggests that we identify one or two “must have” features for extensibility to encourage WG “commitment” to the work and to move it forward effectively; have a clear path to “complete” and then lock the scope/plan

I have drafted a personal I-D that takes a stab at
RPC-over-RDMA Version Two.

The IETF submission tool is closed now in preparation
for IETF 95. And this mailing list has some limits on
attachment size.

Thus I plan to submit this document when the tool
re-opens in a few weeks. Meanwhile, I will focus on
completing the action items in the minutes above.

--
Chuck Lever