draft-ietf-nfsv4-migration-issues-03.txt   draft-ietf-nfsv4-migration-issues-04.txt 
NFSv4 D. Noveck, Ed. NFSv4 D. Noveck, Ed.
Internet-Draft EMC Internet-Draft EMC
Intended status: Informational P. Shivam Intended status: Informational P. Shivam
Expires: September 22, 2013 C. Lever Expires: March 20, 2014 C. Lever
B. Baker B. Baker
ORACLE ORACLE
March 21, 2013 September 16, 2013
NFSv4 migration: Implementation experience and spec issues to resolve NFSv4 migration: Implementation experience and spec issues to resolve
draft-ietf-nfsv4-migration-issues-03 draft-ietf-nfsv4-migration-issues-04
Abstract Abstract
The migration feature of NFSv4 provides for moving responsibility for The migration feature of NFSv4 provides for moving responsibility for
a single filesystem from one server to another, without disruption to a single filesystem from one server to another, without disruption to
clients. Recent implementation experience has shown problems in the clients. Recent implementation experience has shown problems in the
existing specification for this feature. This document discusses the existing specification for this feature. This document discusses the
issues which have arisen, explores the options available for curing issues which have arisen, explores the options available for curing
the issues, and explains the choices made in updating the NFSv4.0 and the issues, and explains the choices made in updating the NFSv4.0 and
NFSv4.1 specifications, to address migration. NFSv4.1 specifications, to address migration.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 22, 2013. This Internet-Draft will expire on March 20, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 22 skipping to change at page 2, line 22
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. NFSv4.0 Implementation Experience . . . . . . . . . . . . . . 4 3. NFSv4.0 Implementation Experience . . . . . . . . . . . . . . 4
3.1. Implementation issues . . . . . . . . . . . . . . . . . . 4 3.1. Implementation issues . . . . . . . . . . . . . . . . . . 4
3.1.1. Failure to free migrated state on client reboot . . . 4 3.1.1. Failure to free migrated state on client reboot . . . 4
3.1.2. Server reboots resulting in a confused lease 3.1.2. Server reboots resulting in a confused lease
situation . . . . . . . . . . . . . . . . . . . . . . 5 situation . . . . . . . . . . . . . . . . . . . . . . 5
3.1.3. Client complexity issues . . . . . . . . . . . . . . 6 3.1.3. Client complexity issues . . . . . . . . . . . . . . 6
3.2. Sources of Protocol difficulties . . . . . . . . . . . . 8 3.2. Sources of Protocol difficulties . . . . . . . . . . . . 8
3.2.1. Issues with nfs_client_id4 generation and use . . . . 8 3.2.1. Issues with nfs_client_id4 generation and use . . . . 8
3.2.2. Issues with lease proliferation . . . . . . . . . . . 9 3.2.2. Issues with lease proliferation . . . . . . . . . . . 10
4. Issues to be resolved in NFSv4.0 . . . . . . . . . . . . . . 10 4. Issues to be resolved in NFSv4.0 . . . . . . . . . . . . . . 10
4.1. Possible changes to nfs_client_id4 client-string . . . . 10 4.1. Possible changes to nfs_client_id4 client-string . . . . 10
4.2. Possible changes to handle differing nfs_client_id4 4.2. Possible changes to handle differing nfs_client_id4
string values . . . . . . . . . . . . . . . . . . . . . . 11 string values . . . . . . . . . . . . . . . . . . . . . . 11
4.3. Other issues within migration-state sections . . . . . . 12 4.3. Possible changes to add a new operation . . . . . . . . . 12
4.4. Issues within other sections . . . . . . . . . . . . . . 12 4.4. Other issues within migration-state sections . . . . . . 12
4.5. Issues within other sections . . . . . . . . . . . . . . 13
5. Proposed resolution of NFSv4.0 protocol difficulties . . . . 13 5. Proposed resolution of NFSv4.0 protocol difficulties . . . . 13
5.1. Proposed changes: nfs_client_id4 client-string . . . . . 13 5.1. Proposed changes: nfs_client_id4 client-string . . . . . 13
5.2. Proposed changes: merged (vs. synchronized) leases . . . 13 5.2. Proposed changes: merged (vs. synchronized) leases . . . 14
5.3. Other proposed changes to migration-state sections . . . 15 5.3. Other proposed changes to migration-state sections . . . 16
5.3.1. Proposed changes: Client ID migration . . . . . . . . 15 5.3.1. Proposed changes: Client ID migration . . . . . . . . 16
5.3.2. Proposed changes: Callback re-establishment . . . . . 16 5.3.2. Proposed changes: Callback re-establishment . . . . . 16
5.3.3. Proposed changes: NFS4ERR_LEASE_MOVED rework . . . . 16 5.3.3. Proposed changes: NFS4ERR_LEASE_MOVED rework . . . . 17
5.4. Proposed changes to other sections . . . . . . . . . . . 17 5.4. Proposed changes to other sections . . . . . . . . . . . 17
5.4.1. Proposed changes: callback update . . . . . . . . . . 17 5.4.1. Proposed changes: callback update . . . . . . . . . . 17
5.4.2. Proposed changes: clientid4 handling . . . . . . . . 17 5.4.2. Proposed changes: clientid4 handling . . . . . . . . 18
5.4.3. Proposed changes: NFS4ERR_CLID_INUSE . . . . . . . . 19 5.4.3. Proposed changes: NFS4ERR_CLID_INUSE . . . . . . . . 19
6. Results of proposed changes for NFSv4.0 . . . . . . . . . . . 19 6. Results of proposed changes for NFSv4.0 . . . . . . . . . . . 20
6.1. Results: Failure to free migrated state on client reboot 20 6.1. Results: Failure to free migrated state on client reboot 20
6.2. Results: Server reboots resulting in confused lease 6.2. Results: Server reboots resulting in confused lease
situation . . . . . . . . . . . . . . . . . . . . . . . . 20 situation . . . . . . . . . . . . . . . . . . . . . . . . 21
6.3. Results: Client complexity issues . . . . . . . . . . . . 22 6.3. Results: Client complexity issues . . . . . . . . . . . . 22
6.4. Result summary . . . . . . . . . . . . . . . . . . . . . 23 6.4. Result summary . . . . . . . . . . . . . . . . . . . . . 23
7. Issues for NFSv4.1 . . . . . . . . . . . . . . . . . . . . . 23 7. Issues for NFSv4.1 . . . . . . . . . . . . . . . . . . . . . 23
7.1. Addressing state merger in NFSv4.1 . . . . . . . . . . . 23 7.1. Addressing state merger in NFSv4.1 . . . . . . . . . . . 24
7.2. Addressing pNFS relationship with migration . . . . . . . 24 7.2. Addressing pNFS relationship with migration . . . . . . . 25
7.3. Addressing server owner changes in NFSv4.1 . . . . . . . 24 7.3. Addressing server owner changes in NFSv4.1 . . . . . . . 25
8. Security Considerations . . . . . . . . . . . . . . . . . . . 26 8. Security Considerations . . . . . . . . . . . . . . . . . . . 26
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
11.1. Normative References . . . . . . . . . . . . . . . . . . 26 11.1. Normative References . . . . . . . . . . . . . . . . . . 27
11.2. Informative References . . . . . . . . . . . . . . . . . 27 11.2. Informative References . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
1. Introduction 1. Introduction
This document is in the informational category, and while the facts This document is in the informational category, and while the facts
it reports may have normative implications, any such normative it reports may have normative implications, any such normative
significance reflects the readers' preferences. For example, we may significance reflects the readers' preferences. For example, we may
report that the reboot of a client with migrated state results in report that the reboot of a client with migrated state results in
state not being promptly cleared and that this will prevent granting state not being promptly cleared and that this will prevent granting
of conflicting lock requests at least for the lease time, which is a of conflicting lock requests at least for the lease time, which is a
fact. While it is to be expected that client and server implementers fact. While it is to be expected that client and server implementers
skipping to change at page 4, line 45 skipping to change at page 4, line 48
3.1.1. Failure to free migrated state on client reboot 3.1.1. Failure to free migrated state on client reboot
The following sort of situation has proved troublesome: The following sort of situation has proved troublesome:
o A client C establishes a clientid4 C1 with server ABC specifying o A client C establishes a clientid4 C1 with server ABC specifying
an nfs_client_id4 with id string value "C-ABC" and boot verifier an nfs_client_id4 with id string value "C-ABC" and boot verifier
0x111. 0x111.
o The client begins to access files in filesystem F on server ABC, o The client begins to access files in filesystem F on server ABC,
resulting in generating stateids S1, S2, etc. under the lease for resulting in generating stateids S1, S2, etc. under the lease for
clientid C1. It may also access files on other filesystems on the clientid C1. It may also access files on other filesystems on the
same server. same server.
o The filesystem is migrated from server ABC to server XYZ. When o The filesystem is migrated from server ABC to server XYZ. When
transparent state migration is in effect, stateids S1 and S2 and transparent state migration is in effect, stateids S1 and S2 and
clientid4 C1 are now available for use by client C at server XYZ. clientid4 C1 are now available for use by client C at server XYZ.
o Client C reboots and attempts to access data on server XYZ, o Client C reboots and attempts to access data on server XYZ,
whether in filesystem F or another. It does a SETCLIENTID with an whether in filesystem F or another. It does a SETCLIENTID with an
nfs_client_id4 with id string value "C-XYZ" and boot verifier nfs_client_id4 with id string value "C-XYZ" and boot verifier
skipping to change at page 9, line 34 skipping to change at page 9, line 36
the client issues SETCLIENTID with the same id string to each the client issues SETCLIENTID with the same id string to each
network address of such a server, the server will think it is the network address of such a server, the server will think it is the
same client, and each successive SETCLIENTID will cause the server same client, and each successive SETCLIENTID will cause the server
to begin the process of removing the client's previous leased to begin the process of removing the client's previous leased
state. state.
In point of fact, a "SETCLIENTID with the same id string" sent to In point of fact, a "SETCLIENTID with the same id string" sent to
multiple network addresses will be treated as all from the same multiple network addresses will be treated as all from the same
client but will not "cause the server to begin the process of client but will not "cause the server to begin the process of
removing the client's previous leased state" unless the server removing the client's previous leased state" unless the server
believes it is a different instance of the same client, i.e. if the believes it is a different instance of the same client, i.e. if the
id string is the same and there is a different boot verifier. If the id string is the same and there is a different boot verifier. If the
client does not reboot, the verifier should not change. If it does client does not reboot, the verifier should not change. If it does
reboot, the verifier will change, and the server should "begin the reboot, the verifier will change, and the server should "begin the
process of removing the client's previous leased state. process of removing the client's previous leased state.
The situation of multiple SETCLIENTID requests received by a server The situation of multiple SETCLIENTID requests received by a server
on multiple network addresses is exactly the same, from the protocol on multiple network addresses is exactly the same, from the protocol
design point of view, as when multiple (i.e. duplicate) SETCLIENTID design point of view, as when multiple (i.e. duplicate) SETCLIENTID
requests are received by the server on a single network address. The requests are received by the server on a single network address. The
same protocol mechanisms that prevent erroneous state deletion in the same protocol mechanisms that prevent erroneous state deletion in the
latter case prevent it in the former case. There is no reason for latter case prevent it in the former case. There is no reason for
special handling of the multiple-network-appearance case, in this special handling of the multiple-network-appearance case, in this
regard. regard.
3.2.2. Issues with lease proliferation 3.2.2. Issues with lease proliferation
It is often felt that this is a consequence of the client-string It is often felt that this is a consequence of the client-string
construction issues, and it is certainly the case that the two are construction issues, and it is certainly the case that the two are
skipping to change at page 11, line 13 skipping to change at page 11, line 17
is not a reason to use the non-uniform approach but is better thought is not a reason to use the non-uniform approach but is better thought
of as an illustration of the fact that those using the uniform of as an illustration of the fact that those using the uniform
approach need to be aware of the possibility of server trunking and approach need to be aware of the possibility of server trunking and
its effect on server behavior. its effect on server behavior.
If it is possible to reliably infer the existence of trunking of If it is possible to reliably infer the existence of trunking of
server IP addresses from observed server behavior, use of the uniform server IP addresses from observed server behavior, use of the uniform
approach would be more desirable, although compatibility issues would approach would be more desirable, although compatibility issues would
have to be dealt with. have to be dealt with.
An alternative to having the client infer the existence of trunking
of IP server addresses, is to make this information available to the
client directly. See Section 4.3 for details.
It is always possible that a valid new reason will be found, but so It is always possible that a valid new reason will be found, but so
far none has been proposed. Given the history, the burden of proof far none has been proposed. Given the history, the burden of proof
should be on those asserting the validity of a proposed new reason. should be on those asserting the validity of a proposed new reason.
So we will assume for now that the "should" will have to go. The So we will assume for now that the "should" will have to go. The
question is what to replace it with. question is what to replace it with.
o We can't say "MUST NOT", despite the problems this raises for o We can't say "MUST NOT", despite the problems this raises for
migration since this is pretty late in the day for such a change. migration since this is pretty late in the day for such a change.
Many currently operating clients obey the existing "should". Many currently operating clients obey the existing "should".
skipping to change at page 12, line 9 skipping to change at page 12, line 14
Given the difficulties caused by having different nfs_client_id4 Given the difficulties caused by having different nfs_client_id4
client-string values for the same client, we have two choices: client-string values for the same client, we have two choices:
o Deprecate the existing treatment and basically say the client is o Deprecate the existing treatment and basically say the client is
on its own doing migration, if it follows it. on its own doing migration, if it follows it.
o Introduce a way of having the client provide client identity o Introduce a way of having the client provide client identity
information to the server, if it can be done compatibly while information to the server, if it can be done compatibly while
staying within the bounds of v4.0. staying within the bounds of v4.0.
4.3. Other issues within migration-state sections 4.3. Possible changes to add a new operation
It might be possible to return server-identity information to the
client, just as is done in NFSv4.1 by the response to the EXCHANGE_ID
operation. This could be done by a SETCLIENTID_PLUS optional
operation, which acts like SETCLIENTID, except that it returns server
identity information. Such information could be used by clients,
making it possible to for them to be aware of server trunking
relationships, rather than having to infer them from server behavior.
It had always been thought that protocol extensions such as this were
not appropriate to bis documents and other documents updating NFSv4
protocol definition RFC's. However, it is argued in [NFS-ext] that
protocol extensions, similar to those allowed between minor versions,
should be acceptable to correct mistakes within a minor version.
A decision to adopt this approach will depend on nfsv4 working group
discussion and would probably best be effected by means of a
standards-track document laying out a modified NFSv4 extension/
versioning model for all minor versions.
In view of the time to effect such changes, this approach is not
likely to be adopted in an RFC updating [RFC3530] or [RFC3530bis],
such as [migr-v4.0-update]. Still, it is worth keeping in mind, if
implementers have difficulties inferring trunking relationships using
the techniques discussed there.
4.4. Other issues within migration-state sections
There are a number of issues where the existing text is unclear and/ There are a number of issues where the existing text is unclear and/
or wrong and needs to be fixed in some way. or wrong and needs to be fixed in some way.
o Lack of clarity in the discussion of moving clientids (as well as o Lack of clarity in the discussion of moving clientids (as well as
stateids) as part of moving state for migration. stateids) as part of moving state for migration.
o The discussion of synchronized leases is wrong in that there is no o The discussion of synchronized leases is wrong in that there is no
way to determine (in the current spec) when leases are for the way to determine (in the current spec) when leases are for the
same client and also wrong in suggesting a benefit from leases same client and also wrong in suggesting a benefit from leases
synchronized at the point of transfer. What is needed is merger synchronized at the point of transfer. What is needed is merger
of leases, which is necessary to keep client complexity of leases, which is necessary to keep client complexity
requirements from getting out of hand. requirements from getting out of hand.
o Lack of clarity in the discussion of LEASE_MOVED handling, o Lack of clarity in the discussion of LEASE_MOVED handling,
including failure to fully address situations in which transparent including failure to fully address situations in which transparent
state migration did not occur. state migration did not occur.
4.4. Issues within other sections 4.5. Issues within other sections
There are a number of cases in which certain sections, not There are a number of cases in which certain sections, not
specifically related to migration, require additional clarification. specifically related to migration, require additional clarification.
This is generally because text that is clear in a context in which This is generally because text that is clear in a context in which
leases and clientids are created in one place and live there forever leases and clientids are created in one place and live there forever
may need further refinement in the more dynamic environment that may need further refinement in the more dynamic environment that
arises as part of migration. arises as part of migration.
Some examples: Some examples:
skipping to change at page 13, line 46 skipping to change at page 14, line 32
o It should describe the compatibility issues that might cause o It should describe the compatibility issues that might cause
servers to be incompatible with the uniform approach and give servers to be incompatible with the uniform approach and give
guidance about dealing with these. guidance about dealing with these.
o It should describe how a client using the uniform approach might o It should describe how a client using the uniform approach might
use server behavior to determine server address trunking patterns. use server behavior to determine server address trunking patterns.
o It should present a clearer and more complete set of o It should present a clearer and more complete set of
recommendations to guide client string construction. recommendations to guide client string construction.
5.2. Proposed changes: merged (vs. synchronized) leases 5.2. Proposed changes: merged (vs. synchronized) leases
The current definitive definitions of the NFSv4.0 protocol, [RFC3530] The current definitive definitions of the NFSv4.0 protocol, [RFC3530]
and [RFC3530bis] both agree. The section entitled "Migration and and [RFC3530bis] both agree. The section entitled "Migration and
State" says: State" says:
As part of the transfer of information between servers, leases As part of the transfer of information between servers, leases
would be transferred as well. The leases being transferred to the would be transferred as well. The leases being transferred to the
new server will typically have a different expiration time from new server will typically have a different expiration time from
those for the same client, previously on the old server. To those for the same client, previously on the old server. To
maintain the property that all leases on a given server for a maintain the property that all leases on a given server for a
skipping to change at page 15, line 15 skipping to change at page 15, line 50
o Servers SHOULD provide automatic lease merger during state o Servers SHOULD provide automatic lease merger during state
migration so that clients using the uniform id approach get the migration so that clients using the uniform id approach get the
support automatically. support automatically.
If the clients and the servers obey the SHOULD's, having more than a If the clients and the servers obey the SHOULD's, having more than a
single lease for a given client-server pair will be a transient single lease for a given client-server pair will be a transient
situation, cleaned up as part of adapting to use of migrated state. situation, cleaned up as part of adapting to use of migrated state.
Since clients and servers will be a mixture of old and new and Since clients and servers will be a mixture of old and new and
because nothing is a MUST we have to ensure that no combination will because nothing is a MUST we have to ensure that no combination will
show worse behavior than is exhibited by current (i.e. old) clients show worse behavior than is exhibited by current (i.e. old) clients
and servers. and servers.
5.3. Other proposed changes to migration-state sections 5.3. Other proposed changes to migration-state sections
5.3.1. Proposed changes: Client ID migration 5.3.1. Proposed changes: Client ID migration
The current definitive definitions of the NFSv4.0 protocol, [RFC3530] The current definitive definitions of the NFSv4.0 protocol, [RFC3530]
and [RFC3530bis] both agree. The section entitled "Migration and and [RFC3530bis] both agree. The section entitled "Migration and
State" says: State" says:
skipping to change at page 17, line 27 skipping to change at page 18, line 15
o Make it clear that after migration there are confirmed entries for o Make it clear that after migration there are confirmed entries for
transferred clientid4/nfs_client_id4 pairs. transferred clientid4/nfs_client_id4 pairs.
o Be explicit in the sections headed "otherwise," in the o Be explicit in the sections headed "otherwise," in the
descriptions of SETCLIENTID and SETCLIENTID_CONFIRM, that these descriptions of SETCLIENTID and SETCLIENTID_CONFIRM, that these
don't apply in the cases we are concerned about. don't apply in the cases we are concerned about.
5.4.2. Proposed changes: clientid4 handling 5.4.2. Proposed changes: clientid4 handling
To address both of the clientid4-related issues mentioned in To address both of the clientid4-related issues mentioned in
Section 4.4, we propose replacing the last three paragraphs of the Section 4.5, we propose replacing the last three paragraphs of the
section entitled "Client ID" with the following: section entitled "Client ID" with the following:
Once a SETCLIENTID and SETCLIENTID_CONFIRM sequence has Once a SETCLIENTID and SETCLIENTID_CONFIRM sequence has
successfully completed, the client uses the shorthand client successfully completed, the client uses the shorthand client
identifier, of type clientid4, instead of the longer and less identifier, of type clientid4, instead of the longer and less
compact nfs_client_id4 structure. This shorthand client compact nfs_client_id4 structure. This shorthand client
identifier (a client ID) is assigned by the server and should be identifier (a client ID) is assigned by the server and should be
chosen so that it will not conflict with a client ID previously chosen so that it will not conflict with a client ID previously
assigned by same server. This applies across server restarts or assigned by same server. This applies across server restarts or
reboots. reboots.
skipping to change at page 18, line 18 skipping to change at page 19, line 6
* A server reboot causing loss of the server's knowledge of the * A server reboot causing loss of the server's knowledge of the
client client
* Client error sending an incorrect clientid4 or a valid * Client error sending an incorrect clientid4 or a valid
clientid4 to the wrong server. clientid4 to the wrong server.
* Loss of lease state due to lease expiration. * Loss of lease state due to lease expiration.
* Client or server error causing the server to believe that the * Client or server error causing the server to believe that the
client has rebooted (i.e. receiving a SETCLIENTID with an client has rebooted (i.e. receiving a SETCLIENTID with an
nfs_client_id4 which has a matching id string and a non- nfs_client_id4 which has a matching id string and a non-
matching boot verifier). matching boot verifier).
* Migration of all state under the associated lease causes its * Migration of all state under the associated lease causes its
non-existence to be recognized on the source server. non-existence to be recognized on the source server.
* Merger of state under the associated lease with another lease * Merger of state under the associated lease with another lease
under a different clientid causes the clientid4 serving as the under a different clientid causes the clientid4 serving as the
source of the merge to cease being recognized on its server. source of the merge to cease being recognized on its server.
skipping to change at page 20, line 5 skipping to change at page 20, line 38
returns a NFS4ERR_CLID_INUSE error" should be expanded to read returns a NFS4ERR_CLID_INUSE error" should be expanded to read
"then the server returns a NFS4ERR_CLID_INUSE error, since use of "then the server returns a NFS4ERR_CLID_INUSE error, since use of
a single client with multiple principals is not allowed." a single client with multiple principals is not allowed."
6. Results of proposed changes for NFSv4.0 6. Results of proposed changes for NFSv4.0
The purpose of this section is to examine the troubling results The purpose of this section is to examine the troubling results
reported in Section 3.1. We will look at the scenarios as they would reported in Section 3.1. We will look at the scenarios as they would
be handled within the proposal. be handled within the proposal.
Because the choice of uniform vs. non-uniform nfs_client_id4 id Because the choice of uniform vs. non-uniform nfs_client_id4 id
strings is a "SHOULD" in these cases, we will designate clients that strings is a "SHOULD" in these cases, we will designate clients that
follow this recommendation by SHOULD-UF-CID. follow this recommendation by SHOULD-UF-CID.
We will also have to take account of any merger-related "SHOULD" We will also have to take account of any merger-related "SHOULD"
clauses to better understand how they have addressed the issues seen. clauses to better understand how they have addressed the issues seen.
We abbreviate as follows: We abbreviate as follows:
o SHOULD-SVR-AM refers to the server obeying the SHOULD which o SHOULD-SVR-AM refers to the server obeying the SHOULD which
RECOMMENDS that they merge leases with identical nfs_client_id4 id RECOMMENDS that they merge leases with identical nfs_client_id4 id
strings and boot verifiers. strings and boot verifiers.
skipping to change at page 20, line 29 skipping to change at page 21, line 14
Let's look at the troublesome situation cited in Section 3.1.1. We Let's look at the troublesome situation cited in Section 3.1.1. We
have already seen what happens when SHOULD-UF-CID does not hold. Now have already seen what happens when SHOULD-UF-CID does not hold. Now
let's look at the situation in which SHOULD-UF-CID holds, whether let's look at the situation in which SHOULD-UF-CID holds, whether
SHOULD-SVR-AM is in effect or not. SHOULD-SVR-AM is in effect or not.
o A client C establishes a clientid4 C1 with server ABC specifying o A client C establishes a clientid4 C1 with server ABC specifying
an nfs_client_id4 with id string value "C" and boot verifier an nfs_client_id4 with id string value "C" and boot verifier
0x111. 0x111.
o The client begins to access files in filesystem F on server ABC, o The client begins to access files in filesystem F on server ABC,
resulting in generating stateids S1, S2, etc. under the lease for resulting in generating stateids S1, S2, etc. under the lease for
clientid C1. It may also access files on other filesystems on the clientid C1. It may also access files on other filesystems on the
same server. same server.
o The filesystem is migrated from ABC to server XYZ. When o The filesystem is migrated from ABC to server XYZ. When
transparent state migration is in effect, stateids S1 and S2 and transparent state migration is in effect, stateids S1 and S2 and
lease {0x111, "C", C1} are now available for use by client C at lease {0x111, "C", C1} are now available for use by client C at
server XYZ. server XYZ.
o Client C reboots and attempts to access data on server XYZ, o Client C reboots and attempts to access data on server XYZ,
whether in filesystem F or another. It does a SETCLIENTID with an whether in filesystem F or another. It does a SETCLIENTID with an
skipping to change at page 25, line 28 skipping to change at page 26, line 19
values may be different on subsequent EXCHANGE_ID requests made to values may be different on subsequent EXCHANGE_ID requests made to
the same network address. the same network address.
In most cases such reconfiguration events will be disruptive and In most cases such reconfiguration events will be disruptive and
indicate that an IP address formerly connected to one server is indicate that an IP address formerly connected to one server is
now connected to an entirely different one. now connected to an entirely different one.
Some guidelines on client handling of such situations follow: Some guidelines on client handling of such situations follow:
* When eir_server_scope changes, the client has no assurance that * When eir_server_scope changes, the client has no assurance that
any id's it obtained previously (e.g. file handles) can be any id's it obtained previously (e.g. file handles) can be
validly used on the new server, and, even if the new server validly used on the new server, and, even if the new server
accepts them, there is no assurance that this is not due to accepts them, there is no assurance that this is not due to
accident. Thus it is best to treat all such state as lost/ accident. Thus it is best to treat all such state as lost/
stale although a client may assume that the probability of stale although a client may assume that the probability of
inadvertent acceptance is low and treat this situation as inadvertent acceptance is low and treat this situation as
within the next case. within the next case.
* When eir_server_scope remains the same and * When eir_server_scope remains the same and
eir_server_owner.so_major_id changes, the client can use eir_server_owner.so_major_id changes, the client can use
filehandles it has and attempt reclaims. It may find that filehandles it has and attempt reclaims. It may find that
skipping to change at page 26, line 44 skipping to change at page 27, line 34
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., [RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R.,
Beame, C., Eisler, M., and D. Noveck, "Network File System Beame, C., Eisler, M., and D. Noveck, "Network File System
(NFS) version 4 Protocol", RFC 3530, April 2003. (NFS) version 4 Protocol", RFC 3530, April 2003.
[RFC3530bis] [RFC3530bis]
Haynes, T., Ed. and D. Noveck, Ed., "Network File System Haynes, T., Ed. and D. Noveck, Ed., "Network File System
(NFS) Version 4 Protocol", 2011, <http://www.ietf.org/id/ (NFS) Version 4 Protocol", 2013, <http://www.ietf.org/id/
draft-ietf-nfsv4-rfc3530bis-25.txt>. draft-ietf-nfsv4-rfc3530bis-27.txt>.
Work in progress. Work in progress.
[RFC5661] Shepler, S., Eisler, M., and D. Noveck, "Network File [RFC5661] Shepler, S., Eisler, M., and D. Noveck, "Network File
System (NFS) Version 4 Minor Version 1 Protocol", RFC System (NFS) Version 4 Minor Version 1 Protocol", RFC
5661, January 2010. 5661, January 2010.
11.2. Informative References 11.2. Informative References
[NFS-ext] Noveck, D., "NFS Protocol Extension: Retrospect and
Prospect", 2013, <http://www.ietf.org/id/draft-dnoveck-
nfs-extension-00.txt>.
Work in progress.
[migr-v4.0-update] [migr-v4.0-update]
Noveck, D., Ed., Shivam, P., Lever, C., and B. Baker, Noveck, D., Ed., Shivam, P., Lever, C., and B. Baker,
"NFSv4.0 migration: Specification Update", 2013, <http:// "NFSv4.0 migration: Specification Update", 2013, <http://
www.ietf.org/id/draft-ietf-nfsv4-rfc3530-migration- www.ietf.org/id/draft-ietf-nfsv4-rfc3530-migration-
update-01.txt>. update-02.txt>.
Work in progress. Work in progress.
Authors' Addresses Authors' Addresses
David Noveck (editor) David Noveck (editor)
EMC Corporation EMC Corporation
228 South Street 228 South Street
Hopkinton, MA 01748 Hopkinton, MA 01748
US US
 End of changes. 30 change blocks. 
37 lines changed or deleted 75 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/