draft-ietf-nfsv4-migration-issues-07.txt   draft-ietf-nfsv4-migration-issues-08.txt 
NFSv4 D. Noveck, Ed. NFSv4 D. Noveck, Ed.
Internet-Draft Dell Internet-Draft HP
Intended status: Informational P. Shivam Intended status: Informational P. Shivam
Expires: September 3, 2015 C. Lever Expires: February 25, 2016 C. Lever
B. Baker B. Baker
ORACLE ORACLE
March 2, 2015 August 24, 2015
NFSv4 migration: Implementation experience and spec issues to resolve NFSv4 migration: Implementation experience and spec issues to resolve
draft-ietf-nfsv4-migration-issues-07 draft-ietf-nfsv4-migration-issues-08
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 to be made in updating the
NFSv4.1 specifications, to address migration. NFSv4.0 and NFSv4.1 specifications, to properly address migration.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 3, 2015. This Internet-Draft will expire on February 25, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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 20 skipping to change at page 2, line 20
Table of Contents Table of Contents
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 . . . . . . . . . . . . 7
3.2.1. Issues with nfs_client_id4 generation and use . . . . 8 3.2.1. Issues with nfs_client_id4 generation and use . . . . 7
3.2.2. Issues with lease proliferation . . . . . . . . . . . 10 3.2.2. Issues with lease proliferation . . . . . . . . . . . 9
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 . . . . . . . . . . . . . . . . . . . . . . 12 string values . . . . . . . . . . . . . . . . . . . . . . 11
4.3. Possible changes to add a new operation . . . . . . . . . 12 4.3. Possible changes to add a new operation . . . . . . . . . 12
4.4. Other issues within migration-state sections . . . . . . 12 4.4. Other issues within migration-state sections . . . . . . 12
4.5. Issues within other sections . . . . . . . . . . . . . . 13 4.5. Issues within other sections . . . . . . . . . . . . . . 12
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 . . . . . 14 5.1. Proposed changes: nfs_client_id4 client-string . . . . . 13
5.2. Proposed changes: merged (vs. synchronized) leases . . . 14 5.2. Proposed changes: merged (vs. synchronized) leases . . . 14
5.3. Other proposed changes to migration-state sections . . . 16 5.3. Other proposed changes to migration-state sections . . . 15
5.3.1. Proposed changes: Client ID migration . . . . . . . . 16 5.3.1. Proposed changes: Client ID migration . . . . . . . . 15
5.3.2. Proposed changes: Callback re-establishment . . . . . 17 5.3.2. Proposed changes: Callback re-establishment . . . . . 16
5.3.3. Proposed changes: NFS4ERR_LEASE_MOVED rework . . . . 17 5.3.3. Proposed changes: NFS4ERR_LEASE_MOVED rework . . . . 16
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 . . . . . . . . 18 5.4.2. Proposed changes: clientid4 handling . . . . . . . . 17
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 . . . . . . . . . . . 20 6. Results of proposed changes for NFSv4.0 . . . . . . . . . . . 20
6.1. Results: Failure to free migrated state on client reboot 21 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 . . . . . . . . . . . . . . . . . . . . . . . . 21 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 . . . . . . . . . . . . . . . . . . . . . 24 7. Issues for NFSv4.1 . . . . . . . . . . . . . . . . . . . . . 23
7.1. Addressing state merger in NFSv4.1 . . . . . . . . . . . 24 7.1. Addressing state merger in NFSv4.1 . . . . . . . . . . . 24
7.2. Addressing pNFS relationship with migration . . . . . . . 25 7.2. Addressing pNFS relationship with migration . . . . . . . 24
7.3. Addressing server owner changes in NFSv4.1 . . . . . . . 25 7.3. Addressing server owner changes in NFSv4.1 . . . . . . . 25
8. Security Considerations . . . . . . . . . . . . . . . . . . . 26 8. Security Considerations . . . . . . . . . . . . . . . . . . . 26
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
11.1. Normative References . . . . . . . . . . . . . . . . . . 27 11.1. Normative References . . . . . . . . . . . . . . . . . . 26
11.2. Informative References . . . . . . . . . . . . . . . . . 27 11.2. Informative References . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
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 3, line 47 skipping to change at page 3, line 47
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
In the context of this informational document, these normative In the context of this informational document, these normative
keywords will always occur in the context of a quotation, most often keywords will always occur in the context of a quotation, most often
direct but sometimes indirect. The context will make it clear direct but sometimes indirect. The context will make it clear
whether the quotation is from: whether the quotation is from:
o The current definitive definition of the NFSv4.0 protocol, whether o The current definitive definition of the NFSv4.0 protocol
that is the original NFSv4.0 specification [RFC3530], or its [RFC7530].
expected successor [RFC3530bis].
As the identity of that document may change during the lifetime of
this document, we will often refer to the current or pending
definition of NFSv4.0 and quote from portions of the documents
that are identical among all existing drafts. Given that RFC3530
and all RFC3530bis drafts agree as to the issues under discussion,
this should not cause undue difficulty. Note that to simplify
document maintenance, section names rather than section numbers
are used when referring to sections in existing documents so that
only minimal changes will be necessary as the identity of the
document defining NFSv4.0 changes.
o The current definitive definition of the NFSv4.1 protocol o The current definitive definition of the NFSv4.1 protocol
[RFC5661]. [RFC5661].
o A proposed or possible text to serve as a replacement for the o A proposed or possible text to serve as a replacement for the
current definitive document text. Sometimes, a number of possible current definitive document text. Sometimes, a number of possible
alternative texts may be listed and benefits and detriments of alternative texts may be listed and benefits and detriments of
each examined in turn. each examined in turn.
3. NFSv4.0 Implementation Experience 3. NFSv4.0 Implementation Experience
skipping to change at page 6, line 10 skipping to change at page 5, line 42
One of the first cases in which this sort of situation has resulted One of the first cases in which this sort of situation has resulted
in difficulties is in connection with doing a SETCLIENTID for in difficulties is in connection with doing a SETCLIENTID for
callback update. callback update.
The SETCLIENTID for callback update only includes the nfs_client_id4, The SETCLIENTID for callback update only includes the nfs_client_id4,
assuming there can only be one such with a given nfs_client_id4 assuming there can only be one such with a given nfs_client_id4
value. If there were multiple, confirmed client records with value. If there were multiple, confirmed client records with
identical nfs_client_id4 id string values, there would be no way to identical nfs_client_id4 id string values, there would be no way to
map the callback update request to the correct client record. Apart map the callback update request to the correct client record. Apart
from the migration handling specified in [RFC3530] and [RFC3530bis], from the migration handling specified in [RFC7530], such a situation
such a situation cannot arise. cannot arise.
One possible accommodation for this particular issue that has been One possible accommodation for this particular issue that has been
used is to add a RENEW operation along with SETCLIENTID (on a used is to add a RENEW operation along with SETCLIENTID (on a
callback update) to disambiguate the client. callback update) to disambiguate the client.
When the client updates the callback info to the destination, the When the client updates the callback info to the destination, the
client would, by convention, send a compound like this: client would, by convention, send a compound like this:
{ RENEW clientid4, SETCLIENTID nfs_client_id4,verf,cb } { RENEW clientid4, SETCLIENTID nfs_client_id4,verf,cb }
skipping to change at page 8, line 12 skipping to change at page 7, line 46
o There may be multiple clientid4's all connected to the same server o There may be multiple clientid4's all connected to the same server
and using the same nfs_clientid4. and using the same nfs_clientid4.
This sort of additional client complexity is troublesome and needs to This sort of additional client complexity is troublesome and needs to
be eliminated. be eliminated.
3.2. Sources of Protocol difficulties 3.2. Sources of Protocol difficulties
3.2.1. Issues with nfs_client_id4 generation and use 3.2.1. Issues with nfs_client_id4 generation and use
The current definitive definitions of the NFSv4.0 protocol, [RFC3530] In the current definitive definition of the NFSv4.0 protocol,
and [RFC3530bis] both agree. The section entitled "Client ID" says: [RFC7530], the section entitled "Client ID" says:
The second field, id is a variable length string that uniquely The second field, id is a variable length string that uniquely
defines the client. defines the client.
There are two possible interpretations of the phrase "uniquely There are two possible interpretations of the phrase "uniquely
defines" in the above: defines" in the above:
o The relation between strings and clients is a function from such o The relation between strings and clients is a function from such
strings to clients so that each string designates a single client. strings to clients so that each string designates a single client.
skipping to change at page 9, line 20 skipping to change at page 9, line 7
distinction becomes very important. distinction becomes very important.
Given the need for the server to be aware of client identity with Given the need for the server to be aware of client identity with
regard to migrated state, either client-string construction rules regard to migrated state, either client-string construction rules
will have to change or there will be a need to get around current will have to change or there will be a need to get around current
issues, or perhaps a combination of these two will be required. issues, or perhaps a combination of these two will be required.
Later sections will examine the options and propose a solution. Later sections will examine the options and propose a solution.
One consideration that may indicate that this cannot remain exactly One consideration that may indicate that this cannot remain exactly
as it is today has to do with the fact that the current explanation as it is today has to do with the fact that the current explanation
for this behavior is not correct. The current definitive definitions for this behavior is not correct. In the current definitive
of the NFSv4.0 protocol, [RFC3530] and [RFC3530bis] both agree. The definition of the NFSv4.0 protocol [RFC7530], the section entitled
section entitled "Client ID" says: "Client ID" says:
The reason is that it may not be possible for the client to tell The reason is that it may not be possible for the client to tell
if the same server is listening on multiple network addresses. If if the same server is listening on multiple network addresses. If
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
skipping to change at page 10, line 31 skipping to change at page 10, line 15
patterns make this an unpalatable choice for use as a general patterns make this an unpalatable choice for use as a general
solution, but it is reasonable to "RECOMMEND" this choice for a well- solution, but it is reasonable to "RECOMMEND" this choice for a well-
defined subset of clients. One alternative would be to create a way defined subset of clients. One alternative would be to create a way
for the server to infer from client behavior which leases are held by for the server to infer from client behavior which leases are held by
the same client and use this information to do appropriate lease the same client and use this information to do appropriate lease
mergers. Prototyping and detailed specification work has shown that mergers. Prototyping and detailed specification work has shown that
this could be done but the resulting complexity is such that a better this could be done but the resulting complexity is such that a better
choice is to "RECOMMEND" use of the uniform client-string approach choice is to "RECOMMEND" use of the uniform client-string approach
for clients supporting the migration feature. for clients supporting the migration feature.
Because of the discussion of client-string construction in [RFC3530] Because of the discussion of client-string construction in [RFC7530],
and [RFC3530bis], most existing clients implement the non-uniform most existing clients implement the non-uniform client-string
client-string approach. As a result, existing servers may not have approach. As a result, existing servers may not have been tested
been tested with clients implementing uniform client-strings. As a with clients implementing uniform client-strings. As a consequence,
consequence, care must be taken to preserve interoperability between care must be taken to preserve interoperability between UCS-capable
UCS-capable clients and servers that don't tolerate uniform client clients and servers that don't tolerate uniform client strings for
strings for one reason or another. one reason or another.
4. Issues to be resolved in NFSv4.0 4. Issues to be resolved in NFSv4.0
4.1. Possible changes to nfs_client_id4 client-string 4.1. Possible changes to nfs_client_id4 client-string
The fact that the reason given in client-string-BP3 is not valid The fact that the reason given in client-string-BP3 is not valid
makes the existing "should" insupportable. We can't either makes the existing "should" insupportable. We can't either
o Keep a reason we know is invalid. o Keep a reason we know is invalid.
skipping to change at page 12, line 29 skipping to change at page 12, line 17
It might be possible to return server-identity information to the 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 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. This could be done by a SETCLIENTID_PLUS optional
operation, which acts like SETCLIENTID, except that it returns server operation, which acts like SETCLIENTID, except that it returns server
identity information. Such information could be used by clients, identity information. Such information could be used by clients,
making it possible to for them to be aware of server trunking making it possible to for them to be aware of server trunking
relationships, rather than having to infer them from server behavior. relationships, rather than having to infer them from server behavior.
It has been generally thought that protocol extensions such as this It has been generally thought that protocol extensions such as this
are not appropriate in bis documents and other documents updating are not appropriate in bis documents and other documents updating
NFSv4 protocol definition RFC's. However, it is argued in [NFS-ext] NFSv4 protocol definition RFC's. However, [NFSv4-vers] discusses
that protocol extensions, similar to those allowed between minor means by which protocol extensions, similar to those allowed between
versions, should be acceptable to correct mistakes within a minor minor versions, can be used to correct protocol mistakes.
version.
A decision to adopt this approach will require considerable 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 applying to all minor versions, as has been
proposed.
In view of the time to effect such changes, this approach is not A decision to adopt this approach would require waiting for
likely to be adopted in an RFC updating [RFC3530] or [RFC3530bis], [NFSv4-vers] to become a Proposed Standard. In view of the time
such as [migr-v4.0-update]. Still, it is worth keeping in mind, if necessary for that to happen, this approach is not expected to be
implementers have difficulties inferring trunking relationships using adopted in an RFC updating [RFC7530], such as [migr-v4.0-update].
the techniques discussed there. 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 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
skipping to change at page 14, line 39 skipping to change at page 14, line 20
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] In the current definitive definition of the NFSv4.0 protocol,
and [RFC3530bis] both agree. The section entitled "Migration and [RFC7530], 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
given client expire at the same time, the server should advance given client expire at the same time, the server should advance
the expiration time to the later of the leases being transferred the expiration time to the later of the leases being transferred
or the leases already present. This allows the client to maintain or the leases already present. This allows the client to maintain
lease renewal of both classes without special effort: lease renewal of both classes without special effort:
skipping to change at page 16, line 11 skipping to change at page 15, line 40
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] In the current definitive definition of the NFSv4.0 protocol
and [RFC3530bis] both agree. The section entitled "Migration and [RFC7530], the section entitled "Migration and State" says:
State" says:
In the case of migration, the servers involved in the migration of In the case of migration, the servers involved in the migration of
a filesystem SHOULD transfer all server state from the original to a filesystem SHOULD transfer all server state from the original to
the new server. This must be done in a way that is transparent to the new server. This must be done in a way that is transparent to
the client. This state transfer will ease the client's transition the client. This state transfer will ease the client's transition
when a filesystem migration occurs. If the servers are successful when a filesystem migration occurs. If the servers are successful
in transferring all state, the client will continue to use in transferring all state, the client will continue to use
stateids assigned by the original server. Therefore the new stateids assigned by the original server. Therefore the new
server must recognize these stateids as valid. This holds true server must recognize these stateids as valid. This holds true
for the client ID as well. Since responsibility for an entire for the client ID as well. Since responsibility for an entire
skipping to change at page 17, line 7 skipping to change at page 16, line 34
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.3.2. Proposed changes: Callback re-establishment 5.3.2. Proposed changes: Callback re-establishment
The current definitive definitions of the NFSv4.0 protocol, [RFC3530] In the current definitive definition of the NFSv4.0 protocol
and [RFC3530bis] both agree. The section entitled "Migration and [RFC7530], the section entitled "Migration and State" says:
State" says:
A client SHOULD re-establish new callback information with the new A client SHOULD re-establish new callback information with the new
server as soon as possible, according to sequences described in server as soon as possible, according to sequences described in
sections "Operation 35: SETCLIENTID - Negotiate Client ID" and sections "Operation 35: SETCLIENTID - Negotiate Client ID" and
"Operation 36: SETCLIENTID_CONFIRM - Confirm Client ID". This "Operation 36: SETCLIENTID_CONFIRM - Confirm Client ID". This
ensures that server operations are not blocked by the inability to ensures that server operations are not blocked by the inability to
recall delegations. recall delegations.
The above will need to be fixed to reflect the possibility of merging The above will need to be fixed to reflect the possibility of merging
of leases, of leases,
5.3.3. Proposed changes: NFS4ERR_LEASE_MOVED rework 5.3.3. Proposed changes: NFS4ERR_LEASE_MOVED rework
The current definitive definitions of the NFSv4.0 protocol, [RFC3530] In the current definitive definition of the NFSv4.0 protocol
and [RFC3530bis] both agree. The section entitled "Notification of [RFC7530], the section entitled "Notification of Migrated Lease"
Migrated Lease" says: says:
Upon receiving the NFS4ERR_LEASE_MOVED error, a client that Upon receiving the NFS4ERR_LEASE_MOVED error, a client that
supports filesystem migration MUST probe all filesystems from that supports filesystem migration MUST probe all filesystems from that
server on which it holds open state. Once the client has server on which it holds open state. Once the client has
successfully probed all those filesystems which are migrated, the successfully probed all those filesystems which are migrated, the
server MUST resume normal handling of stateful requests from that server MUST resume normal handling of stateful requests from that
client. client.
There is a lack of clarity that is prompted by ambiguity about what There is a lack of clarity that is prompted by ambiguity about what
exactly probing is and what the interlock between client and server exactly probing is and what the interlock between client and server
skipping to change at page 24, line 34 skipping to change at page 24, line 8
o The current discussion (in [RFC5661]), of the possibility of o The current discussion (in [RFC5661]), of the possibility of
server_owner changes is incomplete and confusing. server_owner changes is incomplete and confusing.
Discussion of how to resolve these issues will appear in the sections Discussion of how to resolve these issues will appear in the sections
below. below.
7.1. Addressing state merger in NFSv4.1 7.1. Addressing state merger in NFSv4.1
The existing treatment of state transfer in [RFC5661], has similar The existing treatment of state transfer in [RFC5661], has similar
problems to that in [RFC3530] and [RFC3530bis] in that it assumes problems to that in [RFC7530] in that it assumes that the state for
that the state for multiple filesystems on different servers will not multiple filesystems on different servers will not be merged to so
be merged to so that it appears under a single common clientid. that it appears under a single common clientid. We've already seen
We've already seen the reasons that this is a problem, with regard to the reasons that this is a problem, with regard to NFSv4.0.
NFSv4.0.
Although we don't have the problems stemming from the non-uniform Although we don't have the problems stemming from the non-uniform
client-string approach, there are a number of complexities in the client-string approach, there are a number of complexities in the
existing treatment of state management in the section entitled "Lock existing treatment of state management in the section entitled "Lock
State and File System Transitions" in [RFC5661] that make this non- State and File System Transitions" in [RFC5661] that make this non-
trivial to address: trivial to address:
o Migration is currently treated together with other sorts of o Migration is currently treated together with other sorts of
filesystem transitions including transitioning between replicas filesystem transitions including transitioning between replicas
without any NFS4ERR_MOVED errors. without any NFS4ERR_MOVED errors.
skipping to change at page 26, line 42 skipping to change at page 26, line 18
these are now stale but if NFS4ERR_STALE is not received, he these are now stale but if NFS4ERR_STALE is not received, he
can proceed to reclaim his opens. can proceed to reclaim his opens.
* When eir_server_scope and eir_server_owner.so_major_id remain * When eir_server_scope and eir_server_owner.so_major_id remain
the same, the client has to use the now-current values of the same, the client has to use the now-current values of
eir_server-owner.so_minor_id in deciding on appropriate forms eir_server-owner.so_minor_id in deciding on appropriate forms
of trunking. of trunking.
8. Security Considerations 8. Security Considerations
With regard to NFSv4.0, the current definitive definitions of the With regard to NFSv4.0, the Security Considerations section of
protocol, [RFC3530] and [RFC3530bis] both agree. The section [RFC7530] encourages clients to protect the integrity of the SECINFO
entitled "Security Considerations" encourages that clients protect operation, any GETATTR operation for the fs_locations attribute, and
the integrity of the SECINFO operation, any GETATTR operation for the the operations SETCLIENTID/SETCLIENTID_CONFIRM. A migration recovery
fs_locations attribute, and the operations SETCLIENTID/ event can use any or all of these operations. We do not recommend
SETCLIENTID_CONFIRM. A migration recovery event can use any or all any change here.
of these operations. We do not recommend any change here.
With regard to NFSv4.1, the Security Considerations section of With regard to NFSv4.1, the Security Considerations section of
[RFC5661] takes proper care of migration-related issues. No change [RFC5661] takes proper care of migration-related issues. No change
is needed. is needed.
9. IANA Considerations 9. IANA Considerations
This document does not require actions by IANA. This document does not require actions by IANA.
10. Acknowledgements 10. Acknowledgements
skipping to change at page 27, line 30 skipping to change at page 26, line 50
Special thanks go to members of the Oracle Solaris NFS team, Special thanks go to members of the Oracle Solaris NFS team,
especially Rick Mesta and James Wahlig, for their work implementing especially Rick Mesta and James Wahlig, for their work implementing
an NFSv4.0 migration prototype and identifying many of the issues an NFSv4.0 migration prototype and identifying many of the issues
documented here. documented here.
11. References 11. References
11.1. Normative References 11.1. Normative References
[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,
DOI 10.17487/RFC2119, March 1997,
[RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., <http://www.rfc-editor.org/info/rfc2119>.
Beame, C., Eisler, M., and D. Noveck, "Network File System
(NFS) version 4 Protocol", RFC 3530, April 2003.
[RFC3530bis]
Haynes, T., Ed. and D. Noveck, Ed., "Network File System
(NFS) Version 4 Protocol", 2014, <http://www.ietf.org/id/
draft-ietf-nfsv4-rfc3530bis-35.txt>.
Work in progress. [RFC5661] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed.,
"Network File System (NFS) Version 4 Minor Version 1
Protocol", RFC 5661, DOI 10.17487/RFC5661, January 2010,
<http://www.rfc-editor.org/info/rfc5661>.
[RFC5661] Shepler, S., Eisler, M., and D. Noveck, "Network File [RFC7530] Haynes, T., Ed. and D. Noveck, Ed., "Network File System
System (NFS) Version 4 Minor Version 1 Protocol", RFC (NFS) Version 4 Protocol", RFC 7530, DOI 10.17487/RFC7530,
5661, January 2010. March 2015, <http://www.rfc-editor.org/info/rfc7530>.
11.2. Informative References 11.2. Informative References
[NFS-ext] Noveck, D., "NFS Protocol Extension: Retrospect and
Prospect", 2014, <http://www.ietf.org/id/
draft-dnoveck-nfs-extension-01.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", 2015, "NFSv4.0 migration: Specification Update", 2015,
<http://www.ietf.org/id/ <http://www.ietf.org/id/
draft-ietf-nfsv4-rfc3530-migration-update-06.txt>. draft-ietf-nfsv4-rfc3530-migration-update-06.txt>.
Work in progress. Work in progress.
[NFSv4-vers]
Noveck, D., "NFSv4 Version Management", 2015,
<http://www.ietf.org/id/
draft-ietf-nfsv4-versioning-01.txt>.
Work in progress.
Authors' Addresses Authors' Addresses
David Noveck (editor) David Noveck (editor)
Dell Hewlett-Packard
300 Innovative Way 165 Dascomb Road
Nashua, NH 03062 Andover, MA 01810
US US
Phone: +1 781 572 8038 Phone: +1 978 474 2011
Email: dave_noveck@dell.com Email: davenoveck@gmail.com
Piyush Shivam Piyush Shivam
Oracle Corporation Oracle Corporation
5300 Riata Park Ct. 5300 Riata Park Ct.
Austin, TX 78727 Austin, TX 78727
US US
Phone: +1 512 401 1019 Phone: +1 512 401 1019
Email: piyush.shivam@oracle.com Email: piyush.shivam@oracle.com
Charles Lever Charles Lever
Oracle Corporation Oracle Corporation
1015 Granger Avenue 1015 Granger Avenue
Ann Arbor, MI 48104 Ann Arbor, MI 48104
US US
Phone: +1 248 614 5091 Phone: +1 248 614 5091
Email: chuck.lever@oracle.com Email: chuck.lever@oracle.com
Bill Baker Bill Baker
Oracle Corporation Oracle Corporation
5300 Riata Park Ct. 5300 Riata Park Ct.
Austin, TX 78727 Austin, TX 78727
US US
Phone: +1 512 401 1081 Phone: +1 512 401 1081
Email: bill.baker@oracle.com Email: bill.baker@oracle.com
 End of changes. 39 change blocks. 
119 lines changed or deleted 94 lines changed or added

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