Text is checked into CVS. I put some text in multi_server_ns chapter.
Feel free to nuke.

Note that I'm still planning to do the changes in the multi_server_ns chapter
to interface with this change.  I'm assuming that Mike will make the changes
in the core infrastructure chapter.

I think it makes sense to move this over to Mike.  I'm assuming that the
absence of comment on my proposal can be interpreted as at least consensus
to draft the appropriate text.

assign to dave based on discussion in wg concall

Yes.  Really it includes any transition to a different replica although by far
the most common motivation to switch replicas is failure of an existing one.  In
that context, you may have two different servers front-ending a clustered fs in
which case you have two replicas even though though there is really one replica
from the  fs point of view.

Dave, when you refer to failover, do mean when a client fails over
to a different replica?

One part of the solution here might involve an nfs4serevrid4.  In light of that
I'm closing 42 and combning that issue with this one.

There are a number of inter-related issues regarding the seesions trunking
model for sessions.  Since these issues are so tightly inter-related, it is 
assumed that a single integrated solution will need to address all of them
together and so they are being disucssed as a single "issue".

The current sessions text assumes that the client has externally given (from
DNS or otherwise) presumed correct information about when two communications 
endpoints connect to the same server, allowing multiple connection sfor the
same session or multiple session to the same server to be established.

The problem with this approach is that there will be cases in which such
information is not available, and trying to protect against them, in turn
causes further difficulties for migration and failover in clustered 
environments.

In particular, if a client establishes a session to two different IP addresses,
without the knowledge that they terminate at the same server, confusion can
occur if the client and the server have different views of the situation.  
In particular, if the server thinks that he is dealing with a single client
while the client has no way to know that what he thinks are two servers are
in fact one, state management can become totally confused.

In order to prevent such a situation, v4.0 has established the rule that 
the nfs_client_id4 should be varied based on the server IP address.  This
causes the server and the client to have a common view of the situation.
The server thinks that there are two clients while the client thinks there
are two servers.  The result, while at variance with reality, can work.

The problem is that it creates difficulties for failover.  If a client fails
over to another server clustered with the first, it needs to be recognized
as the same client, for the purposes of reboot detection etc.  This is what
the current strategy of changing nfs_cleint_id4's breaks.

We need to have some way of the server declaring its identity to the client
so as to find trunking situations, even without external knowledge (even though
the external knowledge is helpful for finding the alternate paths).  This would
allow the client to declare his own identity with a fixed (i.e. not varying
based on the destination server) nfs_client_id4, and so avoid not having
a good grasp of client identity in clustered server situations.