draft-ietf-nfsv4-mv0-trunking-update-00.txt   draft-ietf-nfsv4-mv0-trunking-update-01.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: July 11, 2018 January 7, 2018 Expires: January 17, 2019 July 16, 2018
NFS version 4.0 Trunking Update NFS version 4.0 Trunking Update
draft-ietf-nfsv4-mv0-trunking-update-00 draft-ietf-nfsv4-mv0-trunking-update-01
Abstract Abstract
The location-related attribute in NFS version 4.0, fs_locations, is The location-related attribute in NFS version 4.0, fs_locations,
used to support the migration and replication of server file systems. informs clients about alternate locations of file systems. An NFS
This document describes an additional use for this attribute as a version 4.0 client can use this information to handle migration and
mechanism for an NFS version 4.0 client to discover an NFS version replication of server filesystems. This document describes how an
4.0 server's trunking capabilities. The interaction of trunking with NFS version 4.0 client can additionally use this information to
migration and replication is also clarified. This document updates discover an NFS version 4.0 server's trunking capabilities. This
RFC 7530. document updates RFC 7530.
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 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 July 11, 2018. This Internet-Draft will expire on January 17, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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
skipping to change at page 2, line 20 skipping to change at page 2, line 20
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Preliminaries . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Preliminaries . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
3.2. Document Organization . . . . . . . . . . . . . . . . . . 5 3.2. Document Organization . . . . . . . . . . . . . . . . . . 5
3.3. Document Goals . . . . . . . . . . . . . . . . . . . . . 6 3.3. Document Goals . . . . . . . . . . . . . . . . . . . . . 6
4. Overview of changes in RFC7530 Section 8 . . . . . . . . . . 6 4. Overview of changes in RFC7530 Section 8 . . . . . . . . . . 6
5. Location Attributes (as updated) . . . . . . . . . . . . . . 7 5. Location Attributes (as updated) . . . . . . . . . . . . . . 7
6. Updates to RFC7530 Section 8.4 (Uses of Location Information) 8 6. Updates to RFC7530 Section 8.4 (Uses of Location Information) 8
6.1. Introduction to uses of Location Information (as updated) 8 6.1. Introduction to uses of Location Information (as updated) 8
6.2. Trunking Discovery and Detection (to be added) . . . . . 9 6.2. Trunking Discovery and Detection (to be added) . . . . . 10
6.3. File System Replication and Trunking (as updated) . . . . 10 6.3. Location Attributes and Connection Type Selection (to be
6.4. File System Migration (as updated) . . . . . . . . . . . 10 added) . . . . . . . . . . . . . . . . . . . . . . . . . 11
6.5. Interaction of Trunking, Migration, and Replication (to 6.4. File System Replication and Trunking (as updated) . . . . 11
be added) . . . . . . . . . . . . . . . . . . . . . . . . 11 6.5. File System Migration (as updated) . . . . . . . . . . . 11
7. Location Entries and Server Identity Update (as updated) . . 12 6.6. Interaction of Trunking, Migration, and Replication (to
8. Updates to RFC7530 Outside Section Eight . . . . . . . . . . 13 be added) . . . . . . . . . . . . . . . . . . . . . . . . 12
9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. Location Entries and Server Identity Update (as updated) . . 13
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 8. Updates to RFC7530 Outside Section Eight . . . . . . . . . . 14
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14
11.1. Normative References . . . . . . . . . . . . . . . . . . 15 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
11.2. Informative References . . . . . . . . . . . . . . . . . 16 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
Appendix A. Section Classification . . . . . . . . . . . . . . . 16 11.1. Normative References . . . . . . . . . . . . . . . . . . 16
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17 11.2. Informative References . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Appendix A. Section Classification . . . . . . . . . . . . . . . 17
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
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 which enables the transfer of a file system from one server
to another without disruption of client activity. There were a to another without disruption of client activity. There were a
number of issues with the original definition of this feature, now number of issues with the original definition of this feature, now
resolved with the publication of [RFC7931]. resolved 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 into NFS As part of addressing this need, [RFC7931] introduces into NFS
version 4.0 a trunking detection mechanism to enable a client to version 4.0 a trunking detection mechanism to enable a client to
determine whether two distinct network addresses are connected to the determine whether two distinct network addresses are connected to the
same NFS version 4.0 server instance; i.e., are trunked. Even so, same NFS version 4.0 server instance. Despite this addition, the NFS
the NFS version 4.0 specification remains without a complete version 4.0 specification remains without a complete discussion of
discussion of trunking. trunking.
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
skipping to change at page 3, line 39 skipping to change at page 3, line 39
document are to be interpreted as described in BCP 14 [RFC2119] document are to be interpreted as described in BCP 14 [RFC2119]
[RFC8174] when, and only when, they appear in all capitals, as shown [RFC8174] when, and only when, they appear in all capitals, as shown
here. here.
3. Preliminaries 3. Preliminaries
3.1. Terminology 3.1. Terminology
Most of the terms related to handling the fs_locations attribute are Most of the terms related to handling the fs_locations attribute are
appropriately defined in Section 5 below. However, there are a few appropriately defined in Section 5 below. However, there are a few
terms used outside that context that are explained here. terms used outside that context that are explained in this section.
Regarding network addresses and the handling of trunking we use the Regarding network addresses and the handling of trunking we use the
following terminology: following terminology:
o Each NFSv4 server is assumed to have a set of IP addresses to o Each NFSv4 server is assumed to have a set of IP addresses to
which NFSv4 requests may be sent by clients. These are referred which NFSv4 requests may be sent by clients. These are referred
to as the server's network addresses. to as the server's network addresses. Access to a specific server
network address might involve the use of multiple network ports,
since the ports to be used for particular types of connections
might be required to be different.
o Clients may establish connections to NFSv4 servers via one of
several connection types, supporting the NFSv4 protocol layered on
top of an RPC stream transport, as described in [RFC5531], or on
top of RPC-over-RDMA, as described in [RFC8166].
o The combination of a server network address and a particular
connection type is referred to as a "server endpoint". Using
different connection types typically results in the use of
different ports. However, the use of different ports by multiple
connections to the same network address is not the essence of the
distinction between the two endpoints used.
o Each network address, when combined with a pathname providing the o Each network address, when combined with a pathname providing the
location of a file system root directory relative to the location of a file system root directory relative to the
associated server root file handle, defines a file system network associated server root file handle, defines a file system network
access path. access path.
o Two network addresses connected to the same server are said to be o Two network addresses connected to the same server are said to be
server-trunkable. server-trunkable.
Particularly important is the distinction between trunking detection Particularly important is the distinction between trunking detection
skipping to change at page 4, line 22 skipping to change at page 4, line 36
o Trunking detection refers to ways of confirming that two unique o Trunking detection refers to ways of confirming that two unique
network addresses are associated with the same NFSv4 server network addresses are associated with the same NFSv4 server
instance. The means available to make this determination depends instance. The means available to make this determination depends
on the protocol version and, in some cases, on the client on the protocol version and, in some cases, on the client
implementation. implementation.
In the case of NFS version 4.0, the means to be used are described In the case of NFS version 4.0, the means to be used are described
in [RFC7931] and require use of the Uniform Client String approach in [RFC7931] and require use of the Uniform Client String approach
to be effective. This is in contrast to later minor versions for to be effective. This is in contrast to later minor versions for
which the means of trunking detection are described by [RFC5661] which the means of trunking detection are described by [RFC5661].
and are available to every NFS version 4.0 client.
o Trunking discovery is a process by which an NFSv4 client, o Trunking discovery is a process by which an NFSv4 client,
accessing one server network address, can obtain other addresses accessing one server network address, can obtain other addresses
that might be associated with the same server instance. Typically that might be associated with the same server instance. Typically
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. reasons. Even though the term is used in explaining the issues in
[RFC7530] that need to be addressed in this document, a full
Even though the term is used in explaining the issues in [RFC7530] explanation of this term requires explanation of related terms
that need to be addressed in this document, a full explanation of connected to the fs_locations attribute, which is provided in
this term requires explanation of related terms connected to the Section 5 of the current document.
fs_locations attribute, which is provided in Section 5 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], [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
a single replica with multiple network access paths. Although a single replica with multiple network access paths. Although
[RFC7931] allowed the client to determine whether two addresses were [RFC7931] enables an NFSv4.0 client to determine whether two network
server-trunkable, it never described these as connected to a single addresses were server-trunkable, it never described these as
replica, leaving in effect the approach established in [RFC7530]. connected to a single replica, leaving in effect the approach
established in [RFC7530].
3.2. Document Organization 3.2. Document Organization
The sections of the current document are divided into four types The sections of the current document are divided into four types
based on how they relate to the eventual updating of the NFS verion based on how they relate to the eventual updating of the NFS verion
4.0 specification. Once this update is published, NFS version 4.0 4.0 specification. Once this update is published, NFS version 4.0
will be specified by multiple documents that need to be read will be specified by multiple documents that need to be read
together, until such time as a consolidated replacement specification together, until such time as a consolidated replacement specification
is produced. is produced.
skipping to change at page 6, line 23 skipping to change at page 6, line 32
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.
The current document pursues these goals by presenting a set of The current document pursues these goals by presenting a set of
updates to [RFC7530] as summarized in Section 4 below. updates to [RFC7530] as summarized in Sections 4 and 8 below.
4. Overview of changes in RFC7530 Section 8 4. Overview of changes in RFC7530 Section 8
With a few small exceptions (see below), all of the updates to With a few small exceptions (see below), all of the updates to
[RFC7530] to provide support for trunking using the fs_locations [RFC7530] to provide support for trunking using the fs_locations
attribute apply to Section 8 of that document, entitled "Multi-Server attribute apply to Section 8 of that document, entitled "Multi-Server
Namespace". Namespace".
o Section 5 replaces Section 8.1 of [RFC7530], entitled "Location o Section 5 replaces Section 8.1 of [RFC7530], entitled "Location
Attributes". This section has been reorganized and extended to Attributes". This section has been reorganized and extended to
skipping to change at page 6, line 51 skipping to change at page 7, line 11
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 6.1 replaces the introductory material within * Section 6.1 replaces the introductory material within
Section 8.4 of [RFC7530]. Section 8.4 of [RFC7530].
* Section 6.2 is to be added after the introductory material * Section 6.2 is to be added after the introductory material
within Section 8.4 of [RFC7530]. within Section 8.4 of [RFC7530].
* Section 6.3 replaces Section 8.4.1 of [RFC7530], entitled "File * Section 6.4 replaces Section 8.4.1 of [RFC7530], entitled "File
System Replication". System Replication".
* Section 6.4 replaces Section 8.4.2 of [RFC7530], entitled "File * Section 6.5 replaces Section 8.4.2 of [RFC7530], entitled "File
System Migration". System Migration".
* Section 6.5 is to be added after the updated Section 8.4.2 of * Section 6.6 is to be added after the updated Section 8.4.2 of
[RFC7530]. [RFC7530].
o Section 7 replaces Section 8.5 of [RFC7530], entitled "Location o Section 7 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.
o A small set of updates outside Section 8 of [RFC7530] are o A small set of updates outside Section 8 of [RFC7530] are
presented in Section 8. presented in Section 8.
o Section 9 introduces additional security considerations that are o Section 9 introduces additional security considerations that are
to be added to those within Section 19 of [RFC7530], entitled to be added to those within Section 19 of [RFC7530], entitled
"Security Considerations". "Security Considerations".
5. Location Attributes (as updated) 5. Location Attributes (as updated)
The fs_locations RECOMMENDED attribute allows specification of file The fs_locations attribute (described as "RECOMMENDED" in [RFC7530])
system locations where the data corresponding to a given file system allows specification of file system locations where the data
may be accessed. This attribute represents such file system corresponding to a given file system may be accessed. This attribute
instances as a server address target (as either a DNS host name represents such file system instances as a server address target (as
representing one or more network addresses, or a single literal either a DNS host name representing one or more network addresses, or
network address) together with the path of that file system within a single literal network address) together with the path of that file
the associated single-server namespace. Individual fs_locations system within the associated single-server namespace. Individual
entries can express trunkable addresses, locations of file system fs_locations entries can express trunkable addresses, locations of
replicas on other servers, migration targets, or pure referrals. file system replicas on other servers, migration targets, or pure
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 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.
o Trunking discovery is a process by which a client using one o Trunking discovery is a process by which a client using one
network address can obtain other candidate addresses that are network address can obtain other candidate addresses that are
server-trunkable with it. server-trunkable with it.
Regarding terminology relating to GETATTR attributes used in trunking Regarding terminology relating to GETATTR attributes used in trunking
discovery and other multi-server namespace features: discovery and other multi-server namespace features:
o Location attributes include only the fs_locations GETATTR
attribute.
o Location entries (fs_location4, defined in [RFC7530] o Location entries (fs_location4, defined in [RFC7530]
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). fs_locations attribute (defined in [RFC7530] Section 2.2.7). A
location entry designates a set of network addresses to which
clients may establish connections. The entry may designate
multiple such addresses because the server host name may map to
multiple network addresses, and because multiple connection types
may be used to communicate with each specified network address.
All such addresses MUST provide a way of connecting to a single
server.
o Location elements are derived from location entries. If a o Location elements are derived from location entries. If a
location entry specifies a network address there is only a single location entry specifies a network address there is only a single
corresponding location element. When a location entry contains a corresponding location element. When a location entry contains a
host name, the host name is resolved by the client, producing one host name, the host name is resolved by the client, producing one
location element for each of the resulting network addresses. location element for each of the resulting network addresses.
o All location elements consist of a location address, which is the o All location elements consist of a location address, which is the
network address of an interface to a server, and an fs_name, which network address of an interface to a server, and an fs_name, which
is the location of the file system within the server's pseudo-fs. is the location of the file system within the server's pseudo-fs.
o The fs_name is empty if the server has no pseudo-fs and only a o If the server has no pseudo-fs and only a single exported file
single exported file system at the root filehandle. system at the root filehandle, the fs_name may be empty.
6. Updates to RFC7530 Section 8.4 (Uses of Location Information) 6. Updates to RFC7530 Section 8.4 (Uses of Location Information)
The subsections below provide replacement sections for existing The subsections below provide replacement sections for existing
sections within Section 8.4 of [RFC7530] or new sub-sections to be sections within Section 8.4 of [RFC7530] or new sub-sections to be
added to that section. added to that section.
6.1. Introduction to uses of Location Information (as updated) 6.1. Introduction to uses of Location Information (as updated)
Together with the possibility of absent file systems, the location- Together with the possibility of absent file systems, the location-
bearing attribute fs_locations provides a number of important bearing attribute fs_locations provides a number of important
facilities that enable reliable, manageable, and scalable data facilities that enable reliable, manageable, and scalable data
access. access.
When a file system is present, this attribute can provide alternative When a file system is present on the queried server, this attribute
locations to be used to access the same data in the event of server can provide a set of locations that clients may use to access the
failure, communications problems, or other difficulties that make file system. In the event that server failure, communications
continued access to the current file system impossible or otherwise problems, or other difficulties make continued access to the file
impractical. Provision of such alternative locations is referred to system impossible or otherwise impractical, the returned information
as "replication". provides alternate locations that enable continued access to the file
system. Provision of such alternative locations is referred to as
"replication".
One type of replication is trunking, where the location entries do When alternative locations are provided, they may represent distinct
not in fact represent different servers but are instead distinct physical copies of the same file system data or separate NFS server
network paths to the same server. A client may use location elements instances that provide access to the same physical file system.
simultaneously to provide higher-performance access to the target Another possible use of the provision of multiple location entries is
file system. The client utilizes trunking detection and/or trunking, wherein the location entries do not in fact represent
discovery, further described in Section 6.2 of the current document, different servers but rather are distinct network paths to the same
to determine if location elements are server-trunkable. server.
Alternative locations may also represent physical replicas of the A client may use location elements simultaneously to provide higher-
same file system data or, in the case of various forms of server performance access to the target file system. The client utilizes
clustering, another server providing access to the same physical file trunking detection and/or discovery, further described in Section 6.2
of the current document, to determine a set of network paths that are
server-trunkable with the one currently being used to access the file
system. system.
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 location. Transfer of the file system their data at an alternative location. Transfer of the file system
contents to the new location is referred to as "migration". The contents to the new location is referred to as "migration". The
client's responsibilities in dealing with this transition depend on client's responsibilities in dealing with this transition depend on
the specific nature of the new access path as well as how and whether the specific nature of the new access path as well as how and whether
data was in fact migrated. See Section 6.4 and Section 6.5 of the data was in fact migrated. See Sections 6.5 and 6.6 of the current
current document for details. document for details.
The fs_locations attribute can designate one or more remote locations The fs_locations attribute can designate one or more remote locations
in place of an absent file system. This is known as a "referral". A in place of an absent file system. This is known as a "referral". A
particularly important case is that of a "pure referral", in which particularly important case is that of a "pure referral", in which
the absent file system has never been present on the NFS server. the absent file system has never been present on the NFS server.
Such a referral is a means by which a file system located on one Such a referral is a means by which a file system located on one
server can redirect clients to file systems located on other servers, server can redirect clients to file systems located on other servers,
thus enabling the creation of a multi-server namespace. thus enabling the creation of a multi-server namespace.
Because client support for the fs_locations attribute is OPTIONAL, a Because client support for the fs_locations attribute is OPTIONAL, a
skipping to change at page 9, line 36 skipping to change at page 10, line 18
are associated with the same NFS server instance. As a matter of are associated with the same NFS server instance. As a matter of
convenience, we say that two network addresses connected to the same convenience, we say that two network addresses connected to the same
NFS server instance are server-trunkable. Section 5.4 of [RFC7931] NFS server instance are server-trunkable. Section 5.4 of [RFC7931]
explains why NFSv4 clients need to be aware of NFS server identity to explains why NFSv4 clients need to be aware of NFS server identity to
manage lease and lock state effectively when multiple connections to manage lease and lock state effectively when multiple connections to
the same server exist. the same server exist.
Trunking detection refers to a way for an NFSv4 client to confirm Trunking detection refers to a way for an NFSv4 client to confirm
that two independently acquired network addresses are connected to that two independently acquired network addresses are connected to
the same NFSv4 server. Section 5.8 of [RFC7931] describes an the same NFSv4 server. Section 5.8 of [RFC7931] describes an
OPTIONAL means by which it can be determined if two server network OPTIONAL means by which it can be determined if two network addresses
addresses correspond to the same NFSv4.0 server instance. Without correspond to the same NFSv4.0 server instance. Without trunking
trunking detection, an NFSv4.0 client has no other way to confirm detection, an NFSv4.0 client has no other way to confirm that two
that two network addresses are server-trunkable. network addresses are server-trunkable.
In the particular context of NFS version 4.0, trunking detection In the particular context of NFS version 4.0, trunking detection
requires that the client support the Uniform Client ID String requires that the client support the Uniform Client ID String
approach (UCS), described in Section 5.6 of [RFC7931]. Any NFSv4.0 approach (UCS), described in Section 5.6 of [RFC7931]. Any NFSv4.0
client that supports migration or trunking detection needs to present client that supports migration or trunking detection needs to present
a Uniform Client ID String to all NFSv4.0 servers. If it does not do a Uniform Client ID String to all NFSv4.0 servers. If it does not do
so, it will be unable to perform trunking detection. so, it will be unable to perform trunking detection.
Trunking discovery is the process by which an NFSv4 client using a Trunking discovery is the process by which an NFSv4 client using a
host name or one of an NFSv4 server's network addresses can obtain host name or one of an NFSv4 server's network addresses can obtain
skipping to change at page 10, line 21 skipping to change at page 11, line 5
o Location entries returned in an fs_locations attribute can specify o Location entries returned in an fs_locations attribute can specify
network addresses. These network addresses are candidates for network addresses. These network addresses are candidates for
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.
6.3. File System Replication and Trunking (as updated) 6.3. Location Attributes and Connection Type Selection (to be added)
Because of the need to support multiple connections, clients face the
issue of determining the proper connection type to use when
establishing a connection to a server network address. The
fs_locations attribute provides no information to support connection
type selection. As a result, clients supporting multiple connection
types need to attempt to establish a connection on various connection
types until the one preferred by the client is successfully
established.
6.4. File System Replication and Trunking (as updated)
On first access to a file system, the client should obtain the value On first access to a file system, the client should obtain the value
of the set of alternative locations by interrogating the fs_locations of the set of alternative locations by interrogating the fs_locations
attribute. Trunking discovery and/or detection can then be applied attribute. Trunking discovery and/or detection can then be applied
to the location entries to separate the candidate server-trunkable to the location entries to separate the candidate server-trunkable
addresses from the replica addresses that provide alternative addresses from the replica addresses that provide alternative
locations of the file system. Server-trunkable addresses may be used locations of the file system. Server-trunkable addresses may be used
simultaneously to provide higher performance through the exploitation simultaneously to provide higher performance through the exploitation
of multiple paths between client and target file system. of multiple paths between client and target file system.
In the event that server failures, communications problems, or other In the event that server failures, communications problems, or other
difficulties make continued access to the current file system difficulties make continued access to the current file system
impossible or otherwise impractical, the client can use the impossible or otherwise impractical, the client can use the
alternative locations as a way to maintain continued access to the alternative locations as a way to maintain continued access to the
file system. See Section 6.5 of the current document for more file system. See Section 6.6 of the current document for more
detail. detail.
6.4. File System Migration (as updated) 6.5. File System Migration (as updated)
When a file system is present and becomes absent, clients can be When a file system is present and becomes absent, clients can be
given the opportunity to have continued access to their data, at an given the opportunity to have continued access to their data at an
alternative location specified by the fs_locations attribute. alternative location specified by the fs_locations attribute.
Typically, a client will be accessing the file system in question, Typically, a client will be accessing the file system in question,
get an NFS4ERR_MOVED error, and then use the fs_locations attribute get an NFS4ERR_MOVED error, and then use the fs_locations attribute
to determine the new location of the data. See Section 6.5 of the to determine the new location of the data. See Section 6.6 of the
current document for more detail. current document for more detail.
Such migration can be helpful in providing load balancing or general Such migration can help provide load balancing or general resource
resource reallocation. The protocol does not specify how the file reallocation. The protocol does not specify how the file system will
system will be moved between servers. It is anticipated that a be moved between servers. It is anticipated that a number of
number of different server-to-server transfer mechanisms might be different server-to-server transfer mechanisms might be used, with
used, with the choice left to the server implementer. The NFSv4 the choice left to the server implementer. The NFSv4 protocol
protocol specifies the method used to communicate the migration event specifies the method used to communicate the migration event between
between client and server. client and server.
When an alternative location is designated as the target for When an alternative location is designated as the target for
migration, it must designate the same data. Where file systems are migration, it must designate the same data. Where file systems are
writable, a change made on the original file system must be visible writable, a change made on the original file system must be visible
on all migration targets. Where a file system is not writable but on all migration targets. Where a file system is not writable but
represents a read-only copy (possibly periodically updated) of a represents a read-only copy (possibly periodically updated) of a
writable file system, similar requirements apply to the propagation writable file system, similar requirements apply to the propagation
of updates. Any change visible in the original file system must of updates. Any change visible in the original file system must
already be effected on all migration targets, to avoid any already be effected on all migration targets, to avoid any
possibility that a client, in effecting a transition to the migration possibility that a client, in effecting a transition to the migration
target, will see any reversion in file system state. target, will see any reversion in file system state.
6.5. Interaction of Trunking, Migration, and Replication (to be added) 6.6. Interaction of Trunking, Migration, and Replication (to be added)
When the set of network addresses designated by a location attribute When the set of network addresses designated by a location attribute
changes, NFS4ERR_MOVED might or might not result. In some of the changes, NFS4ERR_MOVED might or might not result. In some of the
cases in which NFS4ERR_MOVED is returned migration has occurred, cases in which NFS4ERR_MOVED is returned migration has occurred,
while in others there is a shift in the network addresses used to while in others there is a shift in the network addresses used to
access a particular file system with no migration. access a particular file system with no migration.
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
skipping to change at page 12, line 10 skipping to change at page 13, line 5
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.
With regard to the server in use, it may be that return of With regard to the server in use, it may be that return of
NFS4ERR_MOVED indicates that a particular network address is no NFS4ERR_MOVED indicates that a particular network address is no
longer to be used, without implying that migration of the file system longer to be used, without implying that migration of the file system
to a different server is needed. Clients should not conclude that to a different server is needed. Clients should not conclude that
migration has occurred until confirming that all network addresses migration has occurred until confirming that all network addresses
known to be associated with the server are not usable. known to be associated with that server are not usable.
It should be noted that the need to defer this determination is not It should be noted that the need to defer this determination is not
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.
While significant harm will not 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, normally
calling for it to be recoverable via an fs-specific grace period calling for it to be recoverable via an fs-specific grace period
associated with the migration event. associated with the migration event.
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 the valid network addresses that can be used to to be aware of all valid network addresses that can be used to access
access the destination server. However, there is no need for this to the destination server. However, there is no need for this to be
be done immediately. Implementations can process the additional done immediately. Implementations can process the additional
location elements in parallel with normal use of the first valid location elements in parallel with normal use of the first valid
location entry found to access the destination. location entry found to access the destination.
Because a location attribute may include entries relating to the Because a location attribute may include entries relating to the
current server, the migration destination, and possible replicas to current server, the migration destination, and possible replicas to
use, scanning for available network addresses could potentially be a use, scanning for available network addresses could potentially be a
long process. To keep this process as short as possible, Servers are long process. To keep this process as short as possible, Servers are
REQUIRED to place location entries that represent addresses usable REQUIRED to place location entries that represent addresses usable
with the current server or a migration target before those associated with the current server or a migration target before those associated
with replicas. A client can then cease scanning for trunkable with replicas. A client can then cease scanning for trunkable
skipping to change at page 16, line 10 skipping to change at page 17, line 5
[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, <https://www.rfc-editor.org/info/rfc7530>. March 2015, <https://www.rfc-editor.org/info/rfc7530>.
[RFC7931] Noveck, D., Ed., Shivam, P., Lever, C., and B. Baker, [RFC7931] Noveck, D., Ed., Shivam, P., Lever, C., and B. Baker,
"NFSv4.0 Migration: Specification Update", RFC 7931, "NFSv4.0 Migration: Specification Update", RFC 7931,
DOI 10.17487/RFC7931, July 2016, DOI 10.17487/RFC7931, July 2016,
<https://www.rfc-editor.org/info/rfc7931>. <https://www.rfc-editor.org/info/rfc7931>.
[RFC8166] Lever, C., Ed., Simpson, W., and T. Talpey, "Remote Direct
Memory Access Transport for Remote Procedure Call Version
1", RFC 8166, DOI 10.17487/RFC8166, June 2017,
<https://www.rfc-editor.org/info/rfc8166>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
11.2. Informative References 11.2. Informative References
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", Rose, "DNS Security Introduction and Requirements",
RFC 4033, DOI 10.17487/RFC4033, March 2005, RFC 4033, DOI 10.17487/RFC4033, March 2005,
<https://www.rfc-editor.org/info/rfc4033>. <https://www.rfc-editor.org/info/rfc4033>.
skipping to change at page 16, line 44 skipping to change at page 17, line 44
Appendix A. Section Classification Appendix A. Section Classification
All sections of this document are considered explanatory with the All sections of this document are considered explanatory with the
following exceptions. following exceptions.
o Sections 5 and 6.1 are replacement sections. o Sections 5 and 6.1 are replacement sections.
o Section 6.2 is an additional section. o Section 6.2 is an additional section.
o Sections 6.3 and 6.4 are replacement sections. o Sections 6.4 and 6.5 are replacement sections.
o Section 6.5 is an additional section. o Section 6.6 is an additional section.
o Section 7 is a replacement section. o Section 7 is a replacement section.
o Section 8 is an editing section. o Section 8 is an editing section.
o Section 9 is an additional section. o Section 9 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 of Oracle for his support of The editor wishes to thank Greg Marsden of Oracle for his support of
this work, and Rob Thurlow of Oracle for review and suggestions. this work, and Rob Thurlow of Oracle for 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 Chair Spencer Shepler, and NFSV4 Working Group Working Group Chairs Spencer Shepler and Brian Pawlowski, and NFSV4
Secretary Thomas Haynes for their support. Working Group Secretary Thomas Haynes for their support.
Authors' Addresses Authors' Addresses
Charles Lever (editor) Charles Lever (editor)
Oracle Corporation Oracle Corporation
1015 Granger Avenue 1015 Granger Avenue
Ann Arbor, MI 48104 Ann Arbor, MI 48104
United States of America United States of America
Phone: +1 248 816 6463 Phone: +1 248 816 6463
 End of changes. 40 change blocks. 
104 lines changed or deleted 150 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/