draft-ietf-nfsv4-migration-issues-13.txt   draft-ietf-nfsv4-migration-issues-14.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: November 17, 2017 C. Lever Expires: May 20, 2018 C. Lever
B. Baker B. Baker
ORACLE ORACLE
May 16, 2017 November 16, 2017
NFSv4 Migration and Trunking: Implementation and Specification Issues NFSv4 Migration and Trunking: Implementation and Specification Issues
draft-ietf-nfsv4-migration-issues-13 draft-ietf-nfsv4-migration-issues-14
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 network addresses to use to access a file system. The focus of the
discussion, which relates to multiple minor versions, is on providing discussion, which relates to multiple minor versions, is on defining
appropriate clarification and correction of existing specifications. the appropriate clarifications and corrections for existing
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 http://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 November 17, 2017. This Internet-Draft will expire on May 20, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (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. Multi-version Issues and Their Resolution . . . . . . . . . . 6
3.1. Multi-Version Issues . . . . . . . . . . . . . . . . . . 6 3.1. Multi-Version Issues . . . . . . . . . . . . . . . . . . 6
3.2. Resolution of Multi-Version Issues . . . . . . . . . . . 7 3.2. Resolution of Multi-Version Issues . . . . . . . . . . . 7
3.2.1. Providing Trunking Discovery . . . . . . . . . . . . 7 3.2.1. Providing Trunking Discovery . . . . . . . . . . . . 8
3.2.2. Interaction of Trunking and Migration . . . . . . . . 9 3.2.2. Interaction of Trunking and Migration . . . . . . . . 9
4. NFSv4.0 Issues . . . . . . . . . . . . . . . . . . . . . . . 11 4. NFSv4.0 Issues . . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Core NFSv4.0 Migration Issues . . . . . . . . . . . . . . 11 4.1. Core NFSv4.0 Migration Issues . . . . . . . . . . . . . . 11
4.2. Resolution of Core Migration Protocol Difficulties in 4.2. Resolution of Core Migration Protocol Difficulties in
NFSv4.0 . . . . . . . . . . . . . . . . . . . . . . . . . 12 NFSv4.0 . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.3. Additional NFSv4.0 Issues . . . . . . . . . . . . . . . . 12 4.3. Additional NFSv4.0 Issues . . . . . . . . . . . . . . . . 12
4.4. Resolution of Additional NFSv4.0 Issues . . . . . . . . . 12 4.4. Resolution of Additional NFSv4.0 Issues . . . . . . . . . 13
5. Issues for NFSv4.1 . . . . . . . . . . . . . . . . . . . . . 14 5. Issues for NFSv4.1 . . . . . . . . . . . . . . . . . . . . . 14
5.1. Issues to Address for NFSv4.1 . . . . . . . . . . . . . . 14 5.1. Issues to Address for NFSv4.1 . . . . . . . . . . . . . . 14
5.1.1. Addressing State Merger in NFSv4.1 . . . . . . . . . 15 5.1.1. Addressing State Merger in NFSv4.1 . . . . . . . . . 15
5.1.2. Addressing pNFS Relationship with Migration . . . . . 15 5.1.2. Addressing pNFS Relationship with Migration . . . . . 15
5.1.3. Addressing Server_owner Changes in NFSv4.1 . . . . . 16 5.1.3. Addressing Server_owner Changes in NFSv4.1 . . . . . 16
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 . . . . . . . . . . . . . . . . 17
5.1.5. Addressing Changes in Trunking Configuration . . . . 18 5.1.5. Addressing Changes in Trunking Configuration . . . . 18
5.1.6. Addressing Session Migration in NFSv4.1 . . . . . . . 18 5.1.6. Addressing Session Migration in NFSv4.1 . . . . . . . 19
5.2. Possible Resolutions for NFSv4.1 Protocol Issues . . . . 19 5.2. Possible Resolutions for NFSv4.1 Protocol Issues . . . . 19
5.2.1. Client ID Confirmation Issues . . . . . . . . . . . . 19 5.2.1. Client ID Confirmation Issues . . . . . . . . . . . . 19
5.2.2. Dealing with Multiple Location Entries . . . . . . . 20 5.2.2. Dealing with Multiple Location Entries . . . . . . . 20
5.2.3. Migration and pNFS . . . . . . . . . . . . . . . . . 22 5.2.3. Migration and pNFS . . . . . . . . . . . . . . . . . 23
5.3. Defining Server Responsibilities for NFSv4.1 . . . . . . 23 5.3. Defining Server Responsibilities for NFSv4.1 . . . . . . 24
5.3.1. Server Responsibilities in Effecting Transparent 5.3.1. Server Responsibilities in Effecting Transparent
State Migration . . . . . . . . . . . . . . . . . . . 24 State Migration . . . . . . . . . . . . . . . . . . . 24
5.3.2. Synchronizing Session Transfer . . . . . . . . . . . 25 5.3.2. Synchronizing Session Transfer . . . . . . . . . . . 25
5.4. Defining Client Responsibilities for NFSv4.1 . . . . . . 27 5.4. Defining Client Responsibilities for NFSv4.1 . . . . . . 28
5.4.1. Client Recovery from Migration Events . . . . . . . . 28 5.4.1. Client Recovery from Migration Events . . . . . . . . 28
5.4.2. The Migration Discovery Process . . . . . . . . . . . 30 5.4.2. The Migration Discovery Process . . . . . . . . . . . 30
5.4.3. Overview of Client Response to NFS4ERR_MOVED . . . . 31 5.4.3. Overview of Client Response to NFS4ERR_MOVED . . . . 31
5.4.4. Obtaining Access to Sessions and State after 5.4.4. Obtaining Access to Sessions and State after
Migration . . . . . . . . . . . . . . . . . . . . . . 33 Migration . . . . . . . . . . . . . . . . . . . . . . 33
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 . . . . . . . . . . . . . . . . . . 35
5.5. Resolution of NFSv4.1 Issues . . . . . . . . . . . . . . 35 5.5. Resolution of NFSv4.1 Issues . . . . . . . . . . . . . . 35
6. Security Considerations . . . . . . . . . . . . . . . . . . . 38 6. Evolution of Issue Handling . . . . . . . . . . . . . . . . . 38
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 6.1. History of this Document . . . . . . . . . . . . . . . . 38
8. Normative References . . . . . . . . . . . . . . . . . . . . 38 6.2. Further Work Needed . . . . . . . . . . . . . . . . . . . 39
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 38 7. Security Considerations . . . . . . . . . . . . . . . . . . . 42
Appendix B. History of this Document . . . . . . . . . . . . . . 39 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 43
9.1. Normative References . . . . . . . . . . . . . . . . . . 43
9.2. Informative References . . . . . . . . . . . . . . . . . 44
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 44
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45
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 27 skipping to change at page 5, line 27
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 addresses 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 addresses 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 addresses connected to the same server such that those
addresses can be used to support a single common session are addresses can be used to support a single common session are
referred to as session-trunkable. Note that two addresses may be referred to as session-trunkable. Note NFSv4.1 allows two
server-trunkable without being session-trunkable. addresses to be server-trunkable without being session-trunkable,
while in NFSv4.0 no addresses are session-trunkable, 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 address can obtain other addresses that are trunkable
(either server-trunkable or session-trunkable) with it. (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.
skipping to change at page 6, line 48 skipping to change at page 6, line 50
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 contains 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 that relates to specific protocol
versions and documents: 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.
skipping to change at page 17, line 37 skipping to change at page 17, line 47
is clear that the transferred client ID needs to be considered is clear that the transferred client ID needs to be considered
confirmed, as the existence of an associated session is incompatible confirmed, as the existence of an associated session is incompatible
with an unconfirmed client ID. with an unconfirmed client ID.
The case in which a client ID is transferred without an associated The case in which a client ID is transferred without an associated
session is less clear-cut, particularly since the treatment of session is less clear-cut, particularly since the treatment of
EXCHANGE_ID in [RFC5661] assumes that CREATE_SESSION is the only EXCHANGE_ID in [RFC5661] assumes that CREATE_SESSION is the only
means by which a client id may be confirmed. While this assumption means by which a client id may be confirmed. While this assumption
is valid in the absence of Transparent State Migration, is valid in the absence of Transparent State Migration,
implementation of migration means that if this assumption is implementation of migration means that if this assumption is
maintained, it is not clear how migrated client ID s can be a maintained, it is not clear how migrated client IDs can be a
accommodated. If this assumption were maintained, we would have to accommodated. If this assumption were maintained, we would have to
choose between the following two alternatives, regarding whether the choose between the following two alternatives, regarding whether the
client ID to be reported as confirmed when EXCHANGE_ID is used to client ID to be reported as confirmed when EXCHANGE_ID is used to
register an already-known client_owner with the server. register an already-known client_owner with the server.
o Report the client ID unconfirmed, because of the lack of an o Report the client ID unconfirmed, because of the lack of an
associated session. This makes it simpler for the client to associated session. This makes it simpler for the client to
determine whether there is an associated session transferred at determine whether there is an associated session transferred at
the same time. However, it is inconsistent with the fact there the same time. However, it is inconsistent with the fact there
are stateids which have been transferred with the client ID. are stateids which have been transferred with the client ID.
skipping to change at page 28, line 36 skipping to change at page 28, line 42
This condition continues until the client acknowledges the This condition continues until the client acknowledges the
notification by fetching a location attribute for the migrated notification by fetching a location attribute for the migrated
file system. When there are multiple migrated file systems, a file system. When there are multiple migrated file systems, a
location attribute for each such migrated file system needs to be location attribute for each such migrated file system needs to be
fetched, in order to clear the condition. Even after the fetched, in order to clear the condition. Even after the
condition is cleared, the client needs to respond by using the condition is cleared, the client needs to respond by using the
location information to access the destination server to ensure location information to access the destination server to ensure
that leases are not needlessly expired. that leases are not needlessly expired.
Unlike the case of NFSv4.0 in which the corresponding conditions are Unlike the case of NFSv4.0 in which the corresponding conditions are
both errors, in NFSv4.1 the client can, and often will, receive both distinct errors and thus mutually exclusive, in NFSv4.1 the client
indications on the same request. As a result, implementations need can, and often will, receive both indications on the same request.
to address the question of how to co-ordinate the necessary recovery As a result, implementations need to address the question of how to
actions when both indications arrive simultaneously. It should be co-ordinate the necessary recovery actions when both indications
noted that when the server decides whether SEQ4_STATUS_LEASE_MOVED is arrive simultaneously. It should be noted that when the server
to be set, it has no way of knowing which file system will be decides whether SEQ4_STATUS_LEASE_MOVED is to be set, it has no way
referenced or whether NFS4ERR_MOVED will be returned. of knowing which file system will be referenced or whether
NFS4ERR_MOVED will be returned.
While it is true that, when only a single migrated file system is While it is true that, when only a single migrated file system is
involved, a single set of actions will clear both indications, the involved, a single set of actions will clear both indications, the
possibility of multiple migrated file systems calls for an approach possibility of multiple migrated file systems calls for an approach
in which there are separate recovery actions for each indication. In in which there are separate recovery actions for each indication. In
general, the response to neither indication can be subsumed within general, the response to neither indication can be subsumed within
the other since: the other since:
o If the client were to respond only to the MOVED indication, there o If the client were to respond only to the MOVED indication, there
would be no effective client response to a situation in which a would be no effective client response to a situation in which a
skipping to change at page 38, line 12 skipping to change at page 38, line 19
"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.
6. Security Considerations 6. Evolution of Issue Handling
With regard to NFSv4.0, the Security Considerations section of
[RFC7530] as modified by that of [RFC7931] takes proper care of
migration-related issues. No change is needed.
With regard to NFSv4.1, the Security Considerations section of
[RFC5661] takes proper care of migration-related issues. No change
is needed.
7. IANA Considerations
This document does not require actions by IANA.
8. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC5661] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed.,
"Network File System (NFS) Version 4 Minor Version 1
Protocol", RFC 5661, DOI 10.17487/RFC5661, January 2010,
<http://www.rfc-editor.org/info/rfc5661>.
[RFC7530] Haynes, T., Ed. and D. Noveck, Ed., "Network File System
(NFS) Version 4 Protocol", RFC 7530, DOI 10.17487/RFC7530,
March 2015, <http://www.rfc-editor.org/info/rfc7530>.
[RFC7931] Noveck, D., Ed., Shivam, P., Lever, C., and B. Baker,
"NFSv4.0 Migration: Specification Update", RFC 7931,
DOI 10.17487/RFC7931, July 2016,
<http://www.rfc-editor.org/info/rfc7931>.
Appendix A. Acknowledgements
The editor and authors of this document gratefully acknowledge the
contributions of Trond Myklebust of Primary Data, Robert Thurlow of
Oracle, and Andy Adamson of NetApp. We also thank Tom Haynes of
Primary Data and Spencer Shepler of Microsoft for their guidance and
suggestions.
Special thanks go to members of the Oracle Solaris NFS team,
especially Rick Mesta and James Wahlig, for their work implementing
an NFSv4.0 migration prototype and identifying many of the issues
documented here. Also, the work of Xuan Qi of Oracle with NFSv4.1
client and server prototypes was helpful.
Appendix B. 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 here have 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.
As a result, it may be helpful to understand the history of these As a result, it may be helpful to understand the history of these
issues, which is complicated because multiple NFSv4 protocols have issues, which is complicated because multiple NFSv4 protocols have
been involved. been involved.
This history can be summarized as follows This history can be summarized as follows
skipping to change at page 39, line 45 skipping to change at page 39, line 5
of the problem and further work proceeded on that basis. of the problem and further work proceeded on that basis.
During the period, treatment of NFSv4.1 was expanded but the fact During the period, treatment of NFSv4.1 was expanded but the fact
that NFSv4.1 had existing facilities for trunking detection was that NFSv4.1 had existing facilities for trunking detection was
taken as an indication that the problems would not be difficult to taken as an indication that the problems would not be difficult to
address.. address..
o As work proceeded on a standards-track document addressing the o As work proceeded on a standards-track document addressing the
NFSv4.0 issues, material that proposed changes to address the NFSv4.0 issues, material that proposed changes to address the
issues became less relevant, since the effective vehicle for issues became less relevant, since the effective vehicle for
addressing these issues became the standards-track document. addressing these issues became the standards-track document
eventually published as [RFC7931].
During this period, and subsequently, treatment of NFSv4.1 During this period, and subsequently, treatment of NFSv4.1
remained essentially unchanged. remained essentially unchanged.
o With the publication of [RFC7931], material regarding fixes for o With the publication of [RFC7931], material regarding fixes for
the NSV4.0 became vestigial but the material was retained for a the NSV4.0 became vestigial but the material was retained for a
while together with a shift from proposing those changes to while together with a shift from proposing those changes to
reporting that they had been made. reporting that they had been made.
o Later, in response to experiences testing existing NFSv4.1 o Later, in response to experiences testing existing NFSv4.1
skipping to change at page 40, line 29 skipping to change at page 39, line 38
o Finally, based on the results of work to provide NFSv4 with o Finally, based on the results of work to provide NFSv4 with
trunking discovery facilities, a decision was made that this work trunking discovery facilities, a decision was made that this work
was most appropriately dealt with together with migration, for was most appropriately dealt with together with migration, for
reasons noted previously. reasons noted previously.
Since the trunking discovery facilities apply to all NFSv4 minor Since the trunking discovery facilities apply to all NFSv4 minor
versions, work was needed to define those for NFSv4.0as well, versions, work was needed to define those for NFSv4.0as well,
together with the necessary interactions with migration. together with the necessary interactions with migration.
Although there is a need for further working group discussion and
review, it appears that the issues to be dealt with have been
identified and that most work to address these issues need to take
place as part of the construction of one or more standards-track
documents. See Section 6.2 for further information about possible
approaches to providing the necessary documents.
6.2. Further Work Needed
The following table classifies issues in this area and indicates
which are currently adequately addressed and where the protocol
specifications need further correction or clarification. Where the
topic is adequately addressed, a reference is given to the RFC
providing support for the issue. In other cases, an area name
(explained below) is given.
+---------+-----------+-----------+---------------+-----------------+
| Version | Trunking | Trunking | Transparent | Interaction of |
| | Detection | Discovery | State | Trunking and |
| | | | Migration | Migration |
+---------+-----------+-----------+---------------+-----------------+
| v4.0 | [RFC7931] | TrDisc-0 | [RFC7931] | Int-0 |
| v4.1+ | [RFC5661] | TrDisc-1 | TSM-1 | Int-1 |
+---------+-----------+-----------+---------------+-----------------+
The following table explains the work that needs to be done
corresponding to each area name above.
+----------+--------------------------------------------------------+
| Area | Description |
| Name | |
+----------+--------------------------------------------------------+
| TrDisc-0 | Although it is possible for there to be multiple |
| | location entries for a given file system, the |
| | possibility of using these to enable trunking |
| | discovery was not addressed in [RFC7530], most likely |
| | because trunking was considered a problem to be |
| | avoided (rather than a helpful feature) at that time. |
| | This situation could have been addressed by the |
| | publication of [RFC7931] but unfortunately that did |
| | not happen. |
+----------+--------------------------------------------------------+
| TrDisc-1 | Despite the fact that [RFC5661] provides a means of |
| | trunking detection, trunking discovery was not |
| | addressed. This problem was compounded by confusion |
| | regarding multiple file system replicas arising from |
| | the fact that multiple network addresses connected to |
| | the same server were treated as if they were referring |
| | to distinct sets of replicas. |
+----------+--------------------------------------------------------+
| TSM-1 | Unlike [RFC7530], which mishandled Transparent State |
| | Migration because of confusion arising from the lack |
| | of appropriate trunking support, [RFC5661] simply |
| | neglected to provide any description of this feature. |
| | It appears likely that confusion between the needs of |
| | migration and those of dealing with shifts in |
| | responsibility for clustered file system access had |
| | significant role in allowing this issue to be ignored. |
| | Rectifying this situation along the lines of [RFC7931] |
| | is complicated by the need to rewrite significant |
| | pieces of the section about multi-server namespace to |
| | address this confusion. Beyond this, the necessary |
| | treatment will need to reflect changes required by the |
| | use of the sessions model and related changes in |
| | NFSv.1 and also address migration-related issues |
| | raised by optional features such as pNFS and the |
| | fs_locations_info attribute. |
+----------+--------------------------------------------------------+
| Int-0 | The need to provide trunking-related information puts |
| | additional focus on the issue of dealing with changes |
| | in the value of location-related attributes. This |
| | applies when trunking configurations change and at |
| | other times as well. In addition, the existence of |
| | multiple network addresses connected to the same |
| | server requires clarification when migration and |
| | replication features are used. |
+----------+--------------------------------------------------------+
| Int-1 | This requires similar handling to the case above. |
| | However, further work is made necessary by the fact |
| | that shifts between different sets of network |
| | addresses are erroneously treated as instances of |
| | migration in [RFC5661]. |
+----------+--------------------------------------------------------+
There are number of possible ways of packaging the necessary changes
into RFCs. Some of these are impractical for various reasons:
o While it possible to treat each area in its own RFC, writing five
RFCs would increase the work required, and delay needed
corrections to both versions. Further, it would result in a
situation in which in which someone needing to understand the
specification of NFS version 4.0 or 4.1 would need to be familiar
with a large set of RFCs.
o One could have a document addressing all of the areas above Such a
document would update both [RFC7530] and [RFC5661]. That would
result in a confusing document given how different the v4.0 and
v4.1 protocols are, since most readers will want a clear
description of one or the other.
o It is also possible to produce separate documents addressing
Trdisc-*, TSM-1., an Int-*. This would be subject many of the
difficulties of the two approaches above.
The alternative, of organizing the changes by minor version, is being
actively pursued.
o [I-D.cel-nfsv4-mv0-trunking-update] is a personal draft with a
Standards Track Intended Status. It addresses the issues within
TrDisc-0 and Int-0 by providing updates to [RFC7530], the vast
majority of which are within Section 8 of that document.
o [I-D.dnoveck-nfsv4-mv1-msns-update] is a personal draft with a
Standards Track Intended Status. It addresses the issues within
TrDisc-1, TSM-1, and Int-1 providing updates to [RFC5661], the
vast majority of which are within Section 11 of that document.
These documents will require additional review and discussion before
the working group considers making them working group documents and
decides either to do so, or to address these issues in some other
way.
If the former path is taken, it will be necessary to consolidate the
changes currently specified in these documents. Currently, these
document replace individual sub-sections of Section 8 (of [RFC7530])
or Section 11 (of [RFC5661]). While this is helpful in explaining
what is changing and why, things will be different when the eventual
RFC is published. At that point, it is likely to be more important
to have simply understood specifications of NFS versions 4.0 and 4.1.
At that point, a full replacement section of the affected section may
be more desirable as the basis of the RFC to be published.
7. Security Considerations
In general, the Security Considerations sections of existing
specifications for NFS versions 4.0 and 4.1 provide recommendations
for appropriate handling of requests obtaining location-related
information. In particular, it is recommended that integrity
protection be used when fetching location-related attributes:
o With regard to NFSv4.01, this is done in Section 8.6 of [RFC7931]
which updates the Security Considerations section of [RFC7530].
o With regard to NFSv4.1, this is done in the Security
Considerations section of [RFC5661].
Despite this however, there is a need for further changes in the
Security Considerations with regard to both minor versions dealt with
here. The following issues need to be addressed:
o Because of the potential use of DNS to convert server names to a
set of server network addresses, such translations are subject to
the same sorts of potential interference with trunking discovery
that would occur when trunking discovery is provided using network
addresses returned in the location-related attributes.
To address this issue, specifications for both minor versions need
to mention the issue and indicate that use of DNSSEC [RFC4033] is
appropriate. When it is not available, the server should allow
use of DNS for trunking discovery to be avoided by presenting
network addresses in the location-related attributes, with these
values subject to RPCSECGSS integrity protection.
o Although use of RPCSEC_GSS ([RFC2203], [RFC5403], [RFC7861]) with
integrity protection is RECOMMENDED and "implementations" are
REQUIRED to provide support. However, the possibility that a
particular client may be unable to use RPCSEC_GSS when accessing a
particular server cannot be excluded. As a result, it is
necessary to discuss how such situations affect trunking
discovery, referral, replication, and migration.
o In the case of replication, referral, and migration, it is
necessary to discuss how RPCSEC_GSS mutual authentication on the
destination can be used to make sure that the network addresses
provided by trunking discovery have not been interfered with and
correspond to the server names provided by the location attributes
on the server to which the client was directed.
8. IANA Considerations
This document does not require actions by IANA.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC2203] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol
Specification", RFC 2203, DOI 10.17487/RFC2203, September
1997, <https://www.rfc-editor.org/info/rfc2203>.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, DOI 10.17487/RFC4033, March 2005,
<https://www.rfc-editor.org/info/rfc4033>.
[RFC5403] Eisler, M., "RPCSEC_GSS Version 2", RFC 5403,
DOI 10.17487/RFC5403, February 2009,
<https://www.rfc-editor.org/info/rfc5403>.
[RFC5661] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed.,
"Network File System (NFS) Version 4 Minor Version 1
Protocol", RFC 5661, DOI 10.17487/RFC5661, January 2010,
<https://www.rfc-editor.org/info/rfc5661>.
[RFC7530] Haynes, T., Ed. and D. Noveck, Ed., "Network File System
(NFS) Version 4 Protocol", RFC 7530, DOI 10.17487/RFC7530,
March 2015, <https://www.rfc-editor.org/info/rfc7530>.
[RFC7861] Adamson, A. and N. Williams, "Remote Procedure Call (RPC)
Security Version 3", RFC 7861, DOI 10.17487/RFC7861,
November 2016, <https://www.rfc-editor.org/info/rfc7861>.
[RFC7931] Noveck, D., Ed., Shivam, P., Lever, C., and B. Baker,
"NFSv4.0 Migration: Specification Update", RFC 7931,
DOI 10.17487/RFC7931, July 2016,
<https://www.rfc-editor.org/info/rfc7931>.
9.2. Informative References
[I-D.cel-nfsv4-mv0-trunking-update]
Lever, C. and D. Noveck, "NFS version 4.0 Trunking
Update", draft-cel-nfsv4-mv0-trunking-update-00 (work in
progress), November 2017.
[I-D.dnoveck-nfsv4-mv1-msns-update]
Noveck, D. and C. Lever, "NFSv4.1 Update for Multi-Server
Namespace", draft-dnoveck-nfsv4-mv1-msns-update-01 (work
in progress), November 2017.
Acknowledgements
The editor and authors of this document gratefully acknowledge the
contributions of Trond Myklebust of Primary Data, Robert Thurlow of
Oracle, and Andy Adamson of NetApp. We also thank Tom Haynes of
Primary Data and Spencer Shepler of Microsoft for their guidance and
suggestions.
Special thanks go to members of the Oracle Solaris NFS team,
especially Rick Mesta and James Wahlig who were then part of that
team, for their work implementing an NFSv4.0 migration prototype and
identifying many of the issues documented here. Also, the work of
Xuan Qi for Oracle using NFSv4.1 client and server prototypes was
helpful.
Authors' Addresses Authors' Addresses
David Noveck (editor) David Noveck (editor)
NetApp NetApp
26 Locust Avenue 26 Locust Avenue
Lexington, MA 02421 Lexington, MA 02421
US US
Phone: +1 781 572 8038 Phone: +1 781 572 8038
Email: davenoveck@gmail.com Email: davenoveck@gmail.com
 End of changes. 23 change blocks. 
83 lines changed or deleted 293 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/