draft-ietf-nfsv4-migration-issues-01.txt   draft-ietf-nfsv4-migration-issues-02.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: January 8, 2013 C. Lever Expires: March 26, 2013 C. Lever
B. Baker B. Baker
ORACLE ORACLE
July 7, 2012 September 22, 2012
NFSv4 migration: Implementation experience and spec issues to resolve NFSv4 migration: Implementation experience and spec issues to resolve
draft-ietf-nfsv4-migration-issues-01 draft-ietf-nfsv4-migration-issues-02
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 and explores the options available for issues which have arisen and explores the options available for
curing the issues via clarification and correction of the NFSv4.0 and curing the issues via clarification and correction of the NFSv4.0 and
NFSv4.1 specifications. NFSv4.1 specifications.
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 January 8, 2013. This Internet-Draft will expire on March 26, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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 35 skipping to change at page 2, line 35
4.2. Possible changes to handle differing nfs_client_id4 4.2. Possible changes to handle differing nfs_client_id4
string values . . . . . . . . . . . . . . . . . . . . . . 12 string values . . . . . . . . . . . . . . . . . . . . . . 12
4.3. Other issues within migration-state sections . . . . . . . 13 4.3. Other issues within migration-state sections . . . . . . . 13
4.4. Issues within other sections . . . . . . . . . . . . . . . 13 4.4. Issues within other sections . . . . . . . . . . . . . . . 13
5. Proposed resolution of NFSv4.0 protocol difficulties . . . . . 14 5. Proposed resolution of NFSv4.0 protocol difficulties . . . . . 14
5.1. Proposed changes: nfs_client_id4 client-string . . . . . . 14 5.1. Proposed changes: nfs_client_id4 client-string . . . . . . 14
5.2. Client-string Approaches (AS PROPOSED) . . . . . . . . . . 14 5.2. Client-string Approaches (AS PROPOSED) . . . . . . . . . . 14
5.2.1. Non-Uniform Client-string Approach . . . . . . . . . . 16 5.2.1. Non-Uniform Client-string Approach . . . . . . . . . . 16
5.2.2. Uniform Client-string Approach . . . . . . . . . . . . 16 5.2.2. Uniform Client-string Approach . . . . . . . . . . . . 16
5.2.3. Mixing Client-string Approaches . . . . . . . . . . . 18 5.2.3. Mixing Client-string Approaches . . . . . . . . . . . 18
5.2.4. Trunking Determination using Uniform Client-strings . 19 5.2.4. Trunking Determination when using Uniform
Client-strings . . . . . . . . . . . . . . . . . . . . 19
5.3. Proposed changes: merged (vs. synchronized) leases . . . . 24 5.3. Proposed changes: merged (vs. synchronized) leases . . . . 24
5.4. Other proposed changes to migration-state sections . . . . 25 5.4. Other proposed changes to migration-state sections . . . . 26
5.4.1. Proposed changes: Client ID migration . . . . . . . . 25 5.4.1. Proposed changes: Client ID migration . . . . . . . . 26
5.4.2. Proposed changes: Callback re-establishment . . . . . 26 5.4.2. Proposed changes: Callback re-establishment . . . . . 27
5.4.3. Proposed changes: NFS4ERR_LEASE_MOVED rework . . . . . 26 5.4.3. Proposed changes: NFS4ERR_LEASE_MOVED rework . . . . . 27
5.5. Proposed changes to other sections . . . . . . . . . . . . 27 5.5. Proposed changes to other sections . . . . . . . . . . . . 28
5.5.1. Proposed changes: callback update . . . . . . . . . . 27 5.5.1. Proposed changes: callback update . . . . . . . . . . 28
5.5.2. Proposed changes: clientid4 handling . . . . . . . . . 27 5.5.2. Proposed changes: clientid4 handling . . . . . . . . . 28
5.5.3. Proposed changes: NFS4ERR_CLID_INUSE . . . . . . . . . 29 5.5.3. Proposed changes: NFS4ERR_CLID_INUSE . . . . . . . . . 29
5.6. Migration, Replication and State (AS PROPOSED) . . . . . . 29 5.6. Migration, Replication and State (AS PROPOSED) . . . . . . 30
5.6.1. Migration and State . . . . . . . . . . . . . . . . . 30 5.6.1. Migration and State . . . . . . . . . . . . . . . . . 31
5.6.2. Replication and State . . . . . . . . . . . . . . . . 32 5.6.2. Replication and State . . . . . . . . . . . . . . . . 33
5.6.3. Notification of Migrated Lease . . . . . . . . . . . . 32 5.6.3. Notification of Migrated Lease . . . . . . . . . . . . 33
5.6.4. Migration and the Lease_time Attribute . . . . . . . . 35 5.6.4. Migration and the Lease_time Attribute . . . . . . . . 35
6. Results of proposed changes for NFSv4.0 . . . . . . . . . . . 35
6. Results of proposed changes for NFSv4.0 . . . . . . . . . . . 36
6.1. Results: Failure to free migrated state on client 6.1. Results: Failure to free migrated state on client
reboot . . . . . . . . . . . . . . . . . . . . . . . . . . 36 reboot . . . . . . . . . . . . . . . . . . . . . . . . . . 37
6.2. Results: Server reboots resulting in confused lease 6.2. Results: Server reboots resulting in confused lease
situation . . . . . . . . . . . . . . . . . . . . . . . . 36 situation . . . . . . . . . . . . . . . . . . . . . . . . 37
6.3. Results: Client complexity issues . . . . . . . . . . . . 38 6.3. Results: Client complexity issues . . . . . . . . . . . . 38
6.4. Result summary . . . . . . . . . . . . . . . . . . . . . . 39 6.4. Result summary . . . . . . . . . . . . . . . . . . . . . . 39
7. Issues for NFSv4.1 . . . . . . . . . . . . . . . . . . . . . . 39 7. Issues for NFSv4.1 . . . . . . . . . . . . . . . . . . . . . . 39
7.1. Addressing state merger in NFSv4.1 . . . . . . . . . . . . 39 7.1. Addressing state merger in NFSv4.1 . . . . . . . . . . . . 40
7.2. Addressing pNFS relationship with migration . . . . . . . 40 7.2. Addressing pNFS relationship with migration . . . . . . . 41
7.3. Addressing server owner changes in NFSv4.1 . . . . . . . . 40 7.3. Addressing server owner changes in NFSv4.1 . . . . . . . . 41
8. Lock State and File System Transitions (AS PROPOSED) . . . . . 41 8. Lock State and File System Transitions (AS PROPOSED) . . . . . 42
8.1. File System Transitions with Matching Server Scopes . . . 42 8.1. File System Transitions with Matching Server Scopes . . . 43
8.2. File System Transitions with Non-Matching Server Scopes . 43 8.2. File System Transitions with Non-Matching Server Scopes . 44
8.3. FS Transitions Involving Reobtaining Locking State . . . . 44 8.3. FS Transitions Involving Reobtaining Locking State . . . . 45
9. Security Considerations . . . . . . . . . . . . . . . . . . . 45 9. Security Considerations . . . . . . . . . . . . . . . . . . . 46
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 45 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 46
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 46 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 47
12.1. Normative References . . . . . . . . . . . . . . . . . . . 46 12.1. Normative References . . . . . . . . . . . . . . . . . . . 47
12.2. Informative References . . . . . . . . . . . . . . . . . . 46 12.2. Informative References . . . . . . . . . . . . . . . . . . 47
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 46 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 47
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 12, line 9 skipping to change at page 12, line 9
o Keep a reason we know is invalid. o Keep a reason we know is invalid.
o Keep saying "should" without giving a reason. o Keep saying "should" without giving a reason.
What are often presented as reasons that motivate use of the non- What are often presented as reasons that motivate use of the non-
uniform approach always turn out to be cases in which, if the uniform uniform approach always turn out to be cases in which, if the uniform
approach were used, the server will treat a client which accesses approach were used, the server will treat a client which accesses
that server via two different IP addresses as part of a single that server via two different IP addresses as part of a single
client, as it in fact is. This may be disconcerting to a client client, as it in fact is. This may be disconcerting to a client
unaware that the two IP addresses connect to the same server. This unaware that the two IP addresses connect to the same server. This
is thus not a reason to use the non-uniform approach but rather an is not a reason to use the non-uniform approach but is better thought
illustration of the fact that those using the uniform approach must of as an illustration of the fact that those using the uniform
use server behavior to determine whether any trunking of IP addresses approach need to be aware of the possibility of server trunking and
exists, as is described in Section 5.2.2. its effect on server behavior. The use of observed server behavior
to determine whether any trunking of IP addresses exists is described
in Section 5.2.2.
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.
skipping to change at page 19, line 37 skipping to change at page 19, line 37
uniform client-string approach as the default, but allow a mount uniform client-string approach as the default, but allow a mount
option to specify use of the non-uniform client-string approach for option to specify use of the non-uniform client-string approach for
particular mount points, as long as such mount points are not used particular mount points, as long as such mount points are not used
when migration is to be supported. when migration is to be supported.
In the case in which the same server has multiple mounts, and both In the case in which the same server has multiple mounts, and both
approaches are specified for the same server, the client could have approaches are specified for the same server, the client could have
multiple clientids corresponding to the same server, one for each multiple clientids corresponding to the same server, one for each
approach and would then have to keep these separate. approach and would then have to keep these separate.
5.2.4. Trunking Determination using Uniform Client-strings 5.2.4. Trunking Determination when using Uniform Client-strings
This section provides an example of how trunking determination could This section provides an example of how trunking determination could
be done by a client following the uniform client-string approach be done by a client following the uniform client-string approach
(whether this is used for all mounts or not). Clients need not (whether this is used for all mounts or not). Clients need not
follow this procedure but implementers should make sure that the follow this procedure but implementers should make sure that the
issues dealt with by this procedure are all properly addressed. issues dealt with by this procedure are all properly addressed.
We need to clarify the various possible purposes of trunking We need to clarify the various possible purposes of trunking
determination and the corresponding requirements as to server determination and the corresponding requirements as to server
behavior. The following points should be noted: behavior. The following points should be noted:
skipping to change at page 20, line 47 skipping to change at page 20, line 47
internal recording of clientid4 values needs to include, whether internal recording of clientid4 values needs to include, whether
explicitly or implicitly, identification of the server from which the explicitly or implicitly, identification of the server from which the
clientid4 was received so that one always has a (server, clientid4) clientid4 was received so that one always has a (server, clientid4)
pair. Two such pairs from different servers are always considered pair. Two such pairs from different servers are always considered
distinct even when the clientid4 values are the same, as they may distinct even when the clientid4 values are the same, as they may
occasionally be. occasionally be.
In order to make this approach work, the client must have accessible, In order to make this approach work, the client must have accessible,
for each nfs4_client_id4 used by the uniform approach (only one in for each nfs4_client_id4 used by the uniform approach (only one in
general) a list of all server IP addresses, together with the general) a list of all server IP addresses, together with the
associated clientid4 values and authentication flavors. As a part of associated clientid4 values, SETCLIENTID principals and
the associated data structures, there should be the ability to mark a authentication flavors. As a part of the associated data structures,
server IP structure as having the same server as another and to mark there should be the ability to mark a server IP structure as having
an IP-address as currently unresolved. One way to do this is to a the same server as another and to mark an IP-address as currently
allow each such entry to point to another with the pointer value unresolved. One way to do this is to a allow each such entry to
being one of: point to another with the pointer value being one of:
o A pointer to another entry for an IP address associated with the o A pointer to another entry for an IP address associated with the
same server, where that IP address is the first one referenced to same server, where that IP address is the first one referenced to
access that server. access that server.
o A pointer to the current entry if there is no earlier IP address o A pointer to the current entry if there is no earlier IP address
associated with the same server, i.e. where the current IP address associated with the same server, i.e. where the current IP address
is the first one referenced to access that server. We'll refer to is the first one referenced to access that server. We'll refer to
such an IP address as the lead IP address for a given server. such an IP address as the lead IP address for a given server.
skipping to change at page 21, line 36 skipping to change at page 21, line 36
returned, the data structure can be searched for a matching clientid4 returned, the data structure can be searched for a matching clientid4
and if such is found, further processing can be done to determine and if such is found, further processing can be done to determine
whether the clientid4 match is accidental, or the result of trunking. whether the clientid4 match is accidental, or the result of trunking.
In this algorithm, when SETCLIENTID is done it will use the common In this algorithm, when SETCLIENTID is done it will use the common
nfs_client_id4 and specify the current target IP address as part of nfs_client_id4 and specify the current target IP address as part of
the callback parameters. We call the clientid4 and SETCLIENTID the callback parameters. We call the clientid4 and SETCLIENTID
verifier returned by this operation XC and XV. verifier returned by this operation XC and XV.
Note that when the client has done previous SETCLIENTID's, to any IP Note that when the client has done previous SETCLIENTID's, to any IP
addresses, with more than one authentication flavor, we have the addresses, with more than one principal or authentication flavor, we
possibility of receiving NFS4ERR_CLID_INUSE, since we do not yet know have the possibility of receiving NFS4ERR_CLID_INUSE, since we do not
which of our connections with existing IP addresses might be trunked yet know which of our connections with existing IP addresses might be
with our current one. In the event that the SETCLIENID fails with trunked with our current one. In the event that the SETCLIENTID
NFS4ERR_CLID_INUSE, one must try all other authentication flavors fails with NFS4ERR_CLID_INUSE, one must try all other combinations of
currently in use and eventually one will be correct and not return principals and authentication flavors currently in use and eventually
NFS4ERR_CLID_INUSE. one will be correct and not return NFS4ERR_CLID_INUSE.
Note that at this point, no SETCLIENTID_CONFIRM has yet been done. Note that at this point, no SETCLIENTID_CONFIRM has yet been done.
This is because our SETCLIENTID has either established a new This is because our SETCLIENTID has either established a new
clientid4 on a previously unknown server or changed the callback clientid4 on a previously unknown server or changed the callback
parameters on a clientid4 associated with some already known server. parameters on a clientid4 associated with some already known server.
Given that we don't want to confirm something that we are not sure we Given that we don't want to confirm something that we are not sure we
want to happen, what is to be done next depends on information about want to happen, what is to be done next depends on information about
existing clientid4's. existing clientid4's.
o If no matching clientid4 is found, the IP address X and clientid4 o If no matching clientid4 is found, the IP address X and clientid4
skipping to change at page 22, line 29 skipping to change at page 22, line 29
addresses with a matching clientid4, the address will have been addresses with a matching clientid4, the address will have been
resolved: either it will be part of the same server as a new IP resolved: either it will be part of the same server as a new IP
address to be added to an existing set of IP addresses for a address to be added to an existing set of IP addresses for a
server, or it will be recognized as a new server. At the point at server, or it will be recognized as a new server. At the point at
which this determination is made, the unresolved indication is which this determination is made, the unresolved indication is
cleared and any suspended SETCLIENTID processing is restarted cleared and any suspended SETCLIENTID processing is restarted
So for each lead IP address IPn with a clientid4 matching XC, the So for each lead IP address IPn with a clientid4 matching XC, the
following steps are done. following steps are done.
o If the authentication flavor for IPn does not match that for X, o If the principal for IPn does not match that for X, the IP address
the IP address is skipped, since it is impossible or IPn and X to is skipped, since it is impossible or IPn and X to be trunked in
be trunked in these circumstances. This avoids any possibility these circumstances. If the principal does match but the
that NFS4ERR_CLID_INUSE will be returned for the SETCLIENTID and authentication flavor does not, the authentication flavor already
SETCLIENID_CONFIRM to be done below, as long as the server(s) at used should be used for address X as well. This will avoid any
IP addresses IPn and X are correctly implemented. possibility that NFS4ERR_CLID_INUSE will be returned for the
SETCLIENTID and SETCLIENTID_CONFIRM to be done below, as long as
the server(s) at IP addresses IPn and X are correctly implemented.
o A SETCLIENTID is done to update the callback parameters to reflect o A SETCLIENTID is done to update the callback parameters to reflect
the possibility that X will be marked as associated with the the possibility that X will be marked as associated with the
server whose lead IP address is IPn. The specific callback server whose lead IP address is IPn. The specific callback
parameters chosen, in terms of cb_client4 and callback_ident, are parameters chosen, in terms of cb_client4 and callback_ident, are
up to the client and should reflect its preferences as to callback up to the client and should reflect its preferences as to callback
handling for the common clientid, in the event that X and IPn are handling for the common clientid, in the event that X and IPn are
trunked together. So assume that we do that SETCLIENTID on IP trunked together. So assume that we do that SETCLIENTID on IP
address IPn and get back a setclientid_confirm value (in the form address IPn and get back a setclientid_confirm value (in the form
of a verifier4) SCn. of a verifier4) SCn.
skipping to change at page 23, line 27 skipping to change at page 23, line 29
confirmed. So we go on to the next IPn, until we run out of them. confirmed. So we go on to the next IPn, until we run out of them.
If it happens that we run out of potential matches, then we can If it happens that we run out of potential matches, then we can
treat X as connected to a distinct server and then update and treat X as connected to a distinct server and then update and
confirm its callback parameters on that basis. confirm its callback parameters on that basis.
Note here that we may set a number of possible values for the Note here that we may set a number of possible values for the
callback parameters to be used for XC, one for the possibility that X callback parameters to be used for XC, one for the possibility that X
is untrunked, and others for each potential match with an existing is untrunked, and others for each potential match with an existing
IPn. Although there are multiple such updates at most one will be IPn. Although there are multiple such updates at most one will be
confirmed and, if X is untrunked, its original callback parameters confirmed and, if X is untrunked, its original callback parameters
will be put in effect by its SETCLIENID_CONFIRM. will be put in effect by its SETCLIENTID_CONFIRM.
The procedure described above must be performed so as to exclude the
possibility that multiple SETCLIENTID's, done to different server IP
addresses and returning the same clietid4 might "race" in such a
fashion that there is no explicit determination of whether they
correspond to the same server. The following possibilities for
serialization are all valid and implementers may choose among them
based on a tradeoff between performance and complexity. They are
listed in order of increasing parallelism:
o An NFSv4.0 client might serialize all instances of SETCLIENTID/
SETCLIENTID_CONFIRM processing, either directly or by serializing
mount operations involving use of NFSv4.0. While doing so will
prevent the races mentioned above, this degree of serialization
can cause performance issues when there is a high volume of mount
operations.
o One might instead serialize the period of processing that begins
when the clientid4 received from the server is processed and ends
when all trunking determination for that server is completed.
This prevents the races mentioned above, without adding to delay
except when trunking determination is common.
o One might avoid much of the serialization implied above, by
allowing trunking determination for distinct clientid4 values to
happen in parallel, with serialization of trunking determination
happening independently for each distinct clientid4 value.
The procedure above has made no explicit mention of the possibility The procedure above has made no explicit mention of the possibility
that server reboot can occur at any time. To address this that server reboot can occur at any time. To address this
possibility the client should periodically use the clientid4 XC in possibility the client should periodically use the clientid4 XC in
RENEW operations, directed to both the IP address X and the current RENEW operations, directed to both the IP address X and the current
lead IP address that is currently being tested for identity. lead IP address that is currently being tested for identity.
o When XC becomes invalid on X, the resolution process should be o When XC becomes invalid on X, the resolution process should be
terminated, subject to being redone later. Before redoing the terminated, subject to being redone later. Before redoing the
resolution, XC should be checked on all the lead IP addresses on resolution, XC should be checked on all the lead IP addresses on
skipping to change at page 26, line 17 skipping to change at page 26, line 46
o The phrase "the client ID" is ambiguous, possibly indicating the o The phrase "the client ID" is ambiguous, possibly indicating the
clientid4 and possibly indicating the nfs_client_id4. clientid4 and possibly indicating the nfs_client_id4.
o If the text means to suggest that the same clientid4 must be used, o If the text means to suggest that the same clientid4 must be used,
the logic is not clear since the issue is not the same as for the logic is not clear since the issue is not the same as for
stateids of which there might be many. Adapting to the change of stateids of which there might be many. Adapting to the change of
a single clientid, as might happen as a part of lease migration, a single clientid, as might happen as a part of lease migration,
is relatively easy for the client. is relatively easy for the client.
We have decided to address this issue as follows, with the relevant We have decided that it is best to address this issue as follows,
changes all reflected in Section 5.6. with the relevant changes all reflected in Section 5.6.
o Make it clear that both clientid4 and nfs_client_id4 (including o Make it clear that both clientid4 and nfs_client_id4 (including
both id string and boot verifier) are to be transferred. both id string and boot verifier) are to be transferred.
o Indicate that the initial transfer will result in the same o Indicate that the initial transfer will result in the same
clientid4 after transfer but this is not guaranteed since there clientid4 after transfer but this is not guaranteed since there
may conflict with an existing clientid4 on the destination server may conflict with an existing clientid4 on the destination server
and because lease merger can result in a change of the clientid4. and because lease merger can result in a change of the clientid4.
5.4.2. Proposed changes: Callback re-establishment 5.4.2. Proposed changes: Callback re-establishment
skipping to change at page 28, line 17 skipping to change at page 28, line 51
distinct. For a discussion of how to address the issue in the distinct. For a discussion of how to address the issue in the
face of possible trunking of server IP addresses, see Section 5.2. face of possible trunking of server IP addresses, see Section 5.2.
When a clientid4 is presented to a server and that clientid4 is When a clientid4 is presented to a server and that clientid4 is
not recognized, the server will reject the request with the error not recognized, the server will reject the request with the error
NFS4ERR_STALE_CLIENTID. This can occur for a number of reasons: NFS4ERR_STALE_CLIENTID. This can occur for a number of reasons:
* 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 valid clientid4 * Client error sending an incorrect clientid4 or a valid
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.
skipping to change at page 29, line 15 skipping to change at page 29, line 48
as server reboot which has invalidated the existing clientid4 and as server reboot which has invalidated the existing clientid4 and
associated stateids (see the section entitled "lock-owner" for associated stateids (see the section entitled "lock-owner" for
details). details).
See the detailed descriptions of SETCLIENTID and See the detailed descriptions of SETCLIENTID and
SETCLIENTID_CONFIRM for a complete specification of the SETCLIENTID_CONFIRM for a complete specification of the
operations. operations.
5.5.3. Proposed changes: NFS4ERR_CLID_INUSE 5.5.3. Proposed changes: NFS4ERR_CLID_INUSE
It appears to be the intention that only a single authentication It appears to be the intention that only a single principal be used
flavor be used for client establishment between any client-server for client establishment between any client-server pair. However:
pair. However:
o There is no explicit statement to this effect. o There is no explicit statement to this effect.
o The error that indicates an authentication flavor conflict has a o The error that indicates a principal conflict has a name which
name which does not clarify this issue: NFS4ERR_CLID_INUSE. does not clarify this issue: NFS4ERR_CLID_INUSE.
o The definition of the error is also not very helpful: "The o The definition of the error is also not very helpful: "The
SETCLIENTID operation has found that a client id is already in use SETCLIENTID operation has found that a client id is already in use
by another client". by another client".
As a result, servers exist which reject a SETCLIENTID simply because As a result, servers exist which reject a SETCLIENTID simply because
there already exists a clientid for the same client, established there already exists a clientid for the same client, established
using a different IP address. Although this is generally understood using a different IP address. Although this is generally understood
to be erroneous, such servers still exist and the spec should make to be erroneous, such servers still exist and the spec should make
the correct behavior clear. the correct behavior clear.
Although the error name cannot be changed, the following changes Although the error name cannot be changed, the following changes
should be made to avoid confusion: should be made to avoid confusion:
o The definition of the error should be changed to read, "The o The definition of the error should be changed to read as follows:
SETCLIENTID operation has found that the specified nfs_client_id4
was previously presented with a different authentication flavor The SETCLIENTID operation has found that the specified
and that client instance currently holds an active lease." nfs_client_id4 was previously presented with a different
principal and that client instance currently holds an active
lease. A server MAY return this error if the same principal is
used but a change in authentication flavor gives good reason to
reject the new SETCLIENTID operation as not bona fide.
o In the description of SETCLIENTID, the phrase "then the server o In the description of SETCLIENTID, the phrase "then the server
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."
5.6. Migration, Replication and State (AS PROPOSED) 5.6. Migration, Replication and State (AS PROPOSED)
When responsibility for handling a given filesystem is transferred to When responsibility for handling a given filesystem is transferred to
a new server (migration) or the client chooses to use an alternate a new server (migration) or the client chooses to use an alternate
skipping to change at page 35, line 33 skipping to change at page 36, line 19
previously fetched (on the source server). previously fetched (on the source server).
In the case in which lease merger occurs as part of state transfer, In the case in which lease merger occurs as part of state transfer,
the lease_time attribute of the destination lease remains in effect. the lease_time attribute of the destination lease remains in effect.
The client can simply renew that lease with its existing lease_time The client can simply renew that lease with its existing lease_time
attribute. State in the source lease is renewed at the time of attribute. State in the source lease is renewed at the time of
transfer so that it cannot expire, as long as the destination lease transfer so that it cannot expire, as long as the destination lease
is appropriately renewed. is appropriately renewed.
If state has not been transferred transparently (i.e., the client If state has not been transferred transparently (i.e., the client
need to reclaim or re-obtain its locks), the client should fetch the needs to reclaim or re-obtain its locks), the client should fetch the
value of lease_time on the new (i.e., destination) server, and use it value of lease_time on the new (i.e., destination) server, and use it
for subsequent locking requests. However the server must respect a for subsequent locking requests. However the server must respect a
grace period at least as long as the lease_time on the source server, grace period at least as long as the lease_time on the source server,
in order to ensure that clients have ample time to reclaim their in order to ensure that clients have ample time to reclaim their
locks before potentially conflicting non-reclaimed locks are granted. locks before potentially conflicting non-reclaimed locks are granted.
The means by which the new server obtains the value of lease_time on The means by which the new server obtains the value of lease_time on
the old server is left to the server implementations. It is not the old server is left to the server implementations. It is not
specified by the NFS version 4.0 protocol. specified by the NFS version 4.0 protocol.
6. Results of proposed changes for NFSv4.0 6. Results of proposed changes for NFSv4.0
skipping to change at page 36, line 36 skipping to change at page 37, line 27
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. So far, so good. server XYZ. So far, so good.
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 SETCLIENID with an whether in filesystem F or another. It does a SETCLIENTID with an
nfs_client_id4 with id string value "C" and boot verifier 0x112. nfs_client_id4 with id string value "C" and boot verifier 0x112.
The state associated with lease {0x111, "C", C1} is deleted as The state associated with lease {0x111, "C", C1} is deleted as
part of creating {0x112, "C", C2}. No problem. part of creating {0x112, "C", C2}. No problem.
The correctness signature for this issue is The correctness signature for this issue is
SHOULD-UF-CID SHOULD-UF-CID
so if you have clients and servers that obey the SHOULD clauses, the so if you have clients and servers that obey the SHOULD clauses, the
problem is gone regardless of the choice on the MAY. problem is gone regardless of the choice on the MAY.
skipping to change at page 46, line 32 skipping to change at page 47, line 25
[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", System (NFS) Version 4 Minor Version 1 Protocol",
RFC 5661, January 2010. RFC 5661, January 2010.
12.2. Informative References 12.2. Informative References
[cur-v4.0-bis] [cur-v4.0-bis]
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", 2011, <http://www.ietf.org/id/
draft-ietf-nfsv4-rfc3530bis-18.txt>. draft-ietf-nfsv4-rfc3530bis-19.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. 25 change blocks. 
74 lines changed or deleted 110 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/