draft-ietf-nfsv4-mv0-trunking-update-03.txt   draft-ietf-nfsv4-mv0-trunking-update-04.txt 
Network File System Version 4 C. Lever, Ed. Network File System Version 4 C. Lever, Ed.
Internet-Draft Oracle Internet-Draft Oracle
Updates: 7530 (if approved) D. Noveck Updates: 7530 (if approved) D. Noveck
Intended status: Standards Track NetApp Intended status: Standards Track NetApp
Expires: June 30, 2019 December 27, 2018 Expires: August 5, 2019 February 1, 2019
NFS version 4.0 Trunking Update NFS version 4.0 Trunking Update
draft-ietf-nfsv4-mv0-trunking-update-03 draft-ietf-nfsv4-mv0-trunking-update-04
Abstract Abstract
The file system location-related attribute in NFS version 4.0, The file system location-related attribute in NFS version 4.0,
fs_locations, informs clients about alternate locations of file fs_locations, informs clients about alternate locations of file
systems. An NFS version 4.0 client can use this information to systems. An NFS version 4.0 client can use this information to
handle migration and replication of server filesystems. This handle migration and replication of server filesystems. This
document describes how an NFS version 4.0 client can additionally use document describes how an NFS version 4.0 client can additionally use
this information to discover an NFS version 4.0 server's trunking this information to discover an NFS version 4.0 server's trunking
capabilities. This document updates RFC 7530. capabilities. This document updates RFC 7530.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 June 30, 2019. This Internet-Draft will expire on August 5, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Document Organization . . . . . . . . . . . . . . . . . . . . 5 4. Document Organization . . . . . . . . . . . . . . . . . . . . 6
5. Changes Within Section 8 of [RFC7530] . . . . . . . . . . . . 6 5. Changes Within Section 8 of [RFC7530] . . . . . . . . . . . . 7
5.1. Updated Section 8.1 of [RFC7530], entitled 5.1. Updated Section 8.1 of [RFC7530], entitled
"Location Attributes" . . . . . . . . . . . . . . . . . . 7 "Location Attributes" . . . . . . . . . . . . . . . . . . 8
5.2. Updates to Section 8.4 of [RFC7530], entitled 5.2. Updates to Section 8.4 of [RFC7530], entitled
"Uses of Location Information" . . . . . . . . . . . . . 9 "Uses of Location Information" . . . . . . . . . . . . . 9
5.2.1. Updated Introduction to Section 8.4 of [RFC7530], 5.2.1. Updated Introduction to Section 8.4 of [RFC7530],
entitled "Uses of Location Information" . . . . . . . 9 entitled "Uses of Location Information" . . . . . . . 9
5.2.2. New Sub-section of Section 8.4 of [RFC7530], 5.2.2. New Sub-section of Section 8.4 of [RFC7530],
to be entitled "Trunking Discovery and Detection" . . 10 to be entitled "Trunking Discovery and Detection" . . 10
5.2.3. New Sub-section of Section 8.4 of [RFC7530], 5.2.3. New Sub-section of Section 8.4 of [RFC7530],
to be entitled "Location Attributes and Connection to be entitled "Location Attributes and Connection
Type Selection" . . . . . . . . . . . . . . . . . . . 11 Type Selection" . . . . . . . . . . . . . . . . . . . 11
5.2.4. Updated Section 8.4.1 of [RFC7530], entitled 5.2.4. Updated Section 8.4.1 of [RFC7530], entitled
"File System Replication and Trunking" . . . . . . . 11 "File System Replication and Trunking" . . . . . . . 12
5.2.5. Updated Section 8.4.2 of [RFC7530], entitled 5.2.5. Updated Section 8.4.2 of [RFC7530], entitled
"File System Migration" . . . . . . . . . . . . . . . 12 "File System Migration" . . . . . . . . . . . . . . . 12
5.2.6. New Sub-section of Section 8.4 of [RFC7530], 5.2.6. New Sub-section of Section 8.4 of [RFC7530],
to be entitled "Interaction of Trunking, Migration, to be entitled "Interaction of Trunking, Migration,
and Replication" . . . . . . . . . . . . . . . . . . 12 and Replication" . . . . . . . . . . . . . . . . . . 13
5.3. Updated Section 8.5 of [RFC7530], entitled 5.3. Updated Section 8.5 of [RFC7530], entitled
"Location Entries and Server Identity Update" . . . . . . 14 "Location Entries and Server Identity Update" . . . . . . 15
6. Updates to [RFC7530] Outside Section Eight . . . . . . . . . 14 6. Updates to [RFC7530] Outside Section Eight . . . . . . . . . 15
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
9.1. Normative References . . . . . . . . . . . . . . . . . . 17 9.1. Normative References . . . . . . . . . . . . . . . . . . 18
9.2. Informative References . . . . . . . . . . . . . . . . . 18 9.2. Informative References . . . . . . . . . . . . . . . . . 19
Appendix A. Section Classification . . . . . . . . . . . . . . . 18 Appendix A. Section Classification . . . . . . . . . . . . . . . 19
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 18 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
The NFS version 4.0 specification [RFC7530] defines a migration The NFS version 4.0 specification [RFC7530] defines a migration
feature which enables the transfer of a file system from one server feature that enables the transfer of a file system from one server to
to another without disruption of client activity. There were a another without disruption of client activity. There were a number
number of issues with the original definition of this feature, now of issues with the original definition of this feature, now resolved
resolved with the publication of [RFC7931]. with the publication of [RFC7931].
After a migration event, a client must determine whether state After a migration event, a client must determine whether state
recovery is necessary. To do this, it needs to determine whether the recovery is necessary. To do this, it needs to determine whether the
source and destination server addresses represent the same server source and destination server addresses represent the same server
instance, if the client has already established a lease on the instance, if the client has already established a lease on the
destination server for other file systems, and if the destination destination server for other file systems, and if the destination
server instance has lock state for the migrated file system. server instance has lock state for the migrated file system.
As part of addressing this need, [RFC7931] introduces trunking into As part of addressing this need, [RFC7931] introduces trunking into
NFS version 4.0 along with a trunking detection mechanism. This NFS version 4.0 along with a trunking detection mechanism. A
enables a client to determine whether two distinct network addresses trunking detection mechanism enables a client to determine whether
are connected to the same NFS version 4.0 server instance. two distinct network addresses are connected to the same NFS version
Nevertheless, the use of the concept of server-trunkability is the 4.0 server instance. Without this knowledge, a client unaware of a
same in both protocol versions. trunking relationship between paths it is using simultaneously is
likely to become confused in ways described in [RFC7530].
NFSv4.1 was defined with an integral means of trunking detection,
described in [RFC5661]. NFSv4.0 initially did not have one, with it
being added by [RFC7931]. Nevertheless, the use of the concept of
server-trunkability is the same in both protocol versions.
File system migration, replication, and referrals are distinct File system migration, replication, and referrals are distinct
protocol features. However, it is not appropriate to treat each of protocol features. However, it is not appropriate to treat each of
these features in isolation. For example, client migration recovery these features in isolation. For example, client migration recovery
processing needs to deal with the possibility of multiple server processing needs to deal with the possibility of multiple server
addresses in a returned fs_locations attribute. In addition, the addresses in a returned fs_locations attribute. In addition, the
contents of the fs_locations attribute, which provides both trunking- contents of the fs_locations attribute, which provides both trunking-
related and replication information, may change over repeated related and replication information, may change over repeated
retrievals, requiring an integrated description of how clients are to retrievals, requiring an integrated description of how clients are to
deal with such changes. The issues discussed in the current document deal with such changes. The issues discussed in the current document
relate to the interpretation of the fs_locations attribute and to the relate to the interpretation of the fs_locations attribute and to the
proper client and server handling of changes in fs_locations proper client and server handling of changes in fs_locations
attribute values. attribute values.
Therefore the goals of this document are: Therefore the goals of the current document are:
o To provide NFS version 4.0 with a means of trunking discovery, o To provide NFS version 4.0 with a means of finding addresses
trunkable with a given address; i.e., trunking discovery,
compatible with the means of trunking detection introduced by compatible with the means of trunking detection introduced by
[RFC7931]. [RFC7931]. For an explanation of trunking detection and
discovery, see Section 3.
o To describe how NFS version 4.0 clients are to handle the presence o To describe how NFS version 4.0 clients are to handle the presence
of multiple network addresses associated to the same server, when of multiple network addresses associated to the same server, when
recovering from a replication and migration event. recovering from a replication and migration event.
o To describe how NFS version 4.0 clients are to handle changes in o To describe how NFS version 4.0 clients are to handle changes in
the contents of returned fs_locations attributes, including those the contents of returned fs_locations attributes, including those
that indicate changes in the responding NFS version 4.0 server's that indicate changes in the responding NFS version 4.0 server's
trunking configuration. trunking configuration.
skipping to change at page 5, line 29 skipping to change at page 5, line 36
a client builds on a trunking detection facility by providing one a client builds on a trunking detection facility by providing one
or more methods by which candidate addresses are made available to or more methods by which candidate addresses are made available to
the client, who then uses trunking detection to appropriately the client, who then uses trunking detection to appropriately
filter them. filter them.
Trunking discovery is not discussed in [RFC7530] and no Trunking discovery is not discussed in [RFC7530] and no
description of it is provided in [RFC7931]. description of it is provided in [RFC7931].
Discussion of the term "replica" is complicated for a number of Discussion of the term "replica" is complicated for a number of
reasons. Even though the term is used in explaining the issues in reasons. Even though the term is used in explaining the issues in
[RFC7530] that need to be addressed in this document, a full [RFC7530] that need to be addressed in the current document, a full
explanation of this term requires explanation of related terms explanation of this term requires explanation of related terms
connected to the fs_locations attribute, which is provided in connected to the fs_locations attribute, which is provided in
Section 5.1 of the current document. Section 5.1 of the current document.
The term is also used in previous documents about NFSv4.0 (i.e., The term is also used in previous documents about NFSv4.0 (i.e.,
[RFC7530] and [RFC7931]) with a meaning different from that in the [RFC7530] and [RFC7931]) with a meaning different from that in the
current document. In these documents each replica is identified by a current document. In these documents each replica is identified by a
single network access path. However, in the current document a set single network access path. However, in the current document a set
of network access paths which have server-trunkable network addresses of network access paths which have server-trunkable network addresses
and the same root-relative file system pathname are considered to be and the same root-relative file system pathname are considered to be
skipping to change at page 7, line 15 skipping to change at page 7, line 25
migration, replication and referral features of fs_locations. migration, replication and referral features of fs_locations.
Terminology used to describe the interactions is added. Terminology used to describe the interactions is added.
o Section 5.2 updates Section 8.4 of [RFC7530], entitled "Uses of o Section 5.2 updates Section 8.4 of [RFC7530], entitled "Uses of
Location Information". This section comprises the bulk of the Location Information". This section comprises the bulk of the
updates. Each paragraph of Section 8.4 and its sub-sections has updates. Each paragraph of Section 8.4 and its sub-sections has
been reviewed to clarify the provision of trunking-related been reviewed to clarify the provision of trunking-related
information using the fs_locations attribute. information using the fs_locations attribute.
* Section 5.2.1 replaces the introductory material within * Section 5.2.1 replaces the introductory material within
Section 8.4 of [RFC7530]. Section 8.4 of [RFC7530]; i.e., the material within Section 8.4
exclusive of subsections.
* Section 5.2.2 is to be added as a new sub-section of * Section 5.2.2 is to be added as a new sub-section of
Section 8.4 before the updated Section 8.4.1 of [RFC7530]. Section 8.4 before the updated Section 8.4.1 of [RFC7530]. In
a consolidated document, it would appear as Section 8.4.1.
* Section 5.2.3 is to be added as a new sub-section of * Section 5.2.3 is to be added as a new sub-section of
Section 8.4 before the updated Section 8.4.1 of [RFC7530]. Section 8.4 before the updated Section 8.4.1 of [RFC7530]. In
a consolidated document, it would appear as Section 8.4.2.
* Section 5.2.4 replaces Section 8.4.1 of [RFC7530], entitled * Section 5.2.4 replaces Section 8.4.1 of [RFC7530], entitled
"File System Replication". "File System Replication". In a consolidated document, it
would appear as Section 8.4.3.
* Section 5.2.5 replaces Section 8.4.2 of [RFC7530], entitled * Section 5.2.5 replaces Section 8.4.2 of [RFC7530], entitled
"File System Migration". "File System Migration". In a consolidated document, it would
appear as Section 8.4.4.
* Section 5.2.6 is to be added as a new sub-section of * Section 5.2.6 is to be added as a new sub-section of
Section 8.4 before Section 8.4.3 of [RFC7530]. Section 8.4 before Section 8.4.3 of [RFC7530]. In a
consolidated document, it would appear as Section 8.4.5, while
the existing Section 8.3 would appear as Section 8.4.6.
o Section 5.3 replaces Section 8.5 of [RFC7530], entitled "Location o Section 5.3 replaces Section 8.5 of [RFC7530], entitled "Location
Entries and Server Identity". The last paragraph of the existing Entries and Server Identity". The last paragraph of the existing
section has been removed. section has been removed.
5.1. Updated Section 8.1 of [RFC7530], entitled "Location Attributes" 5.1. Updated Section 8.1 of [RFC7530], entitled "Location Attributes"
The fs_locations attribute (described as "RECOMMENDED" in [RFC7530]) The fs_locations attribute allows specification of file system
allows specification of file system locations where the data locations where the data corresponding to a given file system may be
corresponding to a given file system may be accessed. This attribute accessed. This attribute represents such file system instances as a
represents such file system instances as a server address target (as server address target (as either a DNS host name representing one or
either a DNS host name representing one or more network addresses, or more network addresses, or a single literal network address) together
a single literal network address) together with the path of that file with the path of that file system within the associated single-server
system within the associated single-server namespace. Individual namespace. Individual fs_locations entries can express trunkable
fs_locations entries can express trunkable addresses, locations of addresses, locations of file system replicas on other servers,
file system replicas on other servers, migration targets, or pure migration targets, or pure referrals.
referrals.
We introduce the following terminology: We introduce the following terminology:
o Trunking is a situation in which multiple network addresses are o Trunking is a situation in which multiple network addresses are
connected to the same NFS server. Network addresses connected to connected to the same NFS server. Network addresses connected to
the same NFS server instance are said to be server-trunkable. the same NFS server instance are said to be server-trunkable.
o Trunking detection refers to ways of confirming that two distinct o Trunking detection refers to ways of confirming that two distinct
network addresses are connected to the same NFSv4 server instance. network addresses are connected to the same NFSv4 server instance.
skipping to change at page 8, line 33 skipping to change at page 8, line 47
Section 2.2.6) are the individual file system locations in the Section 2.2.6) are the individual file system locations in the
fs_locations attribute (defined in [RFC7530] Section 2.2.7). A fs_locations attribute (defined in [RFC7530] Section 2.2.7). A
file system location entry designates a set of network addresses file system location entry designates a set of network addresses
to which clients may establish connections. The entry may to which clients may establish connections. The entry may
designate multiple such addresses because the server host name may designate multiple such addresses because the server host name may
map to multiple network addresses, and because multiple connection map to multiple network addresses, and because multiple connection
types may be used to communicate with each specified network types may be used to communicate with each specified network
address. Such addresses provide multiple ways of connecting to a address. Such addresses provide multiple ways of connecting to a
single server. single server.
Clients use the existing means for NFSv4.0 trunking detection, Clients use the NFSv4.0 trunking detection mechanism [RFC7931] to
defined in [RFC7931], to confirm that such addresses are connected confirm that such addresses are connected to the same server. The
to the same server. The client can ignore addresses found not to client can ignore non-confirmed trunking relationships and treat
be so connected. the corresponding addresses as connected to different servers.
o File system location elements are derived from file system o File system location elements are derived from file system
location entries. If a file system location entry specifies a location entries. If a file system location entry specifies a
network address, there is only a single corresponding location network address, there is only a single corresponding location
element. When a file system location entry contains a host name, element. When a file system location entry contains a host name,
the client resolves the hostname, producing one file system the client resolves the hostname, producing one file system
location element for each of the resulting network addresses. location element for each of the resulting network addresses.
Issues regarding the trustworthiness of hostname resolutions are Issues regarding the trustworthiness of hostname resolutions are
further discussed in Section 7. further discussed in Section 7 of the current document.
o All file system location elements consist of a file system o All file system location elements consist of a file system
location address, which is the network address of an interface to location address, which is the network address of an interface to
a server, and an fs_name, which is the location of the file system a server, and an fs_name, which is the location of the file system
within the server's pseudo-fs. within the server's pseudo-fs.
o If the server has no pseudo-fs and only a single exported file o If the server has no pseudo-fs and only a single exported file
system at the root filehandle, the fs_name may be empty. system at the root filehandle, the fs_name may be empty.
5.2. Updates to Section 8.4 of [RFC7530], entitled "Uses of Location 5.2. Updates to Section 8.4 of [RFC7530], entitled "Uses of Location
skipping to change at page 9, line 41 skipping to change at page 10, line 6
When alternative file system locations are provided, they may When alternative file system locations are provided, they may
represent distinct physical copies of the same file system data or represent distinct physical copies of the same file system data or
separate NFS server instances that provide access to the same separate NFS server instances that provide access to the same
physical file system. Another possible use of the provision of physical file system. Another possible use of the provision of
multiple file system location entries is trunking, wherein the file multiple file system location entries is trunking, wherein the file
system location entries do not in fact represent different servers system location entries do not in fact represent different servers
but rather are distinct network paths to the same server. but rather are distinct network paths to the same server.
A client may use file system location elements simultaneously to A client may use file system location elements simultaneously to
provide higher-performance access to the target file system. The provide higher-performance access to the target file system. This
can be done using trunking, although the use of multiple replicas
simultaneously is possible. To enable simultaneous access, the
client utilizes trunking detection and/or discovery, further client utilizes trunking detection and/or discovery, further
described in Section 5.2.2 of the current document, to determine a described in Section 5.2.2 of the current document, to determine a
set of network paths that are server-trunkable with the one currently set of network paths that are server-trunkable with the one currently
being used to access the file system. being used to access the file system. Once this determination is
made, requests may be routed across multiple paths, using the
existing state management mechanism.
Multiple replicas may also be used simultaneously, typically used
when accessing read-only datasets. In this case, each replica
requires its own state management. The client performs multiple file
opens to read the same file content from multiple replicas.
When a file system is present and subsequently becomes absent, When a file system is present and subsequently becomes absent,
clients can be given the opportunity to have continued access to clients can be given the opportunity to have continued access to
their data at an alternative file system location. Transfer of the their data at an alternative file system location. Transfer of the
file system contents to the new file system location is referred to file system contents to the new file system location is referred to
as "migration". The client's responsibilities in dealing with this as "migration". The client's responsibilities in dealing with this
transition depend on the specific nature of the new access path as transition depend on the specific nature of the new access path as
well as how and whether data was in fact migrated. See Sections well as how and whether data was in fact migrated. See Sections
5.2.5 and 5.2.6 of the current document for details. 5.2.5 and 5.2.6 of the current document for details.
skipping to change at page 11, line 22 skipping to change at page 11, line 44
trunking. trunking.
When there is a means of trunking detection available, an NFSv4.0 When there is a means of trunking detection available, an NFSv4.0
client can confirm that a set of network addresses correspond to the client can confirm that a set of network addresses correspond to the
same NFSv4.0 server instance and thus any of them can be used to same NFSv4.0 server instance and thus any of them can be used to
access that server. access that server.
5.2.3. New Sub-section of Section 8.4 of [RFC7530], to be entitled 5.2.3. New Sub-section of Section 8.4 of [RFC7530], to be entitled
"Location Attributes and Connection Type Selection" "Location Attributes and Connection Type Selection"
NFS version 4.0 may be implemented using a number of different types
of connections:
Stream connections may be used to provide RPC service, as
described in [RFC5531].
RDMA-capable connections may be used to provide RPC service, as
described in [RFC8166].
Because of the need to support multiple connections, clients face the Because of the need to support multiple connections, clients face the
issue of determining the proper connection type to use when issue of determining the proper connection type to use when
establishing a connection to a server network address. The establishing a connection to a server network address. The
fs_locations attribute provides no information to support connection fs_locations attribute provides no information to support connection
type selection. As a result, clients supporting multiple connection type selection. As a result, clients supporting multiple connection
types need to attempt to establish a connection on various connection types need to attempt to establish a connection on various connection
types allowing it to determine which connection types are supported. types allowing it to determine, via a trial-and-error approach, which
connection types are supported.
If a client strongly prefers one connection type, it can perform If a client strongly prefers one connection type, it can perform
these attempts serially in order of declining preference. Once there these attempts serially in order of declining preference. Once there
is a successful attempt, the established connection can be used. is a successful attempt, the established connection can be used.
Note that with this approach, network partitions can result in a Note that with this approach, network partitions can result in a
sequence of long waits for a successful connection. sequence of long waits for a successful connection.
To avoid waiting when there is at least one viable network path To avoid waiting when there is at least one viable network path
available, simultaneous attempts to establish multiple connection available, simultaneous attempts to establish multiple connection
types are possible. Once a viable connection is established, the types are possible. Once a viable connection is established, the
skipping to change at page 12, line 47 skipping to change at page 13, line 31
writable but represents a read-only copy (possibly periodically writable but represents a read-only copy (possibly periodically
updated) of a writable file system, similar requirements apply to the updated) of a writable file system, similar requirements apply to the
propagation of updates. Any change visible in the original file propagation of updates. Any change visible in the original file
system must already be effected on all migration targets, to avoid system must already be effected on all migration targets, to avoid
any possibility that a client, in effecting a transition to the any possibility that a client, in effecting a transition to the
migration target, will see any reversion in file system state. migration target, will see any reversion in file system state.
5.2.6. New Sub-section of Section 8.4 of [RFC7530], to be entitled 5.2.6. New Sub-section of Section 8.4 of [RFC7530], to be entitled
"Interaction of Trunking, Migration, and Replication" "Interaction of Trunking, Migration, and Replication"
When the set of network addresses designated by a file system When the set of network addresses on a server change in a way that
location attribute changes, NFS4ERR_MOVED might or might not result. would affect a file system location attribute, there are several
In some of the cases in which NFS4ERR_MOVED is returned migration has possible outcomes for clients currently accessing that file system.
occurred, while in others there is a shift in the network addresses NFS4ERR_MOVED is returned only when the server cannot satisfy a
used to access a particular file system with no migration. request from the client, whether because the file system has been
migrated to a different server, is only accessible at a different
trunked address on the same server, or some other reason. In the
cases 1 and 2 below, NFS4ERR_MOVED is not returned.
1. When the list of network addresses is a superset of that 1. When the list of network addresses is a superset of that
previously in effect, there is no need for migration or any other previously in effect, there is no need for migration or any other
sort of client adjustment. Nevertheless, the client is free to sort of client adjustment. Nevertheless, the client is free to
use an additional address in the replacement list if that address use an additional address in the replacement list if that address
provides another path to the same server. Or, the client may provides another path to the same server. Or, the client may
treat that address as it does a replica, to be used if current treat that address as it does a replica, to be used if current
server addresses become unavailable. server addresses become unavailable.
2. When the list of network addresses is a subset of that previously 2. When the list of network addresses is a subset of that previously
in effect, immediate action is not needed if an address missing in effect, immediate action is not needed if an address missing
in the replacement list is not currently in use by the client. in the replacement list is not currently in use by the client.
The client should avoid using that address in the future, whether The client should avoid using that address to access that file
the address is for a replica or an additional path to the server system in the future, whether the address is for a replica or an
being used. additional path to the server being used.
3. When an address being removed is one of a number of paths to the 3. When an address being removed is one of a number of paths to the
current server, the client may continue to use it until current server, the client may continue to use it until
NFS4ERR_MOVED is received. This is not considered a migration NFS4ERR_MOVED is received. This is not considered a migration
event unless the last available path to the server has become event unless the last available path to the server has become
unusable. unusable.
When migration does occur, multiple addresses may be in use on the When migration does occur, multiple addresses may be in use on the
server previous to migration and multiple addresses may be available server previous to migration and multiple addresses may be available
for use on the destination server. for use on the destination server.
skipping to change at page 13, line 48 skipping to change at page 14, line 35
absolute. If a client is not aware of all network addresses for any absolute. If a client is not aware of all network addresses for any
reason, it may conclude that migration has occurred when it has not reason, it may conclude that migration has occurred when it has not
and treat a switch to a different server address as if it were a and treat a switch to a different server address as if it were a
migration event. This is harmless since the use of the same server migration event. This is harmless since the use of the same server
via a new address will appear as a successful instance of Transparent via a new address will appear as a successful instance of Transparent
State Migration. State Migration.
Although significant harm cannot arise from this misapprehension, it Although significant harm cannot arise from this misapprehension, it
can give rise to disconcerting situations. For example, if a lock can give rise to disconcerting situations. For example, if a lock
has been revoked during the address shift, it will appear to the has been revoked during the address shift, it will appear to the
client as if the lock has been lost during migration, normally client as if the lock has been lost during migration. When such a
calling for it to be recoverable via an fs-specific grace period lock is lost, it is the responsibility of the destination server to
associated with the migration event. provide for its recovery via the use of an fs-specific grace period.
With regard to the destination server, it is desirable for the client With regard to the destination server, it is desirable for the client
to be aware of all valid network addresses that can be used to access to be aware of all valid network addresses that can be used to access
the destination server. However, there is no need for this to be the destination server. However, there is no need for this to be
done immediately. Implementations can process the additional file done immediately. Implementations can process the additional file
system location elements in parallel with normal use of the first system location elements in parallel with normal use of the first
valid file system location entry found to access the destination. valid file system location entry found to access the destination.
Because a file system location attribute may include entries relating Because a file system location attribute may include entries relating
to the current server, the migration destination, and possible to the current server, the migration destination, and possible
replicas to use, scanning for available network addresses could replicas to use, scanning for available network addresses that might
be trunkable with addresses the client has already seen could
potentially be a long process. To keep this process as short as potentially be a long process. To keep this process as short as
possible, Servers are REQUIRED to place file system location entries possible, servers that provide information about trunkable network
that represent addresses usable with the current server or a paths are REQUIRED to place file system location entries that
migration target before those associated with replicas. A client can represent addresses usable with the current server or a migration
then cease scanning for trunkable file system location entries once target before those associated with replicas.
it encounters a file system location element whose fs_name differs
from the current fs_name, or whose address is not server-trunkable This ordering allows a client to cease scanning for trunkable file
with the one it is currently using. system location entries once it encounters a file system location
element whose fs_name differs from the current fs_name, or whose
address is not server-trunkable with the one it is currently using.
Although the possibility exists that a client might prematurely cease
scanning for trunkable addresses when receiving a location attribute
from an older server that does not follow the ordering constraint
above, the harm is expected to be limited since such servers would
not be expected to present information about trunkable server access
paths.
5.3. Updated Section 8.5 of [RFC7530], entitled "Location Entries and 5.3. Updated Section 8.5 of [RFC7530], entitled "Location Entries and
Server Identity Update" Server Identity Update"
As mentioned above, a single file system location entry may have a As mentioned above, a single file system location entry may have a
server address target in the form of a DNS host name that resolves to server address target in the form of a DNS host name that resolves to
multiple network addresses, while multiple file system location multiple network addresses; it is also possible for multiple file
entries may have their own server address targets that reference the system location entries to have their own server address targets that
same server. reference the same server.
When server-trunkable addresses for a server exist, the client may When server-trunkable addresses for a server exist, the client may
assume that for each file system in the namespace of a given server assume that for each file system in the namespace of a given server
network address, there exist file systems at corresponding namespace network address, there exist file systems at corresponding namespace
locations for each of the other server network addresses. It may do locations for each of the other server-trunkable network addresses.
this even in the absence of explicit listing in fs_locations. Such It may do this even in the absence of explicit listing in
corresponding file system locations can be used as alternative fs_locations. Such corresponding file system locations can be used
locations, just as those explicitly specified via the fs_locations as alternative locations, just as those explicitly specified via the
attribute. fs_locations attribute.
If a single file system location entry designates multiple server IP
addresses, the client should choose a single one to use. When two
server addresses are designated by a single file system location
entry and they correspond to different servers, this normally
indicates some sort of misconfiguration. The client should avoid
using such file system location entries when alternatives are
available. When they are not, the client should pick one of the IP
addresses and use it, without using others that are not directed to
the same server.
6. Updates to [RFC7530] Outside Section Eight 6. Updates to [RFC7530] Outside Section Eight
Since the existing description of NFS4ERR_MOVED in Section 13.1.2.4 Since the existing description of NFS4ERR_MOVED in Section 13.1.2.4
of [RFC7530] does not take proper account of trunking, it needs to be of [RFC7530] does not take proper account of trunking, it needs to be
modified by replacing the first two sentences of the description with modified by replacing the first two sentences of the description with
the following material: the following material:
The file system that contains the current filehandle object cannot The file system that contains the current filehandle object cannot
be accessed using the current network address. It may be be accessed using the current network address. It may be
skipping to change at page 16, line 33 skipping to change at page 17, line 39
with an NFSv4 server, it SHOULD, as stated above, be done using with an NFSv4 server, it SHOULD, as stated above, be done using
RPCSEC_GSS with integrity protection. RPCSEC_GSS with integrity protection.
When file system location information cannot be protected in When file system location information cannot be protected in
transit, the client can subject it to additional filtering to transit, the client can subject it to additional filtering to
prevent the client from being inappropriately directed. For prevent the client from being inappropriately directed. For
example, if a range of network addresses can be determined that example, if a range of network addresses can be determined that
assure that the servers and clients using AUTH_SYS are subject to assure that the servers and clients using AUTH_SYS are subject to
appropriate constraints (such as physical network isolation and appropriate constraints (such as physical network isolation and
the use of administrative controls within the operating systems), the use of administrative controls within the operating systems),
then network adresses in this range can be used with others then network adresses in this range can be used, with others
discarded or restricted in their use of AUTH_SYS. discarded or restricted in their use of AUTH_SYS.
When neither integrity protection nor filtering is possible, it is When neither integrity protection nor filtering is possible, it is
best for the client to ignore trunking and replica information or best for the client to ignore trunking and replica information or
simply not fetch the file system location information for these simply not fetch the file system location information for these
purposes. purposes.
To summarize considerations regarding the use of RPCSEC_GSS in To summarize considerations regarding the use of RPCSEC_GSS in
fetching file system location information, consider the following fetching file system location information, consider the following
possibilities for requests to interrogate location information, recommendations for requests to interrogate location information,
with interrogation approaches on the referring and destination with interrogation approaches on the referring and destination
servers arrived at separately: servers arrived at separately:
o The use of RPCSEC_GSS with integrity protection is RECOMMENDED o The use of RPCSEC_GSS with integrity protection is RECOMMENDED
in all cases, since the absence of integrity protection exposes in all cases, since the absence of integrity protection exposes
the client to the possibility of the results being modified in the client to the possibility of the results being modified in
transit. transit.
o The use of requests issued without RPCSEC_GSS (e.g., using o The use of requests issued without RPCSEC_GSS (e.g., using
AUTH_SYS), while undesirable, might be unavoidable in some AUTH_SYS), while undesirable, might be unavoidable in some
cases. Where the use of returned file system location cases. Where the use of returned file system location
information cannot be avoided, it should be subject to information cannot be avoided, it should be subject to
filtering to eliminate untrusted network addresses. The filtering to eliminate untrusted network addresses. The
specifics will vary depending on the degree of network specifics will vary depending on the degree of network
isolation and whether the request is to the referring or isolation and whether the request is to the referring or
destination servers. destination servers.
Privacy considerations relating to uniform client strings (UCS)
vs. non-uniform client strings (non-UCS), discussed in
Section 5.6 of [RFC7931], are also applicable to their usage for
trunking detection in NFS version 4.0.
8. IANA Considerations 8. IANA Considerations
This document does not require actions by IANA. This document does not require actions by IANA.
9. References 9. References
9.1. Normative References 9.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,
skipping to change at page 18, line 27 skipping to change at page 19, line 36
[RFC7861] Adamson, A. and N. Williams, "Remote Procedure Call (RPC) [RFC7861] Adamson, A. and N. Williams, "Remote Procedure Call (RPC)
Security Version 3", RFC 7861, DOI 10.17487/RFC7861, Security Version 3", RFC 7861, DOI 10.17487/RFC7861,
November 2016, <https://www.rfc-editor.org/info/rfc7861>. November 2016, <https://www.rfc-editor.org/info/rfc7861>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
Appendix A. Section Classification Appendix A. Section Classification
All sections of this document are considered explanatory with the All sections of the current document are considered explanatory with
following exceptions. the following exceptions.
o Sections 5.1 and 5.2.1 are replacement sections. o Sections 5.1 and 5.2.1 are replacement sections.
o Section 5.2.2 is an additional section. o Section 5.2.2 is an additional section.
o Sections 5.2.4 and 5.2.5 are replacement sections. o Sections 5.2.4 and 5.2.5 are replacement sections.
o Section 5.2.6 is an additional section. o Section 5.2.6 is an additional section.
o Section 5.3 is a replacement section. o Section 5.3 is a replacement section.
skipping to change at page 18, line 52 skipping to change at page 20, line 13
o Section 7 is an additional section. o Section 7 is an additional section.
Acknowledgments Acknowledgments
The authors wish to thank Andy Adamson, who wrote the original The authors wish to thank Andy Adamson, who wrote the original
version of this document. All the innovation in this document is the version of this document. All the innovation in this document is the
result of Andy's work, while mistakes are best ascribed to the result of Andy's work, while mistakes are best ascribed to the
current authors. current authors.
The editor wishes to thank Greg Marsden for his support of this work, The editor wishes to thank Greg Marsden for his support of this work,
and Robert Thurlow for review and suggestions. and Robert Thurlow for his review and suggestions.
Special thanks go to Transport Area Director Spencer Dawkins, NFSV4 Special thanks go to Transport Area Director Spencer Dawkins, NFSV4
Working Group Chairs Spencer Shepler and Brian Pawlowski, and NFSV4 Working Group Chairs Spencer Shepler and Brian Pawlowski, and NFSV4
Working Group Secretary Thomas Haynes for their ongoing support. Working Group Secretary Thomas Haynes for their ongoing support. We
are also grateful for the thorough review of this document by
Benjamin Kaduk and Ben Campbell.
Authors' Addresses Authors' Addresses
Charles Lever (editor) Charles Lever (editor)
Oracle Corporation Oracle Corporation
United States of America United States of America
Email: chuck.lever@oracle.com Email: chuck.lever@oracle.com
David Noveck David Noveck
 End of changes. 41 change blocks. 
89 lines changed or deleted 151 lines changed or added

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