Minutes IETF102: nfsv4
minutes-102-nfsv4-00

NFSv4 WG
IETF 102, Montréal QC CA
July 16, 2018

Start 9:30
6 in room
6+ on meetecho
?? on a/v stream

Blue sheet distributed, Note Well presented.
Agenda not bashed

Chuck Lever  IMA integrity

Per-file integrity hash, of entire file
 Executables, stable file content
 End-to-end, computed above NFS and passed by NFS client
 Returned by NFS server for verification before execution
Also applicable to certain file attributes
Performance, scenarios discussed - to be part of the work
Additional "file capabilities" possible (Linux)
 Focus of a later draft
 Implications on "namespace" - i.e.containers

Discussion as to standardization of hash format(s), PKI infrastructure, other
needed references

Chuck Lever RPC/RDMA Crediting

Review of RPC/RDMA crediting as today
 Credits are not "windowed" - typically a stable, constant number
 Adaptive, but only via recall
 Several other shortcomings listed in deck
Goals for RPC/RDMA v2
 Larger (fragmented) inline request
 RDMA remote invalidation
 Cancelation of ongoing RPC transaction
 Larger RPC Reply
 Callback RPC parsing/management
Possible "fixes"
 Listed in deck (and draft)
Existing rpcrdmav2 draft is expired
Consider concall to discuss ideas in deck, and update draft after

<1 hour timecheck>

Tom Haynes Open vs Deleg Stateid / Offline files / Getattr storm

File browsers open file on hover to provide preview
 Very expensive - how to deal?
 Proposal - add an "offline" bit to suggest client not open file
Clients may issue large number of getattr on write workloads
 Proxying - convert non-NFSv4.2 traffic ("FlexFile server")
 "Time proxying" - DS is not authoritative on times, so MDS still consulted
 (72K gatattrs on 40K writes!)
  MDS infers skew when client requests specific (new?) attribute(s)
Open vs Delegation stateid
 Server needs to maintain extra state, which client may not need
 Make this explicit - client requests Open XOR Delegation stateid
  Note, MDS might return both, and client must handle if so
Draft in review - please send comments
Next draft ideally becomes a WG task
Question - one draft or three? Suggestion: one.

Dave Noveck Multiserver namespace

Multiserver namespace history
 Areas to be addressed listed
  Trunking detection, trunking discovery, state migration, connection types
  For NFSv4.0, 4.1 and 4.2 (need for earlier versions to be revised?)
 Table of RFCs and mv0, mv1 drafts
Migration issues history
 Common document for all minor versions
 draft-ietf-nfsv4-migration-issues-15 is current,but some issues possible remain
  rca_one_fs attribute handling tbd
 Details of vmware esx server discussion
Discussion of WGLC process
 Is document done and publishable?
  it's a worthwhile doc with good content
  Unclear who would consume/implement it
 Opinion - WG should reach rough consensus on content, then larger decision on
 publication as Informational

Trunking update
 MSNS draft moving toward -01, will request as WGLC
 Authors believe work is complete

MSNS update
 -01 has been out about a month, needs discussion
 Is a conference call needed? Can do if so
 Current target March 2019 completion, meaning WGLC by January
 Desire to include rca_one_fs clarifications

Dave Noveck NFSv4 WG milestones

<see table of milestones and dates in milestonesietf102 deck>
Many non-controversial tasks listed

Flex files - may desire a small layout change
 This would require a layout type id change - heavy handed but required by
 layouts May need to discuss how to make this lighter weight
NVMe for pNFS
 Author still interested, but no recent work
 Seeking momentum - should it remain on milestone list in interim? Consensus:
 yes
pNFS RDMA Layout
 I-D is expired
 Some known issues, identified by Oracle researcher
 How realistic is date of 9/2019? TBD, should remain as milestone though
 NFSv4 WG could "take over" the draft, if needed/desired

<ends 11:35>