draft-ietf-nfsv4-migration-issues-14.txt   draft-ietf-nfsv4-migration-issues-15.txt 
NFSv4 D. Noveck, Ed. NFSv4 D. Noveck, Ed.
Internet-Draft NetApp Internet-Draft NetApp
Intended status: Informational P. Shivam Intended status: Informational P. Shivam
Expires: May 20, 2018 C. Lever Expires: November 20, 2018 IBM
C. Lever
B. Baker B. Baker
ORACLE ORACLE
November 16, 2017 May 19, 2018
NFSv4 Migration and Trunking: Implementation and Specification Issues NFSv4 Migration and Trunking: Implementation and Specification Issues
draft-ietf-nfsv4-migration-issues-14 draft-ietf-nfsv4-migration-issues-15
Abstract Abstract
This document discusses a range of implementation and specification This document discusses a range of implementation and specification
issues concerning features related to the use of location-related issues concerning features related to the use of location-related
attributes in NFSv4. These include migration, which transfers attributes in NFSv4. These include migration, which transfers
responsibility for a file system from one server to another, and responsibility for a file system from one server to another, and
trunking which deals with the discovery and control of the set of trunking which deals with the discovery and control of the set of
network addresses to use to access a file system. The focus of the server endpoints to use to access a file system. The focus of the
discussion, which relates to multiple minor versions, is on defining discussion, which relates to multiple minor versions, is on defining
the appropriate clarifications and corrections for existing the appropriate clarifications and corrections for existing
specifications. specifications.
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 May 20, 2018. This Internet-Draft will expire on November 20, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 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
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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Language . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Language . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2.2. Use of Normative Terms . . . . . . . . . . . . . . . . . 4 2.2. Use of Normative Terms . . . . . . . . . . . . . . . . . 4
2.3. Terminology Used in this Document . . . . . . . . . . . . 5 2.3. Terminology Used in this Document . . . . . . . . . . . . 5
3. Multi-version Issues and Their Resolution . . . . . . . . . . 6 3. Issues that Apply to Multiple Versions and their Resolution . 7
3.1. Multi-Version Issues . . . . . . . . . . . . . . . . . . 6 3.1. Issue Summary . . . . . . . . . . . . . . . . . . . . . . 7
3.2. Resolution of Multi-Version Issues . . . . . . . . . . . 7 3.2. Resolution of Multi-Version Issues . . . . . . . . . . . 8
3.2.1. Providing Trunking Discovery . . . . . . . . . . . . 8 3.2.1. Providing Trunking Discovery . . . . . . . . . . . . 9
3.2.2. Interaction of Trunking and Migration . . . . . . . . 9 3.2.2. Interaction of Trunking and Migration . . . . . . . . 10
4. NFSv4.0 Issues . . . . . . . . . . . . . . . . . . . . . . . 11 3.2.3. Dealing with Multiple Connection Types . . . . . . . 12
4.1. Core NFSv4.0 Migration Issues . . . . . . . . . . . . . . 11 4. NFSv4.0 Issues . . . . . . . . . . . . . . . . . . . . . . . 13
4.1. Core NFSv4.0 Migration Issues . . . . . . . . . . . . . . 13
4.2. Resolution of Core Migration Protocol Difficulties in 4.2. Resolution of Core Migration Protocol Difficulties in
NFSv4.0 . . . . . . . . . . . . . . . . . . . . . . . . . 12 NFSv4.0 . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.3. Additional NFSv4.0 Issues . . . . . . . . . . . . . . . . 12 4.3. Additional NFSv4.0 Issues . . . . . . . . . . . . . . . . 15
4.4. Resolution of Additional NFSv4.0 Issues . . . . . . . . . 13 4.4. Resolution of Additional NFSv4.0 Issues . . . . . . . . . 15
5. Issues for NFSv4.1 . . . . . . . . . . . . . . . . . . . . . 14 4.4.1. Resolution of NFSv4.0 Issues with Multiple Connection
5.1. Issues to Address for NFSv4.1 . . . . . . . . . . . . . . 14 Types . . . . . . . . . . . . . . . . . . . . . . . . 17
5.1.1. Addressing State Merger in NFSv4.1 . . . . . . . . . 15 5. Issues for NFSv4.1 and Beyond . . . . . . . . . . . . . . . . 18
5.1.2. Addressing pNFS Relationship with Migration . . . . . 15 5.1. Issues to Address for NFSv4.1 . . . . . . . . . . . . . . 18
5.1.3. Addressing Server_owner Changes in NFSv4.1 . . . . . 16 5.1.1. Addressing State Merger in NFSv4.1 . . . . . . . . . 19
5.1.2. Addressing pNFS Relationship with Migration . . . . . 20
5.1.3. Addressing Server_owner Changes in NFSv4.1 . . . . . 20
5.1.4. Addressing Confirmation Status of Migrated 5.1.4. Addressing Confirmation Status of Migrated
Client IDs in NFSv4.1 . . . . . . . . . . . . . . . . 17 Client IDs in NFSv4.1 . . . . . . . . . . . . . . . . 21
5.1.5. Addressing Changes in Trunking Configuration . . . . 18 5.1.5. Addressing Changes in Trunking Configuration . . . . 23
5.1.6. Addressing Session Migration in NFSv4.1 . . . . . . . 19 5.1.6. Addressing Session Migration in NFSv4.1 . . . . . . . 23
5.2. Possible Resolutions for NFSv4.1 Protocol Issues . . . . 19 5.1.7. Dealing with Multiple Connection Types in NFSv4.1 . . 23
5.2.1. Client ID Confirmation Issues . . . . . . . . . . . . 19 5.2. Possible Resolutions for NFSv4.1 Protocol Issues . . . . 24
5.2.2. Dealing with Multiple Location Entries . . . . . . . 20 5.2.1. Client ID Confirmation Issues . . . . . . . . . . . . 25
5.2.3. Migration and pNFS . . . . . . . . . . . . . . . . . 23 5.2.2. Dealing with Multiple Location Entries . . . . . . . 26
5.3. Defining Server Responsibilities for NFSv4.1 . . . . . . 24 5.2.3. Migration and pNFS . . . . . . . . . . . . . . . . . 28
5.3. Defining Server Responsibilities for NFSv4.1 . . . . . . 29
5.3.1. Server Responsibilities in Effecting Transparent 5.3.1. Server Responsibilities in Effecting Transparent
State Migration . . . . . . . . . . . . . . . . . . . 24 State Migration . . . . . . . . . . . . . . . . . . . 29
5.3.2. Synchronizing Session Transfer . . . . . . . . . . . 25
5.4. Defining Client Responsibilities for NFSv4.1 . . . . . . 28 5.3.2. Synchronizing Session Transfer . . . . . . . . . . . 30
5.4.1. Client Recovery from Migration Events . . . . . . . . 28 5.4. Defining Client Responsibilities for NFSv4.1 . . . . . . 33
5.4.2. The Migration Discovery Process . . . . . . . . . . . 30 5.4.1. Client Recovery from Migration Events . . . . . . . . 33
5.4.3. Overview of Client Response to NFS4ERR_MOVED . . . . 31 5.4.2. The Migration Discovery Process . . . . . . . . . . . 35
5.4.3. Overview of Client Response to NFS4ERR_MOVED . . . . 37
5.4.4. Obtaining Access to Sessions and State after 5.4.4. Obtaining Access to Sessions and State after
Migration . . . . . . . . . . . . . . . . . . . . . . 33 Migration . . . . . . . . . . . . . . . . . . . . . . 39
5.4.5. Obtaining Access to Sessions and State after Network 5.4.5. Obtaining Access to Sessions and State after Network
Address Transfer . . . . . . . . . . . . . . . . . . 35 Address Transfer . . . . . . . . . . . . . . . . . . 40
5.5. Resolution of NFSv4.1 Issues . . . . . . . . . . . . . . 35 5.5. Resolution of NFSv4.1 Issues . . . . . . . . . . . . . . 41
6. Evolution of Issue Handling . . . . . . . . . . . . . . . . . 38 5.6. Potential Protocol Extensions . . . . . . . . . . . . . . 43
6.1. History of this Document . . . . . . . . . . . . . . . . 38 6. Evolution of Issue Handling . . . . . . . . . . . . . . . . . 44
6.2. Further Work Needed . . . . . . . . . . . . . . . . . . . 39 6.1. History of this Document . . . . . . . . . . . . . . . . 44
7. Security Considerations . . . . . . . . . . . . . . . . . . . 42 6.2. Further Work Needed . . . . . . . . . . . . . . . . . . . 46
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 7. Security Considerations . . . . . . . . . . . . . . . . . . . 49
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 43 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50
9.1. Normative References . . . . . . . . . . . . . . . . . . 43 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 50
9.2. Informative References . . . . . . . . . . . . . . . . . 44 9.1. Normative References . . . . . . . . . . . . . . . . . . 50
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 44 9.2. Informative References . . . . . . . . . . . . . . . . . 51
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 52
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52
1. Introduction 1. Introduction
This is an informational document that discusses a number of related This is an informational document that discusses a number of related
issues in multiple versions of NFSv4. issues in multiple versions of NFSv4.
Many of these relate to the migration feature of NFSv4, which Many of these relate to the migration feature of NFSv4, which
provides for moving responsibility for a single filesystem from one provides for moving responsibility for a single filesystem from one
server to another, without disruption to clients. A number of server to another, without disruption to clients. A number of
problems in the specification of this feature in NFSv4.0 were problems in the specification of this feature in NFSv4.0 were
skipping to change at page 5, line 14 skipping to change at page 5, line 20
2.3. Terminology Used in this Document 2.3. Terminology Used in this Document
In this document the phrase "client ID" always refers to the 64-bit In this document the phrase "client ID" always refers to the 64-bit
shorthand identifier assigned by the server (a clientid4) and never shorthand identifier assigned by the server (a clientid4) and never
to the structure which the client uses to identify itself to the to the structure which the client uses to identify itself to the
server (called an nfs_client_id4 or client_owner in NFSv4.0 and server (called an nfs_client_id4 or client_owner in NFSv4.0 and
NFSv4.1 respectively). The opaque identifier within those structures NFSv4.1 respectively). The opaque identifier within those structures
is referred to as a client id string". is referred to as a client id string".
Regarding trunking of network addresses, we use the following Regarding the discussion of potential network endpoints, we use the
terminology: following terminology:
o The phrase "connection type" denotes the use of an existing or
potential connection to support NFSv4 layered on top of the RPC
stream transport as described in [RFC5531] or on top of RPC-over-
RDMA as described in [RFC8166]. Establishing a connection of a
particular type requires that the client and server support that
connection type given the particular client and server network
addresses used.
o Each connection is established between a client and a specfic
server endpoint. Two endpoints are considered distinct if they
differ in either network address or connection type. Multiple
connections may be established to the same endpoint or to
different endpoints.
o The phrase "network endpoint specification" refers to the
combination of a network address and a connection type.
Regarding trunking of connections to server network endpoints, we use
the following terminology:
o Trunking detection refers to ways of deciding whether two specific o Trunking detection refers to ways of deciding whether two specific
network addresses are connected to the same NFSv4 server. The network endpoints are connected to the same NFSv4 server. The
means available to make this determination depends on the protocol means available to make this determination depends on the protocol
version, and, in some cases, on the client implementation. version, and, in some cases, on the client implementation.
o Two network addresses connected to the same server are said to be o Two network endpoints connected to the same server are said to be
server-trunkable. server-trunkable.
o Two network addresses connected to the same server such that those o Two network endpoints connected to the same server such that
addresses can be used to support a single common session are connections to those endpoints can be used to support a single
referred to as session-trunkable. Note NFSv4.1 allows two common session are referred to as session-trunkable. Note NFSv4.1
addresses to be server-trunkable without being session-trunkable, allows two endpoints to be server-trunkable without being session-
while in NFSv4.0 no addresses are session-trunkable, since there trunkable, while in NFSv4.0 no addresses are session-trunkable,
are no sessions. since there are no sessions.
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 addresses that are trunkable network endpoint can obtain the network addresses for endpoints
(either server-trunkable or session-trunkable) with it. that are trunkable (either server-trunkable or session-trunkable)
with it.
Regarding terminology relating to attributes used in trunking Regarding terminology relating to attributes used in trunking
discovery and other multi-server namespace features: discovery and other multi-server namespace features:
o Location attributes include the fs_locations and fs_locations_info o Location attributes include the fs_locations and fs_locations_info
attributes. attributes.
o Location entries are the individual file system locations in the o Location entries are the individual file system locations in the
location attributes. location attributes.
skipping to change at page 6, line 24 skipping to change at page 7, line 5
Each set of server-trunkable location elements defines the available Each set of server-trunkable location elements defines the available
access paths to a particular file system. When there are multiple access paths to a particular file system. When there are multiple
such file systems, each of these, which contains the same data, is a such file systems, each of these, which contains the same data, is a
replica of the others. Logically, such replication is symmetric, replica of the others. Logically, such replication is symmetric,
since the fs currently in use and an alternate fs are replicas of since the fs currently in use and an alternate fs are replicas of
each other. Often, in other documents, the term "replica" is not each other. Often, in other documents, the term "replica" is not
applied to the fs currently in use, despite the fact that the applied to the fs currently in use, despite the fact that the
replication relation is inherently symmetric. replication relation is inherently symmetric.
3. Multi-version Issues and Their Resolution 3. Issues that Apply to Multiple Versions and their Resolution
3.1. Multi-Version Issues Although there are a common set of issues that need to be addressed,
the diffences between NFSv4.0 and NFSv4.1 means that the detailed
handling of these issues will be significantly different in each
prototol.
The source of these issues rises from a lack of clarity regarding the In order to accommodate this situation, this section will deal with
the commonalities across protocol version while the specfics
appropriate to each protocol version are dealt with in Sections 4 and
5 respectively.
3.1. Issue Summary
Many of these issues arise from a lack of clarity regarding the
meaning of and proper handling for location attributes that specify meaning of and proper handling for location attributes that specify
more than a single server address. Such situations can arise as a more than a single server address. Such situations can arise as a
result of multiple entries in the same attribute or because a single result of multiple entries in the same attribute or because a single
entry has a server name which, when processed by DNS, is mapped to entry has a server name which, when processed by DNS, is mapped to
multiple server addresses. multiple server addresses.
Another set of issues arises from the fact that many of the
facilities thst must deal with multiple network addresses assume
there is only a single connection type shared by all of the
addresses. It is necessary to deal with a mixture of connection
types.
Both [RFC7530] and [RFC5661] indicate that multiple addresses may be Both [RFC7530] and [RFC5661] indicate that multiple addresses may be
present and that these addresses may be different paths to the same present and that these addresses may be different paths to the same
server as well as different copies of the same data. However, the server as well as different copies of the same data. However, the
following issues have, for both protocols, interfered with the following issues have, for both protocols, interfered with the
recognition of the existing location attributes as a way of providing recognition of the existing location attributes as a way of providing
a trunking discovery function: a trunking discovery function:
o There is no discussion of the use of these attributes when a file o There is no discussion of the use of these attributes when a file
system is first accessed, giving the impression that they are only system is first accessed, giving the impression that they are only
to be used as a way of overcoming access difficulties. to be used as a way of overcoming access difficulties.
o The treatment of migration (and in the case of NFSv4.1 of file o The treatment of migration (and in the case of NFSv4.1 of file
system transitions in general) is written as if only a single system transitions in general) is written as if only a single
server address will be accessed. server address will be accessed.
o Although location attributes can contain the addresses of o Although location attributes can contain the addresses of
migration targets and of additional replicas as well, the issues migration targets and of additional replicas as well, the issues
that arise when both of these are specified are not clearly that arise when both of these are specified are not clearly
discussed. discussed.
In addition, there are factors that relates to specific protocol In addition, there are factors regarding trunking that relate to
versions and documents: specific protocol versions and documents:
o In NFSv4.0, as described solely by [RFC7530], trunking is treated o In NFSv4.0, as described solely by [RFC7530], trunking is treated
as a problem to be avoided, making the whole matter moot. as a problem to be avoided, making the whole matter moot.
o In NFSv4.0, as described by [RFC7530] together with [RFC7931], the o In NFSv4.0, as described by [RFC7530] together with [RFC7931], the
situation is different. There is a means of trunking detection situation is different. There is a means of trunking detection
suggested in [RFC7931] but it is a suggestion only valid when the suggested in [RFC7931] but it is a suggestion only valid when the
client chooses to use the uniform client id string model. client chooses to use the uniform client id string model.
o For NFSv4.1, as described by [RFC5661], there is a standard method o For NFSv4.1, as described by [RFC5661], there is a standard method
of trunking detection, which can be relied upon. of trunking detection, which can be relied upon.
The issues that need to be resolved for both versions are: The issues that need to be addressed for both versions are:
o Provision of a trunking discovery facility to allow a client to o Provision of a trunking discovery facility to allow a client to
find out about other addresses that may be used to access the find out about other addresses that may be used to access the
current server. current server.
o Discussion of how the appropriate connection type for a given
client-server connection is to be arrived at and of trunking
issues between endpoints of multiple connection types using the
same network address.
o Better integration of migration with trunking changes, including o Better integration of migration with trunking changes, including
situations in which the set of addresses to access the same server situations in which the set of endpoints usable to access the same
changes (without migration) and those in which there is a shift to server changes (without migration) and those in which there is a
a different server, but trunking of addresses on either the source shift to a different server, but trunking of endpoints on either
or destination is involved the source or destination is involved
Note that although these issues need to be addressed for both
protocols, the resolutiions need not be the same and the protocol
facilities within each protocol may limit the completeness of the
resolutions provided.
3.2. Resolution of Multi-Version Issues 3.2. Resolution of Multi-Version Issues
Although the specifics of addressing these issues will be different Although the specifics of addressing these issues will be different
for different versions, there are some common aspects discussed in for different versions, there are some common aspects discussed in
the subsections below: the subsections below:
o The trunking discovery function, except for the additional o The trunking discovery function is to be addressed in
location attribute fs_locations_info, is to be addressed in
substantially the same way in both versions, as explained in substantially the same way in both versions, as explained in
Section 3.2.1. Section 3.2.1. The only version-related differences are the
inclusion of the fs_locations_info attribute in NFSv4.1 and the
potential addition of further per-endpoint information within
extensions to be defined for use in later versions of NFSv4.
o The interaction of trunking and migration is discussed in general o The interaction of trunking and migration is discussed in general
terms in Section 3.2.2. However, the specifics of the NFSv4.1 terms in Section 3.2.2. However, the specifics of the NFSv4.1
client's response to NFS4ERR_MOVED are discussed in Sections client's response to NFS4ERR_MOVED are discussed in Sections
5.4.3, 5.4.4, and 5.4.5. 5.4.3, 5.4.4, and 5.4.5.
3.2.1. Providing Trunking Discovery 3.2.1. Providing Trunking Discovery
A client can discover a set network addresses to use to access a file A client can discover a set network addresses to use to access a file
system using an NFSv4 server in a number of ways: system using an NFSv4 server in a number of ways:
skipping to change at page 8, line 50 skipping to change at page 10, line 7
With regard to security, the possibility that requests to determine With regard to security, the possibility that requests to determine
the set of network addresses corresponding to a given server might be the set of network addresses corresponding to a given server might be
interfered with or have their responses corrupted needs to be taken interfered with or have their responses corrupted needs to be taken
account of. As a result, when use of DNSSEC is not available, it account of. As a result, when use of DNSSEC is not available, it
might not be advisable to present server names in location attributes might not be advisable to present server names in location attributes
and present the network addresses directly, eliminating the need to and present the network addresses directly, eliminating the need to
use DNS to effect this translation. Fetching of location attributes use DNS to effect this translation. Fetching of location attributes
should be done with integrity protection. should be done with integrity protection.
In some situations, the server will want to direct clients to use In many cases, the server will provide all the network addresses to
specific sets of network addresses, to effect load balancing, or to be used to access a given server, allowing the client to select the
meet quality-of-service goals. In such environments, presentation of address or set of addresses most suited to its purposes. However, in
network addresses directly in the location attribute can help give some situations, the server will want to direct clients to use
the server the necessary control over the paths to be used when specific sets of network addresses to effect load balancing, to meet
accessing particular file systems. When such techniques are used, quality-of-service goals, or to optimize use of clustered servers by
servers typically present their own network addresses in the location directing traffic to the cluster element most able to handle it
attribute while adding the names of other servers, such as those used efficiently. In such environments, presentation of network addresses
to access replicas. directly in the location attribute can help give the server the
necessary control over the paths to be used when accessing particular
file systems. When such techniques are used, servers typically
present their own network addresses in the location attribute while
adding the names of other servers, such as those used to access
replicas.
Trunking detection allows the client to determine whether two network Trunking detection allows the client to determine whether two network
addresses can be used to access the same server. The availability of addresses can be used to access the same server. The availability of
trunking detection depends on the protocol version, and, in some trunking detection depends on the protocol version, and, in some
case, on client implementation choices: case, on client implementation choices:
o For NFSv4.0, a means by which it can be determined if two network o For NFSv4.0, a means by which it can be determined if two network
addresses correspond to the same server is suggested in [RFC7931]. addresses correspond to the same server is suggested in [RFC7931].
However is it is optional and only available to clients using the However is it is optional and only available to clients using the
uniform client id string approach. uniform client id string approach.
skipping to change at page 11, line 15 skipping to change at page 12, line 26
addresses usable with the current server or a migration target addresses usable with the current server or a migration target
before those associated with replicas. before those associated with replicas.
o A client can cease scanning for trunkable location entries once it o A client can cease scanning for trunkable location entries once it
encounters one whose fs_name differs from the current fs name. encounters one whose fs_name differs from the current fs name.
o A client can cease scanning for trunkable location entries once it o A client can cease scanning for trunkable location entries once it
encounters a location element whose address in not server- encounters a location element whose address in not server-
trunkable with the one it is using. trunkable with the one it is using.
3.2.3. Dealing with Multiple Connection Types
Because of the use of RPC-over-RDMA [RFC8166] as an inderlying
transport for NFSV4, as described in [RFC8267], a client may have
mutiple connection types to the same server network address. This
gives rise to a number of issues with regard to NFSv4 multi-server
namespace features.
o In the case of migration or referral, the client is directed to
one or more server network addresses and faces the problem of
selecting the appropriate connection type.
o When trunking multiple connections, the client might be directed
to use the same server network address with a different set of of
potential connection types leaving the client to choose the
connection type to be used when a set with multiple connection
types is provided.
Although the situation is similar for both protocol versions,
differences in the attributes supported may result in important
differences in how connection types are selected.
o In the case of NFSv4.0, the fs_locations attribute has no ability
to indicate valid connection types. Only the network address is
provided, either directly in the location entry or as a result of
a server name being mapped to a set of network addresses. As a
result, the client may have to attempt connection with multiple
connection types, making its own selection of the subset to be
used when more than one connection type is available.
o NFSv4.1 has some facilities to aid in the selection of connection
types. The entries within the fs_locations_info attribute may
indicate the availability of RDMA connection support using the
FSLI4TF_RDMA flag. In addition, for RDMA implementation which
allow conversion (i.e. step-up) between non-RDMA and RDMA modes
within the scope of a single connection, the
CREATE_SESSION4_FLAG_CONN_RDMA flag may be used as part of
detecting whether RDMA support is present. When that flag is not
present, step-up is not supported, but the client may use the
FSLI4TF_RDMA flag to determine if RDMA support is available, and
establish a new connection to use to obtain RDMA support.
In addition to the selection of an appropriate connection type to use
when multiple connection types are available, the simultaneous
availability of multiple connection types raises issues related to
trunking, in the same way as the availability of multiple network
addresses connected to the same server. These issues, including the
relationship of such trunking to migration might be dealt with could
potentially be dealt sdifferently within NFSv4.0 and NFSv4.1,
although similar treatment is desirabble. The treatment of these
issues is discused in Sections 4.4.1 and 5.1.7 respectively.
Note that the handling of trunking for NFSv4.0 and for an NFSv4.1
metadata server differs from that for an NFSv4.1 data server. In
that latter case, specification of trunking patterns including the
connection type of endpoints is under the control of the metadata
server and the client simply uses the information presented by the
metadata server to guide selection of the endpoints to be accessed.
One potential difference between the versions that needs to be
resolved concerns the issue of the trunking of multiple connections
directed to endpoints that share a network address while differing as
to connection type. While NFSv4.1 is specified in [RFC5661] as
requring that such connections be trunkable, neither [RFC7530] nor
[RFC7931] contains a corresponding statement.
4. NFSv4.0 Issues 4. NFSv4.0 Issues
4.1. Core NFSv4.0 Migration Issues 4.1. Core NFSv4.0 Migration Issues
Many of the problems seen with Transparent State Migration derived Many of the problems seen with Transparent State Migration derived
from the inability of NFSv4.0servers to determine whether two client from the inability of NFSv4.0servers to determine whether two client
IDs, issued on different servers, corresponded to the same client. IDs, issued on different servers, corresponded to the same client.
This difficulty derived in turn from the common practice, recommended This difficulty derived in turn from the common practice, recommended
by [RFC7530], in which each client presented different client by [RFC7530], in which each client presented different client
identification strings to different servers, rather than presenting identification strings to different servers, rather than presenting
skipping to change at page 12, line 52 skipping to change at page 15, line 32
NFSv4.0 known at that time. NFSv4.0 known at that time.
4.3. Additional NFSv4.0 Issues 4.3. Additional NFSv4.0 Issues
In light of the fact that a large set of migration-specific issues In light of the fact that a large set of migration-specific issues
were addressed by the publication of [RFC7931], the remaining issues were addressed by the publication of [RFC7931], the remaining issues
derive from those mentioned in Section 3.1. These include: derive from those mentioned in Section 3.1. These include:
o Introducing facilities for trunking discovery. o Introducing facilities for trunking discovery.
o Clarifying the relationship between migration and trunking. o Clarifying the handling of multiple connection types, including
issues related to the trunking of multiple connections of
different types to the same network address.
o Clarifying the relationship between migration and trunking,
including trunking among multple server endpoints sharing a server
network address.
4.4. Resolution of Additional NFSv4.0 Issues 4.4. Resolution of Additional NFSv4.0 Issues
One possible approach to addressing these issues would entail One possible approach to addressing these issues would entail
publication of an additional standards-track document updating publication of an additional standards-track document updating
[RFC7530]. [RFC7530].
Fortunately, it appears that all of the material to be updated Fortunately, it appears that all of the material to be updated
appears in Section 8 of that document, whether it concerns the appears in Section 8 of that document, whether it concerns the
provision of trunking discovery or the interaction of trunking and provision of trunking discovery or the interaction of trunking and
skipping to change at page 13, line 42 skipping to change at page 16, line 30
If a single location entry designates multiple server IP If a single location entry designates multiple server IP
addresses, the client should choose a single one to use. When addresses, the client should choose a single one to use. When
two server addresses are designated by a single location entry two server addresses are designated by a single location entry
and they correspond to different servers, this normally and they correspond to different servers, this normally
indicates some sort of misconfiguration, and so the client indicates some sort of misconfiguration, and so the client
should avoid using such location entries when alternatives are should avoid using such location entries when alternatives are
available. When they are not, clients should pick one of the available. When they are not, clients should pick one of the
IP addresses and use it, without using others that are not IP addresses and use it, without using others that are not
directed to the same server. directed to the same server.
As written, this seems to foreclose any use of trunking in In addition, no part of the existing Section 8, mentions the
possibility of multiple connection types, which completes the
exclusion of the possibility of multiple trunked server
endpoints from the existing description of NFSv4.0.
As written, this section seems to foreclose any use of trunking in
connection with migration. In retrospect, it appears that this connection with migration. In retrospect, it appears that this
section should have been revised as part of [RFC7931], but since section should have been revised as part of [RFC7931], but since
that was not done then, the issue needs to be addressed now. that was not done then, the issue needs to be addressed now.
Overall, it appears that, in addition to the revision of Section 8.1, Overall, it appears that, in addition to the revision of Sections 8.1
Sections 8.4 and 8.5 need to be reorganized. One likely approach is and 8.5, Section 8.4 need to be reorganized. One possible approach
to divide the material into three main sections based on the is to divide the material into sub-sections as follows:
circumstances in which the attribute is accessed:
A section dealing with initial use and how it is trunking o A replacement introductory subsection describing all the uses of
discovery and preparation for replication. location information.
A section dealing with subsequent attribute change and how it o A new subsection describing trunking discovery and detection,
affects trunking discovery and preparation for replication. based on use of the existing entries within the fs_locations
attribute.
A section dealing with how the attribute is used to deal with o A new subsection describing the handling of multiple connection
communication problems including receiving NFS4ERR_MOVED but also types. For a discussion of issues to be addressed, see
including other communication difficulties driving selection of a Section 4.4.1.
new replica.
5. Issues for NFSv4.1 o A replacement subsection dealing with replication and trunking.
o A replacement subsection dealing with migration.
o A new subsection dealing with the interaction of trunking,
replication, and migration.
4.4.1. Resolution of NFSv4.0 Issues with Multiple Connection Types
The existence of multiple connection types raises issues regarding
how the connection type to be used is determied by the client. Such
issues need to be addressed when a new server is accessed and also
when NFS4ERR_MOVED is returned and a server endpoint is to be
selected to access the current file system.
The absence of explicit support for multiple connection types within
NFSv4.0 means that the client has a great deal of freedom in making
this determination, although some implementation guidance could be
provided. A client could attempt to establish a connection of each
connection type and the connection type (or types) that it chooses.
To make this an efficient process, servers which do not provide
support for a particular connection type should promptly indicate
that non-support. It should be the case that all server endpoints
sharing a particular network address are to be considered trunkable,,
even though currently neither [RFC7530] nor [RFC7931] explicitly
states that.
The approach mentioned above should, in general, be usable in the
cases of migration and referral, as well as for initial mount.
Clients might well treat these situations differently, for example by
using the type of the current connection as the initial type to try
in the migration case, while not doing in other cases.
Situations in which NFS4ERR_MOVED is returned without requiring any
shift in target network address require special attention, in order
to allow a shift in the network endpoint to be used to be indicated
even if there is no corresponding shift in network address. In the
absence of multiple connection types, receiving NFS4ERR_MOVED when
acessing one file system serves as an indication that that address is
not to be used to access that file system subsequently, making it
necessary to use other network addresses to access the file system,
after migration or a shift in trunking patterns without migration.
Since NFSv4.0 does not provide any way for the server to specify the
use of particular connection types, it might seem that there is no
way for the server to direct such a shift. However, when
NFS4ERR_MOVED is returned and the network address on which it was
returned is still present in the location entries returned, a client
may reasonably conclude that:
o The endpoint from whic NFS4ERR_MOVED was returned is not to be
used to acess the file system in question.
o Other endpoints using the same network address but different
connection types could be used to access the filesystem.
This gives the client a set of server endpoints to test for access to
the filsystem. In cases in which there is already a connection
established to that endpoint, file system access can be tested using
a PUTFH within the target file system followed by a GETFH, which will
either succeed or return NFS4ERR_MOVED depending on whether the
endpoint used can validly access the file system. In other cases a
connection will need to be established before such a test can be
performed.
5. Issues for NFSv4.1 and Beyond
5.1. Issues to Address for NFSv4.1 5.1. Issues to Address for NFSv4.1
Because NFSv4.1 embraces the uniform client-string approach, as Because NFSv4.1 embraces the uniform client-string approach, as
advised by section 2.4 of [RFC5661], addressing migration issues is advised by section 2.4 of [RFC5661], addressing migration issues is
simpler, in that a shift in client id string models is not required. simpler, in that a shift in client id string models is not required.
Instead, NFSv4 returns information in the EXCHANGE_ID response to Instead, NFSv4 returns information in the EXCHANGE_ID response to
enable trunking relationships to be determined by the client. enable trunking relationships to be determined by the client.
Despite this simplification, there are substantial issues that need Despite this simplification, there are substantial issues that need
skipping to change at page 19, line 26 skipping to change at page 23, line 38
o Rules need to be clarified regarding possible transfer of sessions o Rules need to be clarified regarding possible transfer of sessions
when either the source session is being used to access other file when either the source session is being used to access other file
systems on source server or there is already a session connecting systems on source server or there is already a session connecting
the client to the destination server. the client to the destination server.
o There needs to be more detail regarding how the protocol avoids o There needs to be more detail regarding how the protocol avoids
situations in which the same session is subject to concurrent situations in which the same session is subject to concurrent
changes on two different servers at the same time. changes on two different servers at the same time.
5.1.7. Dealing with Multiple Connection Types in NFSv4.1
The existence of multiple connection types raises issues regarding
how the connection type to be used is determied by the client. Such
issues need to be addressed when a new server is accessed and also
when NFS4ERR_MOVED is returned and a server endpoint is to be
selected to access the current file system.
The limited support for multiple connection types within NFSv4.1
means that a client can make this determination by first establishing
a non-RDMA connection and then using the the FSLI4TF_RDMA flag in the
fs_locations_info attribute for the root file system to determine if
an RDMA conection should be established. Such a connection can then,
at the client's option, replace or remain truked with the original
connection. As an alternative, where support is provided, the xxxx
flag returned by EXCHANGE_ID can be used to guide a trnsfer of the
existing connection to RDMA mode.
The approach mentioned above should, in general, be usable in the
cases of migration and referral, as well as for initial mount.
Situations in which NFS4ERR_MOVED is returned without requiring any
shift in target network address require special attention, in order
to allow a shift in the network endpoint to be used to be indicated
even if there is no corresponding shift in network address. In the
absence of multiple connection types, receiving NFS4ERR_MOVED when
acessing one file system serves as an indication that that address is
not to be used to access that file system subsequently, making it
necessary to use other network addresses to access the file system,
after migration or a shift in trunking patterns without migration.
Since NFSv4.1 only limited facilities for the server to specify the
use of particular connection types, there are difficulties in
directing such a shift. When NFS4ERR_MOVED is returned and the
network address on which it was returned is still present in the
location entries returned, a client may reasonably conclude that:
o The usability of the aassociated RDMA endpoint can be determined
based on the status of the the FSLI4TF_RDMA in the
fs_locations_info attribute for the file system being accessed.
o The endpoint returning NFS4ERR_MOVED is not to be used to acess
the file system in question.
o Other endpoints using the same network address but different
connection types could be used to access the filesystem.
This generally allows client to determine set of server endpoints to
be used to access the filsystem. In cases in which there is some
ambiguity file system access can be tested by establishing a
connection if not already present and then using a PUTFH within the
target file system followed by a GETFH, which will either succeed or
return NFS4ERR_MOVED depending on whether the endpoint used can
validly access the file system.
5.2. Possible Resolutions for NFSv4.1 Protocol Issues 5.2. Possible Resolutions for NFSv4.1 Protocol Issues
The subsections below explore some ways of dealing with clarifying The subsections below explore some ways of dealing with clarifying
the protocol to address issues discussed in Section 5.1 the protocol to address issues discussed in Section 5.1
5.2.1. Client ID Confirmation Issues 5.2.1. Client ID Confirmation Issues
As mentioned previously [RFC5661], makes no provision for client IDs As mentioned previously [RFC5661], makes no provision for client IDs
that are confirmed other than through the use of CREATE_SESSION. For that are confirmed other than through the use of CREATE_SESSION. For
example Section 18.35 of [RFC5661] states: example Section 18.35 of [RFC5661] states:
skipping to change at page 38, line 19 skipping to change at page 43, line 41
"Transparent State Migration" is well established in the context "Transparent State Migration" is well established in the context
of NFSv4.0, the word "transparent" could cause confusion given the of NFSv4.0, the word "transparent" could cause confusion given the
existing use of the phrase "transparent transitions". A possible existing use of the phrase "transparent transitions". A possible
title for the new section is "State Transfer during Migration" title for the new section is "State Transfer during Migration"
The new section would present the NFSv4.1-equivalent of Transparent The new section would present the NFSv4.1-equivalent of Transparent
State Migration as described in [RFC7931]. This would address the State Migration as described in [RFC7931]. This would address the
issues presented in Section 5.1 along the lines suggested in Sections issues presented in Section 5.1 along the lines suggested in Sections
5.2, 5.3, and 5.4. 5.2, 5.3, and 5.4.
5.6. Potential Protocol Extensions
There are a number possibilities to provides additional facilities
related to issues discussed in this document using the protocol
extension mechanisms described in [RFC8178]. These facilities relate
to the handling of multiple connection types.
The possibility of additional connection types was not addressed in
NFSv4.0, either in [RFC3530] or [RFC7530]. While the use of mutiple
connection types is allowed, facilities to determine the connection
type to be used are sub-optimal and are expected to remain so.
In the case of NFSv4.1, there are facilities to aid in the
determination of connection types that can be used. However, such
facilities are limited to the two connection types already defined
and may have weaknesses in dealing with changes in the set of
connection types to be used and in selecting connections to be used,
particularly in clustered server environments, in which the set of
potential trunked server endpoints can be large.
In light of this situation, it appears that a number of potential
extensions to NFSv4 might be considered, as provided for by
[RFC8178]. Such extensions could take the form of additional
OPTIONAL attributes. While these attributes would be part of
NFSv4.2, the fact that there is no change in the set of REQUIRED
features between NFSv4.1 and NFSv4.2 means that the upgrade path for
clients and servers can be made relatively simple.
The additonal attributes sketched out below would provide a more
complete way of addressing the possibility of trunking of a large set
of server endpoints, of multiple connection types:
o A new fs-scoped attribute, fs_location_endpoints, could provide
potential locations of a file system by using location entries
specifying each potential endpoint, rather than specifing, as do
fs_locations and fs_locations_info, the nework address applicable
to all potenia endpoints.
o A new server-scoped attribute, server_endpoints, could provide a
set of trunkable endpoints to be used to access the current
server, together with additional performance-related information
useful for endpoint selection.
A fuller elaboration of these proposals would require the writing of
one or more standards-track documents, assuming sufficient interest
in proceeding along this route. Any such work would be separate from
other work suggested to resolve existing protocol issues and will not
be mentioned in Section 6.2
6. Evolution of Issue Handling 6. Evolution of Issue Handling
6.1. History of this Document 6.1. History of this Document
The contents of successive versions of this document have changed The contents of successive versions of this document have changed
because new issues have been discovered, because there have been because new issues have been discovered, because there have been
changes in our understanding of how these features should interact, changes in our understanding of how these features should interact,
and because some of the issues have been adequately addressed with and because some of the issues have been adequately addressed with
regard to certain protocol versions. regard to certain protocol versions.
skipping to change at page 40, line 7 skipping to change at page 46, line 30
6.2. Further Work Needed 6.2. Further Work Needed
The following table classifies issues in this area and indicates The following table classifies issues in this area and indicates
which are currently adequately addressed and where the protocol which are currently adequately addressed and where the protocol
specifications need further correction or clarification. Where the specifications need further correction or clarification. Where the
topic is adequately addressed, a reference is given to the RFC topic is adequately addressed, a reference is given to the RFC
providing support for the issue. In other cases, an area name providing support for the issue. In other cases, an area name
(explained below) is given. (explained below) is given.
+---------+-----------+-----------+---------------+-----------------+ +-------+-----------+----------+-----------+----------+-------------+
| Version | Trunking | Trunking | Transparent | Interaction of | | Vers. | Trunking | Trunking | Xparent | Multiple | Interaction |
| | Detection | Discovery | State | Trunking and | | | Detection | Disc. | State | Conn. | of Trunking |
| | | | Migration | Migration | | | | | Migration | Types | and |
+---------+-----------+-----------+---------------+-----------------+ | | | | | | Migration |
| v4.0 | [RFC7931] | TrDisc-0 | [RFC7931] | Int-0 | +-------+-----------+----------+-----------+----------+-------------+
| v4.1+ | [RFC5661] | TrDisc-1 | TSM-1 | Int-1 | | v4.0 | [RFC7931] | TrDisc-0 | [RFC7931] | Mct-0 | Int-0 |
+---------+-----------+-----------+---------------+-----------------+ | v4.1+ | [RFC5661] | TrDisc-1 | TSM-1 | Mct-1 | Int-1 |
+-------+-----------+----------+-----------+----------+-------------+
The following table explains the work that needs to be done The following table explains the work that needs to be done
corresponding to each area name above. corresponding to each area name above.
+----------+--------------------------------------------------------+ +----------+--------------------------------------------------------+
| Area | Description | | Area | Description |
| Name | | | Name | |
+----------+--------------------------------------------------------+ +----------+--------------------------------------------------------+
| TrDisc-0 | Although it is possible for there to be multiple | | TrDisc-0 | Although it is possible for there to be multiple |
| | location entries for a given file system, the | | | location entries for a given file system, the |
skipping to change at page 41, line 11 skipping to change at page 47, line 34
| | Rectifying this situation along the lines of [RFC7931] | | | Rectifying this situation along the lines of [RFC7931] |
| | is complicated by the need to rewrite significant | | | is complicated by the need to rewrite significant |
| | pieces of the section about multi-server namespace to | | | pieces of the section about multi-server namespace to |
| | address this confusion. Beyond this, the necessary | | | address this confusion. Beyond this, the necessary |
| | treatment will need to reflect changes required by the | | | treatment will need to reflect changes required by the |
| | use of the sessions model and related changes in | | | use of the sessions model and related changes in |
| | NFSv.1 and also address migration-related issues | | | NFSv.1 and also address migration-related issues |
| | raised by optional features such as pNFS and the | | | raised by optional features such as pNFS and the |
| | fs_locations_info attribute. | | | fs_locations_info attribute. |
+----------+--------------------------------------------------------+ +----------+--------------------------------------------------------+
| Mct-0 | Even though protocol support for multiple connection |
| | types is quite limited in NFSv4.0, there still are |
| | multiple connection types specified and implemented. |
| | As a result, some guidance has to be given to allow |
| | interoperable implementations to be developed, and |
| | used, without extensive user configuration effort. |
| | This should include some treatment of situtions in |
| | which the set of connection types to be used to access |
| | a given file system changes, requiring appropriate |
| | recovery from an NFS4ERR_MOVED error. |
+----------+--------------------------------------------------------+
| Mct-1 | Even though protocol support for multiple connection |
| | types is more limited than one might like, there are |
| | helpful facilities that can be used to simplify the |
| | process of determining the connection type(s) to be |
| | uused. The proper use of the available facilities |
| | needs to be clarified including examination of cases |
| | in which the set of connection types to be used to |
| | access a given file system changes, requiring |
| | appropriate recovery from an NFS4ERR_MOVED error. |
+----------+--------------------------------------------------------+
| Int-0 | The need to provide trunking-related information puts | | Int-0 | The need to provide trunking-related information puts |
| | additional focus on the issue of dealing with changes | | | additional focus on the issue of dealing with changes |
| | in the value of location-related attributes. This | | | in the value of location-related attributes. This |
| | applies when trunking configurations change and at | | | applies when trunking configurations change and at |
| | other times as well. In addition, the existence of | | | other times as well. In addition, the existence of |
| | multiple network addresses connected to the same | | | multiple network addresses connected to the same |
| | server requires clarification when migration and | | | server requires clarification when migration and |
| | replication features are used. | | | replication features are used. |
+----------+--------------------------------------------------------+ +----------+--------------------------------------------------------+
| Int-1 | This requires similar handling to the case above. | | Int-1 | This requires similar handling to the case above. |
| | However, further work is made necessary by the fact | | | However, further work is made necessary by the fact |
| | that shifts between different sets of network | | | that shifts between different sets of network |
| | addresses are erroneously treated as instances of | | | addresses are erroneously treated as instances of |
| | migration in [RFC5661]. | | | migration in [RFC5661]. |
+----------+--------------------------------------------------------+ +----------+--------------------------------------------------------+
There are number of possible ways of packaging the necessary changes There are number of possible ways of packaging the necessary changes
into RFCs. Some of these are impractical for various reasons: into RFCs. Some of these are impractical for various reasons:
o While it possible to treat each area in its own RFC, writing five o While it possible to treat each area in its own RFC, writing seven
RFCs would increase the work required, and delay needed RFCs would increase the work required, and delay needed
corrections to both versions. Further, it would result in a corrections to both versions. Further, it would result in a
situation in which in which someone needing to understand the situation in which in which someone needing to understand the
specification of NFS version 4.0 or 4.1 would need to be familiar specification of NFS version 4.0 or 4.1 would need to be familiar
with a large set of RFCs. with a large set of RFCs.
o One could have a document addressing all of the areas above Such a o One could have a document addressing all of the areas above Such a
document would update both [RFC7530] and [RFC5661]. That would document would update both [RFC7530] and [RFC5661]. That would
result in a confusing document given how different the v4.0 and result in a confusing document given how different the v4.0 and
v4.1 protocols are, since most readers will want a clear v4.1 protocols are, since most readers will want a clear
description of one or the other. description of one or the other.
o It is also possible to produce separate documents addressing o It is also possible to produce separate documents addressing
Trdisc-*, TSM-1., an Int-*. This would be subject many of the Trdisc-*, TSM-1., Mct-*, and Int-*. This would be subject many of
difficulties of the two approaches above. the difficulties of the two approaches above.
The alternative, of organizing the changes by minor version, is being The alternative, of organizing the changes by minor version, is being
actively pursued. actively pursued by work on following Standards Track working group
documents:
o [I-D.cel-nfsv4-mv0-trunking-update] is a personal draft with a o [I-D.ietf-nfsv4-mv0-trunking-update] addresses the issues within
Standards Track Intended Status. It addresses the issues within
TrDisc-0 and Int-0 by providing updates to [RFC7530], the vast TrDisc-0 and Int-0 by providing updates to [RFC7530], the vast
majority of which are within Section 8 of that document. majority of which are within Section 8 of that document. Work to
include Mct-0 needs to be added.
o [I-D.dnoveck-nfsv4-mv1-msns-update] is a personal draft with a o [I-D.ietf-nfsv4-mv1-msns-update] addresses the issues within
Standards Track Intended Status. It addresses the issues within
TrDisc-1, TSM-1, and Int-1 providing updates to [RFC5661], the TrDisc-1, TSM-1, and Int-1 providing updates to [RFC5661], the
vast majority of which are within Section 11 of that document. vast majority of which are within Section 11 of that document.
Work to include Mct-1 is underway.
These documents will require additional review and discussion before These two documents will require additional review and discussion
the working group considers making them working group documents and before proceeding to publication as Proposed standards, updating
decides either to do so, or to address these issues in some other [RFC7530] and [RFC5661] respectively.
way.
If the former path is taken, it will be necessary to consolidate the If the working group decides to continue along this path, it may be
changes currently specified in these documents. Currently, these desirable to consolidate the changes currently specified in these
document replace individual sub-sections of Section 8 (of [RFC7530]) documents. Currently, these document replace individual sub-sections
or Section 11 (of [RFC5661]). While this is helpful in explaining of Section 8 (of [RFC7530]) or Section 11 (of [RFC5661]). While this
what is changing and why, things will be different when the eventual is helpful in explaining what is changing and why, things might be
RFC is published. At that point, it is likely to be more important different when the eventual RFC is published. At that point, it is
to have simply understood specifications of NFS versions 4.0 and 4.1. could be judged more important to have simply understood
At that point, a full replacement section of the affected section may specifications of NFS versions 4.0 and 4.1. At that point, a full
be more desirable as the basis of the RFC to be published. replacement section of the affected section might be more desirable
as the basis of the RFC to be published. Alternatively, that
consolidation might be delayed and done later as part of publication
of rfc7530bis and rfc5661bis documents.
7. Security Considerations 7. Security Considerations
In general, the Security Considerations sections of existing In general, the Security Considerations sections of existing
specifications for NFS versions 4.0 and 4.1 provide recommendations specifications for NFS versions 4.0 and 4.1 provide recommendations
for appropriate handling of requests obtaining location-related for appropriate handling of requests obtaining location-related
information. In particular, it is recommended that integrity information. In particular, it is recommended that integrity
protection be used when fetching location-related attributes: protection be used when fetching location-related attributes:
o With regard to NFSv4.01, this is done in Section 8.6 of [RFC7931] o With regard to NFSv4.0, this is done in Section 8.6 of [RFC7931]
which updates the Security Considerations section of [RFC7530]. which updates the Security Considerations section of [RFC7530].
o With regard to NFSv4.1, this is done in the Security o With regard to NFSv4.1, this is done in the Security
Considerations section of [RFC5661]. Considerations section of [RFC5661].
Despite this however, there is a need for further changes in the Despite this however, there is a need for further changes in the
Security Considerations with regard to both minor versions dealt with Security Considerations with regard to both minor versions dealt with
here. The following issues need to be addressed: here. The following issues need to be addressed:
o Because of the potential use of DNS to convert server names to a o Because of the potential use of DNS to convert server names to a
skipping to change at page 44, line 5 skipping to change at page 51, line 5
[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>.
[RFC5403] Eisler, M., "RPCSEC_GSS Version 2", RFC 5403, [RFC5403] Eisler, M., "RPCSEC_GSS Version 2", RFC 5403,
DOI 10.17487/RFC5403, February 2009, DOI 10.17487/RFC5403, February 2009,
<https://www.rfc-editor.org/info/rfc5403>. <https://www.rfc-editor.org/info/rfc5403>.
[RFC5531] Thurlow, R., "RPC: Remote Procedure Call Protocol
Specification Version 2", RFC 5531, DOI 10.17487/RFC5531,
May 2009, <https://www.rfc-editor.org/info/rfc5531>.
[RFC5661] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed., [RFC5661] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed.,
"Network File System (NFS) Version 4 Minor Version 1 "Network File System (NFS) Version 4 Minor Version 1
Protocol", RFC 5661, DOI 10.17487/RFC5661, January 2010, Protocol", RFC 5661, DOI 10.17487/RFC5661, January 2010,
<https://www.rfc-editor.org/info/rfc5661>. <https://www.rfc-editor.org/info/rfc5661>.
[RFC7530] Haynes, T., Ed. and D. Noveck, Ed., "Network File System [RFC7530] Haynes, T., Ed. and D. Noveck, Ed., "Network File System
(NFS) Version 4 Protocol", RFC 7530, DOI 10.17487/RFC7530, (NFS) Version 4 Protocol", RFC 7530, DOI 10.17487/RFC7530,
March 2015, <https://www.rfc-editor.org/info/rfc7530>. March 2015, <https://www.rfc-editor.org/info/rfc7530>.
[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>.
[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>.
[RFC8178] Noveck, D., "Rules for NFSv4 Extensions and Minor
Versions", RFC 8178, DOI 10.17487/RFC8178, July 2017,
<https://www.rfc-editor.org/info/rfc8178>.
[RFC8267] Lever, C., "Network File System (NFS) Upper-Layer Binding
to RPC-over-RDMA Version 1", RFC 8267,
DOI 10.17487/RFC8267, October 2017,
<https://www.rfc-editor.org/info/rfc8267>.
9.2. Informative References 9.2. Informative References
[I-D.cel-nfsv4-mv0-trunking-update] [I-D.ietf-nfsv4-mv0-trunking-update]
Lever, C. and D. Noveck, "NFS version 4.0 Trunking Lever, C. and D. Noveck, "NFS version 4.0 Trunking
Update", draft-cel-nfsv4-mv0-trunking-update-00 (work in Update", draft-ietf-nfsv4-mv0-trunking-update-00 (work in
progress), November 2017. progress), January 2018.
[I-D.dnoveck-nfsv4-mv1-msns-update] [I-D.ietf-nfsv4-mv1-msns-update]
Noveck, D. and C. Lever, "NFSv4.1 Update for Multi-Server Noveck, D. and C. Lever, "NFSv4.1 Update for Multi-Server
Namespace", draft-dnoveck-nfsv4-mv1-msns-update-01 (work Namespace", draft-ietf-nfsv4-mv1-msns-update-00 (work in
in progress), November 2017. progress), January 2018.
Acknowledgements [RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R.,
Beame, C., Eisler, M., and D. Noveck, "Network File System
(NFS) version 4 Protocol", RFC 3530, DOI 10.17487/RFC3530,
April 2003, <https://www.rfc-editor.org/info/rfc3530>.
Acknowledgments
The editor and authors of this document gratefully acknowledge the The editor and authors of this document gratefully acknowledge the
contributions of Trond Myklebust of Primary Data, Robert Thurlow of contributions of Trond Myklebust of Primary Data, Robert Thurlow of
Oracle, and Andy Adamson of NetApp. We also thank Tom Haynes of Oracle, and Andy Adamson of NetApp. We also thank Tom Haynes of
Primary Data and Spencer Shepler of Microsoft for their guidance and Primary Data and Spencer Shepler of Microsoft for their guidance and
suggestions. suggestions.
Special thanks go to members of the Oracle Solaris NFS team, Special thanks go to members of the Oracle Solaris NFS team,
especially Rick Mesta and James Wahlig who were then part of that especially Rick Mesta and James Wahlig who were then part of that
team, for their work implementing an NFSv4.0 migration prototype and team, for their work implementing an NFSv4.0 migration prototype and
identifying many of the issues documented here. Also, the work of identifying many of the issues documented here. Also, the work of
Xuan Qi for Oracle using NFSv4.1 client and server prototypes was Xuan Qi for Oracle using NFSv4.1 client and server prototypes was
helpful. helpful.
Authors' Addresses Authors' Addresses
David Noveck (editor) David Noveck (editor)
NetApp NetApp
26 Locust Avenue 1601 Trapelo Road
Lexington, MA 02421 Waltham, MA 02451
US US
Phone: +1 781 572 8038 Phone: +1 781 572 8038
Email: davenoveck@gmail.com Email: davenoveck@gmail.com
Piyush Shivam Piyush Shivam
Oracle Corporation IBM Corporation
5300 Riata Park Ct. 11501 Burnet Road
Austin, TX 78727 Austin, TX 78758
US US
Phone: +1 512 401 1019 Email: piyush.shivam@ibm.com
Email: piyush.shivam@oracle.com
Charles Lever Charles Lever
Oracle Corporation Oracle Corporation
1015 Granger Avenue 1015 Granger Avenue
Ann Arbor, MI 48104 Ann Arbor, MI 48104
US US
Phone: +1 248 614 5091 Phone: +1 248 614 5091
Email: chuck.lever@oracle.com Email: chuck.lever@oracle.com
Bill Baker Bill Baker
 End of changes. 60 change blocks. 
143 lines changed or deleted 495 lines changed or added

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