draft-ietf-nfsv4-migration-issues-08.txt   draft-ietf-nfsv4-migration-issues-09.txt 
NFSv4 D. Noveck, Ed. NFSv4 D. Noveck, Ed.
Internet-Draft HP Internet-Draft HPE
Intended status: Informational P. Shivam Intended status: Informational P. Shivam
Expires: February 25, 2016 C. Lever Expires: August 22, 2016 C. Lever
B. Baker B. Baker
ORACLE ORACLE
August 24, 2015 February 19, 2016
NFSv4 migration: Implementation experience and spec issues to resolve NFSv4 migration: Implementation experience and spec issues to resolve
draft-ietf-nfsv4-migration-issues-08 draft-ietf-nfsv4-migration-issues-09
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 and explores the options available for
the issues, and explains the choices to be made in updating the curing the issues. It also explains the choices made regarding
NFSv4.0 and NFSv4.1 specifications, to properly address migration. updating the NFSv4.0 specification and those to be made with regard
to the NFSv4.1 specification, in order 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 February 25, 2016. This Internet-Draft will expire on August 22, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 36 skipping to change at page 2, line 37
string values . . . . . . . . . . . . . . . . . . . . . . 11 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 . . . . . . . . . . . . . . 12 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 . . . . . 13 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 . . . 15 5.3. Other proposed changes to migration-state sections . . . 15
5.3.1. Proposed changes: Client ID migration . . . . . . . . 15 5.3.1. Proposed changes: Client ID migration . . . . . . . . 15
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 . . . . . . . . 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. Issues for NFSv4.1 . . . . . . . . . . . . . . . . . . . . . 20
6.1. Results: Failure to free migrated state on client reboot 20 6.1. Addressing state merger in NFSv4.1 . . . . . . . . . . . 20
6.2. Results: Server reboots resulting in confused lease 6.2. Addressing pNFS relationship with migration . . . . . . . 21
situation . . . . . . . . . . . . . . . . . . . . . . . . 21 6.3. Addressing server owner changes in NFSv4.1 . . . . . . . 21
6.3. Results: Client complexity issues . . . . . . . . . . . . 22 7. Security Considerations . . . . . . . . . . . . . . . . . . . 23
6.4. Result summary . . . . . . . . . . . . . . . . . . . . . 23 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
7. Issues for NFSv4.1 . . . . . . . . . . . . . . . . . . . . . 23 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23
7.1. Addressing state merger in NFSv4.1 . . . . . . . . . . . 24 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
7.2. Addressing pNFS relationship with migration . . . . . . . 24 10.1. Normative References . . . . . . . . . . . . . . . . . . 23
7.3. Addressing server owner changes in NFSv4.1 . . . . . . . 25 10.2. Informative References . . . . . . . . . . . . . . . . . 24
8. Security Considerations . . . . . . . . . . . . . . . . . . . 26
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
11.1. Normative References . . . . . . . . . . . . . . . . . . 26
11.2. Informative References . . . . . . . . . . . . . . . . . 27
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 8, line 19 skipping to change at page 8, line 19
strings to clients so that each string designates a single client. strings to clients so that each string designates a single client.
o The relation between strings and clients is a bijection between o The relation between strings and clients is a bijection between
such strings and clients so that each string designates a single such strings and clients so that each string designates a single
client and each client is named by a single string. client and each client is named by a single string.
The first interpretation would make these client-strings like phone The first interpretation would make these client-strings like phone
numbers (a single person can have several) while the second would numbers (a single person can have several) while the second would
make them like social security numbers. make them like social security numbers.
Endless debate about the true meaning of "uniquely defines" in this Debate about the possible meanings of "uniquely defines" in this
context is quite possible but not very helpful. The following points context is quite possible but not very helpful. The following points
should be noted though: should be noted though:
o The second interpretation is more consistent with the way o The second interpretation is more consistent with the way
"uniquely defines" is used elsewhere in the spec. "uniquely defines" is used elsewhere in the spec.
o The spec as now written intends the first interpretation (or is o The spec as now written intends the first interpretation (or is
internally inconsistent). In fact, it recommends, although it internally inconsistent). In fact, it recommends, although non-
doesn't "RECOMMEND" that a single client have at least as many normatively, that a single client have at least as many client-
client-strings as server addresses that it interacts with. It strings as server addresses that it interacts with. It says, in
says, in the third bullet point regarding construction of the the third bullet point regarding construction of the string (which
string (which we shall henceforth refer to as client-string-BP3): we shall henceforth refer to as client-string-BP3):
The string should be different for each server network address The string should be different for each server network address
that the client accesses, rather than common to all server that the client accesses, rather than common to all server
network addresses. network addresses.
o If internode interactions are limited to those between a client o If internode interactions are limited to those between a client
and its servers, there is no occasion for servers to be concerned and its servers, there is no occasion for servers to be concerned
with the question of whether two client-strings designate the same with the question of whether two client-strings designate the same
client, so that there is no occasion for the difference in client, so that there is no occasion for the difference in
interpretation to matter. interpretation to matter.
skipping to change at page 9, line 26 skipping to change at page 9, line 26
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 it is appropriate that the
process of removing the client's previous leased state. server "begin the 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.
skipping to change at page 10, line 43 skipping to change at page 10, line 46
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 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 potential 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 An alternative to having the client infer the existence of trunking
of IP server addresses, is to make this information available to the of IP server addresses, is to make this information available to the
client directly. See Section 4.3 for details. client directly. See Section 4.3 for details.
skipping to change at page 13, line 29 skipping to change at page 13, line 29
o Statements regarding handling of invalid clientid4's need to be o Statements regarding handling of invalid clientid4's need to be
clarified and/or refined in light of the possibilities that arise clarified and/or refined in light of the possibilities that arise
due to lease motion and merger. due to lease motion and merger.
o Confusion and lack of clarity about NFS4ERR_CLID_INUSE. o Confusion and lack of clarity about NFS4ERR_CLID_INUSE.
5. Proposed resolution of NFSv4.0 protocol difficulties 5. Proposed resolution of NFSv4.0 protocol difficulties
This section lists the changes which we believe are necessary to This section lists the changes which we believe are necessary to
resolve the difficulties mentioned above. Such change, along with resolve the difficulties mentioned above. Such changes, along with
other clarifications found to be desirable during drafting and review other clarifications found to be desirable during drafting and review
are contained in [migr-v4.0-update]. are contained in [migr-v4.0-update].
5.1. Proposed changes: nfs_client_id4 client-string 5.1. Proposed changes: nfs_client_id4 client-string
We propose replacing client-string-BP3 with the following text and We propose replacing client-string-BP3 with the following text:
adding the following proposed to provide implementation guidance.
The string MAY be different for each server network address that The string MAY be different for each server network address that
the client accesses, rather than common to all server network the client accesses, rather than common to all server network
addresses. addresses.
In addition, given the importance of the issue of client identity and In addition, given the importance of the issue of client identity and
the fact that both client string-approaches are to be considered the fact that both client string-approaches are to be considered
valid, a greatly expanded treatment of client identity desirable. It valid, a greatly expanded treatment of client identity desirable. It
should have the following major elements. should have the following major elements.
skipping to change at page 15, line 16 skipping to change at page 15, line 16
between a single client and a single server. This requires merger of between a single client and a single server. This requires merger of
leases since there is no real help from synchronizing them at a leases since there is no real help from synchronizing them at a
single instant. single instant.
For the uniform approach, the destination server would simply merge For the uniform approach, the destination server would simply merge
leases as part of state transfer, since two leases with the same leases as part of state transfer, since two leases with the same
nfs_client_id4 values must be for the same client. nfs_client_id4 values must be for the same client.
We have made the following decisions as far as proposed normative We have made the following decisions as far as proposed normative
statements regarding for state merger. They reflect the facts that statements regarding for state merger. They reflect the facts that
we want to support fully migration support in the simplest way we want to allow full migration support in the simplest way possible
possible and that we can't say MUST since we have older clients and and that we can't say MUST since we have older clients and servers to
servers to deal with. deal with.
o Clients SHOULD use the uniform client-string approach in order to o Clients MAY use the uniform client-string approach and are well-
get good migration support. advised to do so if they are concerned about getting good
migration support.
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 servers obey the SHOULD and clients choose to adopt the uniform id
single lease for a given client-server pair will be a transient approach, having more than a single lease for a given client-server
situation, cleaned up as part of adapting to use of migrated state. pair will be a transient 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
skipping to change at page 20, line 10 skipping to change at page 20, line 17
principal and that client instance currently holds an active principal and that client instance currently holds an active
lease. A server MAY return this error if the same principal is lease. A server MAY return this error if the same principal is
used but a change in authentication flavor gives good reason to used but a change in authentication flavor gives good reason to
reject the new SETCLIENTID operation as not bona fide. 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."
6. Results of proposed changes for NFSv4.0 6. Issues for NFSv4.1
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
be handled within the proposal.
Because the choice of uniform vs. non-uniform nfs_client_id4 id
strings is a "SHOULD" in these cases, we will designate clients that
follow this recommendation by SHOULD-UF-CID.
We will also have to take account of any merger-related "SHOULD"
clauses to better understand how they have addressed the issues seen.
We abbreviate as follows:
o SHOULD-SVR-AM refers to the server obeying the SHOULD which
RECOMMENDS that they merge leases with identical nfs_client_id4 id
strings and boot verifiers.
6.1. Results: Failure to free migrated state on client reboot
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
let's look at the situation in which SHOULD-UF-CID holds, whether
SHOULD-SVR-AM is in effect or not.
o A client C establishes a clientid4 C1 with server ABC specifying
an nfs_client_id4 with id string value "C" and boot verifier
0x111.
o The client begins to access files in filesystem F on server ABC,
resulting in generating stateids S1, S2, etc. under the lease for
clientid C1. It may also access files on other filesystems on the
same server.
o The filesystem is migrated from ABC to server XYZ. When
transparent state migration is in effect, stateids S1 and S2 and
lease {0x111, "C", C1} are now available for use by client C at
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
nfs_client_id4 with id string value "C" and boot verifier 0x112.
The state associated with lease {0x111, "C", C1} is deleted as
part of creating {0x112, "C", C2}. No problem.
The correctness signature for this issue is
SHOULD-UF-CID
so if you have clients and servers that obey the SHOULD clauses, the
problem is gone regardless of the choice on the MAY.
6.2. Results: Server reboots resulting in confused lease situation
Now let's consider the scenario given in Section 3.1.2. We 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 and SHOULD-
SVR-AM holds as well.
o Client C talks to server ABC using an nfs_client_id4 id string
such as "C-ABC" and boot verifier v1. As a result a lease with
clientid4 c.i established: {v1, "C-ABC", c.i}.
o Filesystem fs_a1 migrates from server ABC to server XYZ along with
its state. Now server XYZ also has a lease: {v1, "C-ABC", c.i}
o Server ABC reboots.
o Client C talks to server ABC using an nfs_client_id4 id string
such as "C-ABC" and boot verifier v1. As a result a lease with
clientid4 c.j established: {v1, "C-ABC", c.j}.
o fs_a2 migrates from server ABC to server XYZ. As part of
migration the incoming lease is seen to denote same nfs_client_id4
and so is merged with {v1, "C-ABC, c.i}.
o Now server XYZ has only one lease that matches {v1, "C_ABC", *},
so the problem is solved
Now let's consider the same scenario in the situation in which
SHOULD-UF-CID holds and SHOULD-SVR-AM holds as well.
o Client C talks to server ABC using an nfs_client_id4 id string "C"
and boot verifier v1. As a result a lease with clientid4 c.i is
established: {v1, "C", c.i}.
o fs_a1 migrates from server ABC to server XYZ along with its state.
Now XYZ also has a lease: {v1, "C", c.i}
o Server ABC reboots.
o Client C talks to server ABC using an nfs_client_id4 id string "C"
and boot verifier v1. As a result a lease with clientid4 c.j is
established: {v1, "C", c.j}.
o fs_a2 migrates from server ABC to server XYZ. As part of
migration the incoming lease is seen to denote the same
nfs_client_id4 and so is merged with {v1, "C", c.i}.
o Now server XYZ has only one lease that matches {v1, "C", *}, so
the problem is solved
The correctness signature for this issue is
SHOULD-SVR-AM
so if you have clients and servers that obey the SHOULD clauses, the
problem is gone regardless of the choice on the MAY.
6.3. Results: Client complexity issues
Consider the following situation:
o There are a set of clients C1 through Cn accessing servers S1
through Sm. Each server manages some significant number of
filesystems with the filesystem count L being significantly
greater than m.
o Each client Cx will access a subset of the servers and so will
have up to m clientids, which we will call Cxy for server Sy.
o Now assume that for load-balancing or other operational reasons,
numbers of filesystems are migrated among the servers. As a
result, depending on how this handled, the number of clientids may
explode. See below.
Now look what will happen under various scenarios:
o We have previously (in Section 3.1.3) looked at this in case of
client following the non-uniform client-string approach. In that
case, each client-server pair could have up to m clientids and
each client will have up to m**2 clientids. If we add the
possibility of server reboot, the only bound on a client's
clientid count is L.
o If we look at this in the SHOULD-UF-CID case in which the SHOULD-
SVR_AM condition holds, the situation is no different. Although
the server has the client identity information that could enable
same-client-same-server leases to be combined, it does not do so.
We still have up to L clientids per client.
o On the other hand, if we look at the SHOULD-UF-CID case in which
SHOULD-SVR-AM holds, the problem is gone. There can be no more
than m clientids per client, and n clientids per server.
The correctness signature for this issue is
(SHOULD-UF-CID & SHOULD-SVR-AM)
so if you have clients and servers that obey the SHOULD clauses, the
problem is gone regardless of the choice on the MAY.
6.4. Result summary
We have seen that (SHOULD-SVR-AM & SHOULD-UF-CID) are sufficient to
solve the problems people have experienced.
7. Issues for NFSv4.1
Because NFSv4.1 embraces the uniform client-string approach, Because NFSv4.1 embraces the uniform client-string approach, as
addressing migration issues is simpler. In the terms of Section 6, advised by section 2.4 of [RFC5661], addressing migration issues is
we already have SHOULD-UF-CID, for NFSv4.1, as advised by section 2.4 simpler.
of [RFC5661], simplifying the work to be done.
Nevertheless, there are some issues that will have to be addressed. Nevertheless, there are some issues that will have to be addressed.
Some examples: Some examples:
o The other necessary part of addressing migration issues, which we o The other necessary part of addressing migration issues, providing
call above SHOULD-SVR-AM, is not currently addressed by NFSv4.1 for the server's merger of leases that relate to the same client,
and changes need to be made to make it clear that state needs to is not currently addressed by NFSv4.1 and changes need to be made
be appropriately merged as part of migration, to avoid multiple to make it clear that state needs to be appropriately merged as
clientids between a client-server pair. part of migration, to avoid multiple clientids between a client-
server pair.
o There needs to be some clarification of how migration, and o There needs to be some clarification of how migration, and
particularly transparent state migration, should interact with particularly transparent state migration, should interact with
pNFS layouts. pNFS layouts.
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 6.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 [RFC7530] in that it assumes that the state for problems to that in [RFC7530] in that it assumes that the state for
multiple filesystems on different servers will not be merged to so multiple filesystems on different servers will not be merged to so
that it appears under a single common clientid. We've already seen that it appears under a single common clientid. We've already seen
the reasons that this is a problem, with regard to NFSv4.0. the reasons that this is a problem, with regard to 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
skipping to change at page 24, line 33 skipping to change at page 21, line 22
o There is separate handling and discussion of the cases of matching o There is separate handling and discussion of the cases of matching
and non-matching server scopes. and non-matching server scopes.
o In the case of matching server scopes, the text calls for an o In the case of matching server scopes, the text calls for an
impossible degree of transparency. impossible degree of transparency.
o In the case of non-matching server scopes, the text does not o In the case of non-matching server scopes, the text does not
mention transparent state migration at all, resulting in a mention transparent state migration at all, resulting in a
functional regression from NFSV4.0 functional regression from NFSV4.0
7.2. Addressing pNFS relationship with migration 6.2. Addressing pNFS relationship with migration
This is made difficult because, within the PNFS framework, migration This is made difficult because, within the PNFS framework, migration
might mean any of several things: might mean any of several things:
o Transfer of the MDS, leaving DS's alone. o Transfer of the MDS, leaving DS's alone.
This would be minimally disruptive to those using layouts but This would be minimally disruptive to those using layouts but
would require the pNFS control protocol to support the DS being would require the pNFS control protocol to support the DS being
directed to a new MDS. directed to a new MDS.
skipping to change at page 25, line 11 skipping to change at page 21, line 47
o Transfer of the filesystem to a new filesystem with both MDS and o Transfer of the filesystem to a new filesystem with both MDS and
DS's moving. DS's moving.
In such a transfer, an entirely different set of DS's will be at In such a transfer, an entirely different set of DS's will be at
the target location. There may even be no pNFS support on the the target location. There may even be no pNFS support on the
destination filesystem at all. destination filesystem at all.
Migration needs to support both the first and last of these models. Migration needs to support both the first and last of these models.
7.3. Addressing server owner changes in NFSv4.1 6.3. Addressing server owner changes in NFSv4.1
Section 2.10.5 of [RFC5661] states the following. Section 2.10.5 of [RFC5661] states the following.
The client should be prepared for the possibility that The client should be prepared for the possibility that
eir_server_owner values may be different on subsequent EXCHANGE_ID eir_server_owner values may be different on subsequent EXCHANGE_ID
requests made to the same network address, as a result of various requests made to the same network address, as a result of various
sorts of reconfiguration events. When this happens and the sorts of reconfiguration events. When this happens and the
changes result in the invalidation of previously valid forms of changes result in the invalidation of previously valid forms of
trunking, the client should cease to use those forms, either by trunking, the client should cease to use those forms, either by
dropping connections or by adding sessions. For a discussion of dropping connections or by adding sessions. For a discussion of
skipping to change at page 26, line 16 skipping to change at page 23, line 5
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
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 7. Security Considerations
With regard to NFSv4.0, the Security Considerations section of With regard to NFSv4.0, the Security Considerations section of
[RFC7530] encourages clients to protect the integrity of the SECINFO [RFC7530] encourages clients to protect the integrity of the SECINFO
operation, any GETATTR operation for the fs_locations attribute, and operation, any GETATTR operation for the fs_locations attribute. A
the operations SETCLIENTID/SETCLIENTID_CONFIRM. A migration recovery needed change is to include the operations SETCLIENTID/
event can use any or all of these operations. We do not recommend SETCLIENTID_CONFIRM as among those for which integrity protection is
any change here. recommended. A migration recovery event can use any or all of these
operations.
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 8. IANA Considerations
This document does not require actions by IANA. This document does not require actions by IANA.
10. Acknowledgements 9. Acknowledgements
The editor and authors of this document gratefully acknowledge the The editor and authors of this document gratefully acknowledge the
contributions of Trond Myklebust of NetApp and Robert Thurlow of contributions of Trond Myklebust of NetApp and Robert Thurlow of
Oracle. We also thank Tom Haynes of NetApp and Spencer Shepler of Oracle. We also thank Tom Haynes of NetApp and Spencer Shepler of
Microsoft for their guidance and suggestions. Microsoft for their guidance and suggestions.
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 10. References
11.1. Normative References 10.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, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC5661] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed., [RFC5661] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed.,
"Network File System (NFS) Version 4 Minor Version 1 "Network File System (NFS) Version 4 Minor Version 1
Protocol", RFC 5661, DOI 10.17487/RFC5661, January 2010, Protocol", RFC 5661, DOI 10.17487/RFC5661, January 2010,
<http://www.rfc-editor.org/info/rfc5661>. <http://www.rfc-editor.org/info/rfc5661>.
[RFC7530] Haynes, T., Ed. and D. Noveck, Ed., "Network File System [RFC7530] Haynes, T., Ed. and D. Noveck, Ed., "Network File System
(NFS) Version 4 Protocol", RFC 7530, DOI 10.17487/RFC7530, (NFS) Version 4 Protocol", RFC 7530, DOI 10.17487/RFC7530,
March 2015, <http://www.rfc-editor.org/info/rfc7530>. March 2015, <http://www.rfc-editor.org/info/rfc7530>.
11.2. Informative References 10.2. Informative References
[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", 2016,
<http://www.ietf.org/id/ <http://www.ietf.org/id/
draft-ietf-nfsv4-rfc3530-migration-update-06.txt>. draft-ietf-nfsv4-rfc3530-migration-update-08.txt>.
Work in progress. Work in progress.
[NFSv4-vers] [NFSv4-vers]
Noveck, D., "NFSv4 Version Management", 2015, Noveck, D., "NFSv4 Version Management", 2016,
<http://www.ietf.org/id/ <http://www.ietf.org/id/
draft-ietf-nfsv4-versioning-01.txt>. draft-ietf-nfsv4-versioning-03.txt>.
Work in progress. Work in progress.
Authors' Addresses Authors' Addresses
David Noveck (editor) David Noveck (editor)
Hewlett-Packard Hewlett Packard Enterprise
165 Dascomb Road 165 Dascomb Road
Andover, MA 01810 Andover, MA 01810
US US
Phone: +1 978 474 2011 Phone: +1 978 474 2011
Email: davenoveck@gmail.com Email: davenoveck@gmail.com
Piyush Shivam Piyush Shivam
Oracle Corporation Oracle Corporation
5300 Riata Park Ct. 5300 Riata Park Ct.
 End of changes. 36 change blocks. 
233 lines changed or deleted 74 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/