draft-ietf-nfsv4-mv0-trunking-update-02.txt   draft-ietf-nfsv4-mv0-trunking-update-03.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: May 9, 2019 November 5, 2018 Expires: June 30, 2019 December 27, 2018
NFS version 4.0 Trunking Update NFS version 4.0 Trunking Update
draft-ietf-nfsv4-mv0-trunking-update-02 draft-ietf-nfsv4-mv0-trunking-update-03
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 May 9, 2019. This Internet-Draft will expire on June 30, 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 13 skipping to change at page 2, line 13
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 . . . . . . . . . . . . . . . . . . . . 6 4. Document Organization . . . . . . . . . . . . . . . . . . . . 5
5. Changes Within Section 8 of [RFC7530] . . . . . . . . . . . . 7 5. Changes Within Section 8 of [RFC7530] . . . . . . . . . . . . 6
5.1. Updated Section 8.1 of [RFC7530], entitled 5.1. Updated Section 8.1 of [RFC7530], entitled
"Location Attributes" . . . . . . . . . . . . . . . . . . 7 "Location Attributes" . . . . . . . . . . . . . . . . . . 7
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
skipping to change at page 2, line 36 skipping to change at page 2, line 36
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" . . . . . . . 11
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" . . . . . . . . . . . . . . . . . . 12
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" . . . . . . 14
6. Updates to [RFC7530] Outside Section Eight . . . . . . . . . 14 6. Updates to [RFC7530] Outside Section Eight . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1. Normative References . . . . . . . . . . . . . . . . . . 17 9.1. Normative References . . . . . . . . . . . . . . . . . . 17
9.2. Informative References . . . . . . . . . . . . . . . . . 17 9.2. Informative References . . . . . . . . . . . . . . . . . 18
Appendix A. Section Classification . . . . . . . . . . . . . . . 18 Appendix A. Section Classification . . . . . . . . . . . . . . . 18
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 18 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
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
skipping to change at page 4, line 8 skipping to change at page 4, line 8
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 Sections 5 and 6 below. updates to [RFC7530] as summarized in Sections 5 and 6 below.
2. Requirements Language 2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in BCP 14 [RFC2119] "OPTIONAL" in this document are to be interpreted as described in BCP
[RFC8174] when, and only when, they appear in all capitals, as shown 14 [RFC2119] [RFC8174] when, and only when, they appear in all
here. capitals, as shown here.
3. Terminology 3. 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.1 below. However, there are a few appropriately defined in Section 5.1 below. However, there are a few
terms used outside that context that are explained in this section. terms used outside that context that are explained in this section.
Trunking refers to a situation in which a client uses multiple Trunking refers to a situation in which a client uses multiple
network addresses communicate with the same server. Trunking was network addresses communicate with the same server. Trunking was
first introduced to NFSv4.0 by [RFC7931]. Regarding network first introduced to NFSv4.0 by [RFC7931]. Regarding network
skipping to change at page 4, line 45 skipping to change at page 4, line 45
top of RPC-over-RDMA, as described in [RFC8166]. The combination top of RPC-over-RDMA, as described in [RFC8166]. The combination
of a server network address and a particular connection type is of a server network address and a particular connection type is
referred to as a "server endpoint". referred to as a "server endpoint".
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. Unlike the case of NFSv4.1 (which introduced server-trunkable. Unlike subsequent NFSv4 minor versions, NFSv4.0
the concept of trunking to NFS version 4), NFSv4.0 only recgnizes recognizes only a single type of trunking relationship between
a single type of trunking relationship between addresses. NFSv4.1 addresses.
distinguishes two (see [RFC5661]). Despite this difference, two
addresses connected to the same NFSv4.0 server would normally be
connected to the same server if NFSv4.1 were used.
Particularly important is the distinction between trunking detection Particularly important is the distinction between trunking detection
and trunking discovery. The definitions we present are applicable to and trunking discovery. The definitions we present are applicable to
all minor versions of NFSv4, but we put particular emphasis on how all minor versions of NFSv4, but we put particular emphasis on how
these terms apply to NFS version 4.0. these terms apply to NFS version 4.0.
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
skipping to change at page 8, line 37 skipping to change at page 8, line 30
attribute. 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). 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. All such addresses MUST provide a way 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,
defined in [RFC7931], to confirm that such addresses are connected
to the same server. The client can ignore addresses found not to
be so connected.
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 host name is resolved by the client, 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
further discussed in Section 7.
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 11, line 28 skipping to change at page 11, line 28
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"
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 until the one preferred by the client is successfully types allowing it to determine which connection types are supported.
established.
If a client strongly prefers one connection type, it can perform
these attempts serially in order of declining preference. Once there
is a successful attempt, the established connection can be used.
Note that with this approach, network partitions can result in a
sequence of long waits for a successful connection.
To avoid waiting when there is at least one viable network path
available, simultaneous attempts to establish multiple connection
types are possible. Once a viable connection is established, the
client discards less-preferred connections.
5.2.4. Updated Section 8.4.1 of [RFC7530], entitled "File System 5.2.4. Updated Section 8.4.1 of [RFC7530], entitled "File System
Replication and Trunking" Replication and Trunking"
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 file system locations by interrogating the of the set of alternative file system locations by interrogating the
fs_locations attribute. Trunking discovery and/or detection can then fs_locations attribute. Trunking discovery and/or detection can then
be applied to the file system location entries to separate the be applied to the file system location entries to separate the
candidate server-trunkable addresses from the replica addresses that candidate server-trunkable addresses from the replica addresses that
provide alternative locations of the file system. Server-trunkable provide alternative locations of the file system. Server-trunkable
skipping to change at page 12, line 24 skipping to change at page 12, line 31
Section 5.2.6 of the current document for more detail. Section 5.2.6 of the current document for more detail.
Such migration can help provide load balancing or general resource Such migration can help provide load balancing or general resource
reallocation. The protocol does not specify how the file system will reallocation. The protocol does not specify how the file system will
be moved between servers. It is anticipated that a number of be moved between servers. It is anticipated that a number of
different server-to-server transfer mechanisms might be used, with different server-to-server transfer mechanisms might be used, with
the choice left to the server implementer. The NFSv4 protocol the choice left to the server implementer. The NFSv4 protocol
specifies the method used to communicate the migration event between specifies the method used to communicate the migration event between
client and server. client and server.
When an alternative file system location is designated as the target When the client receives indication of a migration event via an
for migration, it must designate the same data. Where file systems NFS4ERR_MOVED error, data propagation to the destination server must
are writable, a change made on the original file system must be have already occurred. Once the client proceeds to access the
visible on all migration targets. Where a file system is not alternate file system location, it must see the same data. Where
file systems are writable, a change made on the original file system
must be visible on all migration targets. Where a file system is not
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"
skipping to change at page 19, line 4 skipping to change at page 19, line 10
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 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.
Authors' Addresses Authors' Addresses
Charles Lever (editor) Charles Lever (editor)
Oracle Corporation Oracle Corporation
1015 Granger Avenue
Ann Arbor, MI 48104
United States of America United States of America
Phone: +1 248 816 6463
Email: chuck.lever@oracle.com Email: chuck.lever@oracle.com
David Noveck David Noveck
NetApp NetApp
1601 Trapelo Road
Waltham, MA 02451
United States of America United States of America
Phone: +1 781 572 8038
Email: davenoveck@gmail.com Email: davenoveck@gmail.com
 End of changes. 20 change blocks. 
32 lines changed or deleted 43 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/