[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ietf-nfsv4
Subject:    [nfsv4] Draft Minutes from 61st IETF Meeting in Washington DC
From:       Brian Pawlowski <beepy () netapp ! com>
Date:       2004-12-10 0:31:02
Message-ID: 200412100031.iBA0V2n13621 () tooting ! eng ! netapp ! com
[Download RAW message or body]

Sorry for the delay.  Presentations have been submitted to
the IETF.  Minutes below will be delivered tomorrow PM.

Comments? Questions?

------------------------------------------------------------------

beepy blue sheeted, noted well, and agenda bashed.

	Draft Status (Shepler)

Spencer covered draft status. XDR draft cleared WG last call on way
to become an Internet Std. 

Talpey (review of sessions proposal and status)

RDMA draft needs to reflect Robinson and Mallakarjun comments -
Talpey owns.

Sun will be proto'ing directory delegation to gain feedback targeting
Connectathon in February.

Two new individual drafts on pNFS to be presented today.  Domain
names etc. from Sun colleague (not discussed).

	Bakeathon (Shepler)

ACLs were focus of testing at University of Michigan in October.
Issues on semantics of ACLs (interpretation) vs. ambiguity in
existing Posix implementations. On-going discussion.

SECINFO work needed.  But people are focused.  Shepler wants ACL
discussion to be forwarded to list arising out of Bakeathon.

	NFS Sessions Experience (Talpey)

Talpey described NFS Sessions and recent experience in implementation.
See the slides...

Discussion of ransport diversity, trunking (really for performance).
Big addition is the reliable at-most-once semantics (fixing the
Duplicate Request Cache).

Linux prototyping is occurring under the RDMA umbrella.  Is passing
Connectathon tests.  Three things remain to be prototyped on client
(see slides).  Server testing is being accomplished with a Linux client
and an extended pyNFS test rig.  Pointed to CITI's work -- implementing
just the sessions 4.1 (linux 2.6.9 is latest target -- only over tcp).
RDMA TBD for sessions testing.

What we have learned:

        - client is complete
        - still dealing with slotid (protocol) and implementation 
	interaction
        - server is passing connectathon

Implemented server transport switch.  Sessions will be performance
neutral (expected to be).  Performance (user-level workloads) is of
interest to explore.  Sessions/rdma are separate -- sessions can
enchance the use of rdma.  Harmony between them - (RDMA is at the RPC
transport).

Discussion of details of NFS over RDDP and will there need to be an
NFSv4 minor version update to provide for this.  What interop issues
when server has a mismatch of RDDP support?  Will need an RPC mapping
for SCTP to try testing that later - new transport type for RPC and
well defined behavior of failure.

Want to do performance measurements.  Report progress at Connectathon.
FileBench work at Sun for performance testing.

RDMA is an RPC level specification, different than sessions.  RPC RDMA
spec is in good shape, and can be advanced.  RDDP drafts to go to WG
last call around Thanksgiving.  We need to advance - RDMA can be
advanced independent of minor versioning of NFS.  The RPC negotiation
will handle RDMA or not between server and client...  (beepy is still
waking). Nico and Tom and David mixed it up on RDMA negotiation. Nico
may follow up offline.

	AI: Talpey needs to get some notes out on mail list. Define
	open issues. And drive to ground RDMA stuff. Brent/Talpey
	to drive draft forward.

Need to review security angles of RDMA and TCP transports.

	AI: What is status of CCM? Nico to work with Mike following
	meeting. Draft to progress through nfsv4 WG with coordination
	with security group.

RDDP status from David Black. beepy: Are there implementations? 
David: Yes!

	Global Namespace and Migration (Fan)

Summary of state of knowledge coming.

Using his newcomer view to bring insight into the problem and to move
it forward.  Namespace - Enterprise Namespace is the key to a workable
solution for "cluster" and "world wide"

Charles' view of requirements:

        - location independent
          users want logical location (not "which server")
        - uniform namespace
        - transparent to change
        - secure

DISCUSSION: beepy mentioned that the fsid/filesystem mapping will raise
a management issue

Rainfinity product is at the directory level.  The considerations slide
is trying to capture the granularity of the referral (bogus comment).

Attempts to capture the client/server issues:

        - purely client-based
        - automounter (managability of it is bad - that is feedback 
	to charles)
        - update of maps is not deterministic

DISCUSSION: beepy points out that there needs to be policy enforcement
to overcome the provincial view of automounter

beepy raised issue of what is managed entity for things like migration,
name space junctions, etc. beepy reflected history of lack of agreement
on heterogeneous view of thing to migrate (run afoul of file system
implementations, and protocol in back end to move atomically, etc.)

Nico mentioned distinction of location independence and name space
construction.

Is this as simple as LDAP schemas? and best practices for client on how
to use. What is goal? Limit protocol support and define best practices?
beepy believes reasonable customer requirements are simple for name
space.

What are the pure technical issues - things like volatile file handle
solve more problems than introduced.

Charles wants to move forward with defining what is in scope and what
is out of scope. Nico said many little problems with lots of
disagreements.

	Parallel NFS Requirements and Design Considerations

NFS as metadata server - data access can be multiplexed over a variety
of transports. Scale in number of dimensions.

Nico stood up and went to mic on security issues. This will be a lot of
discussion in future (access control in face of "insecure" back
channels?). "You can do better."

Heterogeneous parallel file access and back channel failure recovery by
devolving to pure NFS Version 4 for completing access? Massive
discussion. beepy tried to move on - this will be covered moving
forward. beepy observed completely out of scope is modifying security
of existing back channel protocols.

Scalability - Spencer has questions... What about availability and
reliability - what problems are introduced? Brent breaks down to data
availability and metadata availability? What is in scope and out of
scope?

beepy winced on hearing pNFS server clean-up issues in event of RAID
striping from client.  Need an exposition of the errors and strangeness
introduced by enabling pNFS stuff.

Block reorganization - requires callback to update maps for block
to file mapping...

Managing the spec - what will core pNFS spec specify? How are new back
channel protocols "added" - how generic is the mapping structures?  How
are extensions managed?

What are restrictions on callback (similar to delegation callback
issues in NFS) in pNFS?

Spencer raised the following questions throughout:

        - why choose the various backend protocols? (SBC, OSD, NFSvX)
        - what is the assumed operational model?
                - pNFS server is responsible for ultimate negotation with
                  the "data servers" to obtain data (always NFSv4.0 
		  accessible)
        - Interoperability?  What is the requirement/goal?
                Server's will have their own filesystem layout, propose 
		to publish mappings and interactions with server?
        - Scalability talked about (what about availability/reliability?)

Scott Bradner asks if LAYOUTGET/LAYOUTCOMMIT reclaims by the server.
Other discussion about LAYOUTRELEASE proposed operation.

How is pNFS work going to be done in WG - coordinate resources, etc.?

beepy: Above all - do no harm.

	Important Dates in Future

Connectathon will run February 24 - March 3, 2005 - right before the
Spring IETF meeting March 6 - 11, 2005 in Minneapolis.


_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4


[prev in list] [next in list] [prev in thread] [next in thread]