Subject: Replication/Migration issues list

From: Robert Thurlow <[email-masked]>
Date: Fri, 23 Aug 2002 16:34:30 -0600 (MDT)

This is a list of the open issues with the current Internet
draft on replication and migration, found at:

http://www.ietf.org/internet-drafts/draft-thurlow-nfsv4-repl-mig-design-00.txt

We talked about most of these to some degree at the last IETF,
but the turnout was light enough that we didn't make much
progress.  I'd appreciate interested parties looking at this
and giving your opinion. For extra credit, you could comment
on the draft as well :-)

Rob T
-----

RPC or just XDR?
  This is still outstanding, pending some further analysis and
  perhaps some prototyping.  The current draft leans towards
  the servers passing XDR-encoded messages across a regular
  TCP connection to bypass performance limitations and data
  transfer size limits, but is there any real gain from this?

Security - TLS or per-message GSS-API?
  Since we have a situation where two peers are connecting to
  transfer a block of data, we don't really need to put strong
  security support in every message, according to IETF norms.
  The current draft focuses on per-message security, mentioning
  TLS at just one point.  What should we do?

  Advantage of TLS: single 'open' message, lower overhead
  Advantage of per-message: we do it already with V4

Compression - do we need it?
  This can reduce bandwidth, but we need to negotiate it and pick
  an algorithm(s) to use.  This is probably worth specifying - we
  just need to find the right algorithms.

Encryption - do we need it?
  This is necessary if we do not use RPC and RPCSEC_GSS, because
  it must be possible for the data's integrity and privacy to be
  protected.  Again, we just need to find the right algorithms.

Other bandwidth reduction ideas - do we bother?
  Some other ideas (e.g. detection of duplicate blocks) have been
  proposed, but is there really going to be benefit to justify it?
  I'm inclined to close this without action.

rsync equivalent - do we bother and how to approach it?
  Some have suggested the protocol drop into an rsync-like mode
  where the two servers compare objects when insufficient information
  is available.  Probably a good idea if we can detect when to do it
  and come up with protocol.

What base NFSv4 protocol changes would be useful?
  Some things in RFC3010bis are not ideal for replication/migration,
  so we have always been open to minor revisions which would make
  this work better.  Ideas which have been brought forth include:

  - Change the definitions of the fh_expire_type as defined in:
    http://playground.sun.com/pub/nfsv4/nfsv4-wg-archive/2002/0078.html

  - Allow the client to know whether filehandles on the destination
    server are the same or not, based on the results of the transfer.
    The new info would likely have to be made available as more
    attributes the source server makes available.

---

From: Mike Eisler <[email-masked]>
Date: Fri, 23 Aug 2002 16:42:00 -0700

>   Advantage of per-message: we do it already with V4

I'm not aware of any way to use TLS without, at minimum, an integrity
check on each chunk of data that flows on the byte stream that TLS
is layered over. Typically, ifone doesn't want an integrity-protected
or encrypted channle, one doesn't use TLS. Think of http vs. https,
each with a password.

	-mre