NFSv4 D. Noveck
Internet-Draft Dell
Intended status: Informational March 8, 2015
Expires: September 9, 2015

NFS Protocol Extension: Retrospect and Prospect
draft-dnoveck-nfs-extension-02

Abstract

This document surveys the processes by which the NFS protocol has been extended in the past, including all of the NFS major and minor versions. A particular focus is on how the minor versioning model of NFSv4 has worked and what might be done to enhance version management within NFSv4.

The work already done in the new NFSv4 version management document is summarized, and there is a discussion of further issues the working group will need to address in moving that work forward.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on September 9, 2015.

Copyright Notice

Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

1. Introduction

This document examines the subject of protocol extension within the NFS family of protocols. In order to better understand the issues that exist going forward with NFSv4, we examine the history of protocol extension throughout the development of NFS including

With this history in mind, we discuss the issues that the working group needs to address to create an NFSv4 versioning RFC that will serve to define a comprehensive approach to version management for the NFSv4 family of protocols.

1.1. Use of Key words defined in RFC2119

It is intended that these key words be used in this document in a way consistent with their definition in [RFC2119].

However, because of the considerations noted below, there are some issues that readers need to be aware of:

The reader should be aware of our basic practices regarding these terms.

The use of these terms as part of minor versioning rules poses troublesome issues in the context of this document.

2. Protocol Extension

Protocols often require means by which they can be extended. Such extensions may be needed to meet new requirements, to correct protocol weaknesses exposed by experience, or even to correct protocol bugs (as can happen when protocols are published as RFC's without fully fleshed-out implementations).

We need to distinguish here between protocol "extension" and "versioning". Versioning is a form of protocol extension but not every form of protocol extension can be accommodated within a versioning paradigm.

When a versioning paradigm is in place, groups of extensions are conceived of as ordered, allowing extensions in subsequent versions to build upon those in previous versions. When multiple extensions are combined into a single version, each of the extensions may be built assuming that the others will be present as well. In such cases, there can be the opportunity to make design changes in the protocol, allowing elements of the protocol to be restructured, sometimes in major ways.

When a versioning paradigm is in effect and extensions are optional, extensions cannot build upon one another, since the presence of any particular extension cannot be assumed. In such cases, the ability to restructure the protocol is reduced, but smaller changes may be introduced more easily.

In this latter case, it is not clear that the word "versioning" is appropriate. Nevertheless, in this document, we will, as in the phrase "NFSv4 minor versioning" use the existing terminology without necessarily subscribing to the view that "versioning" is the appropriate description.

3. Protocol Extension Mechanisms

Some factors that are often relevant in deciding on the means by which a protocol will be extended.

While it is possible to use different sorts of extension mechanisms for different sorts of extensions, protocols typically do not take advantage of that flexibility.

On the other hand, protocols do, as NFS has done, change their preferred extension mechanisms in response to long-term changes in requirements. However, once having done so, they rarely switch back. Changing extension mechanisms is a big step, both conceptually and in implementation terms, and is not frequently repeated.

3.1. Specific Protocol Mechanisms Designed for Extension

Often, protocols will be designed with specific mechanisms, designed to allow protocol extension. An example is the provision for TCP options (see [RFC0793] and [RFC2780].) Most often, such mechanisms are designed to allow individual extensions to be designed and implemented independently, with any dependency relations between extensions specified separately and not enforced by the extension mechanism itself.

3.2. Protocol Extension by XDR Replacement

RPC-based protocols may, and often do, provide for protocol extension by replacing the XDR for one version with that for another and using the RPC versioning mechanism to manage selection of the proper protocol variant. The use of the RPC versioning mechanism enforces a versioning paradigm of this sort on protocols using this extension mechanism.

This extension mechanism allows very extensive protocol changes, up to and including the replacement of one protocol by an entirely different one. For some kinds of protocol extensions, this seems the only way to effect the change.

3.3. Protocol Extension by XDR Extension

It is possible to replace an XDR definition by one which is an extension in the sense that

Within an XDR/RPC framework, extensions can be arrived at by:

Such an extension relation between XDR descriptions is reflexive and transitive and thus defines a partial order. In practice, provisions have to be made to make sure that two extensions of the same description are compatible (i.e. either one is an extension of the other, or there is a another description that is a valid extension of both).

To put things in concrete terms, such compatibility can be assured if measures are taken to ensure:

3.4. Combination of Protocol Extension Mechanisms

It is possible to use multiple of these means of protocol extension simultaneously. When this is done, the result is a composite extension mechanism. For example, if the XDR replacement or XDR extension mechanism is adopted, a protocol-specific mechanism can be added to it, if the protocol-specific mechanism is built on objects whose XDR definition is sufficiently generic. (e.g. opaque arrays or feature bitmasks).

It can be argued that the NFSv4 attribute model provides such an embedded protocol-specific extension mechanism, since sets of attribute values are specified as XDR opaque arrays and attribute sets are specified as variable-length arrays of 32-bit integers allowing new attribute bits to be defined outside of the XDR definition framework.

Note that there exists specification text that suggests that attributes are part of the XDR specification, making it hard to reach a firm conclusion on the matter. However, the resolution of this question does not affect the other matters discussed below, since, in either case, we have an extension mechanism that allows optional extensions.

4. Pre-IETF NFS Versioning

4.1. The Pre-IETF NFS Environment

NFSv2 and NFSv3 were described by the informational RFC's [RFC1094] and [RFC1813]. These documents each described existing interoperating client and server implementations. Thus they started with running code. If there was a rough consensus in effect, it was that these were useful protocols to use and thus that someone building a client or server had to interoperate with the existing implementations.

The following characteristics of protocol development during that period are noteworthy.

As a result of these commonalities, specifications tended to avoid a lot of detail that would have been required in a more diverse environment. New features were thought of in terms of generally understood client and server implementation frameworks and it was generally clear which of those could be implemented without markedly changing that framework.

4.2. Transition from NFSv2 to NFSv3

There were a number of significant changes involved, but only the first two were of major importance.

Of these only the first actually needed something as drastic as the XDR replacement model. The others could have been handled simply by adding new RPC requests and an enum value to an existing NFSv2 XDR. Since, NFS's extension mechanism was then XDR replacement, such choices were not available.

5. Initial Approach to NFS Versioning Within IETF

5.1. Transition from NFSv3 to NFSv4

NFSv4 was the first NFS version published as a Standards track document. Although an initial [RFC3010], entitled "NFS version 4 protocol" was published as a Proposed Standard, it was never implemented due to issues with the design of locking.

Subsequently, [RFC3530], entitled "Network File System (NFS) version 4 Protocol" was published as a Proposed Standard, obsoleting [RFC3010]. Currently, there are bis documents, [RFC3530bis] and [RFC3530bis-dotx], nearing publication.

The set of changes made to create NFSv4 was larger by far than that for NFSv3. A partial list follows.

These features/extensions were implemented via the XDR replacement model. This was the only realistic alternative, not only because of the size of the list, but also because some of the changes undercut some of the central design elements of the pre-IETF NFS protocol.

5.2. Initial Minor Versioning Model for NFSv4

The minor versioning approach for NFSv4 uses an XDR extension model. It was presented within a versioning paradigm but the fact that all the added features were to be (at least initially) optional indicated that features were intended to be built independently, and that clients were expected to deal with their presence or absence. Note that the term "features" is not explicitly defined. We assume that the definition includes operations within COMPOUND or CB_COMPOUND, attributes, added flag bits and enum values, and new cases of XDR switch definitions.

Now let's look at some specifics of the minor version rules established for NFSv4 in [RFC3530]. Note that some of these were significantly modified by [RFC5661] and [NFSv42], as discussed in Section 5.6.

This model was subsequently modified in [RFC5661] and in [NFSv42]. See Sections 5.3 and 5.4 for details.

Many of the events anticipated in the model presented above have never been realized and it may be that they never will be realized. See Section 5.5 for some details. Examples are:

5.3. Transition from NFSv4.0 to NFSv4.1

NFSv4.1 was described in [RFC5661] and [RFC5662], each of which was published as a Proposed Standard.

NFSv4.1 made a major change to NFSv4.0. It was able to do primarily using an XDR extension model although it did not follow the rules laid out in Section 5.2. Instead, [RFC5661] presented its own set of minor versioning rules.

The following major changes in the rules were made.

NFSv4.1 also bypassed the versioning rules by making non-XDR-based protocol changes. See Section 6.1 for a discussion of the logic behind such changes.

The following features were added as infrastructural features.

In addition to these required features, there were a number of non-XDR-based changes made in NFSv4.1. Although not thought of as "features" at the time, they are described in [RFC5661], which gives no indication that support is optional. These include:

There also a number of non-required features. While such features are optional in the sense that a server may or may not support them, it is not clear that all are optional in terms of the existing minor versioning rules. Given that all attributes are specified as REQUIRED OR RECOMMENDED, it may be that attributes that may or may not be supported are considered recommended from the viewpoint of the minor versioning rules. Here and in the future we will use "non-required" instead of "optional or recommended".

The following non-required features were added.

Note that there has been little implementation work on the last two of these.

Parallel NFS created an alternate protocol extension mechanism for NFS. New pNFS mapping types could be added. Existing mapping types might have their own extension mechanisms. There also exists the possibility that features might be added within the NFSv4 protocol proper, designed to, or capable of, interacting with particular mapping types. This document will not these issues but eventually, the NFSv4 Versioning RFC will have to address them.

5.4. Transition from NFSv4.1 to NFSv4.2

While NFSv4.2 has not been defined in an RFC, its development has been going on for some time and it is unlikely to experience additions to or deletions from its feature set before completion. The descriptions in [NFSv42] and [NFSv42-dotx] can serve as useful references for this analysis. This is despite the fact that some of the features may later experience changes.

Because of the lengthy process involved in producing NFSv4.1, the working group decided that NFSv4.2 was to be a relatively small minor version consisting only of optional features which would be documented by specifying changes from NFSv4.1.

The following features (all optional) are provided for in NFSv4.2:

Note that there are two pieces of infrastructure that are used by multiple features above. These are not "infrastructural" in the sense mentioned in Section 5.3 (i.e. they are not required), but they do serve an infrastructural role in that are required to be present if one of the optional features that use them are supported.

5.5. Evolution of Minor Versioning Model within NFSv4

As noted above, there have been changes made by [RFC5661] and [NFSv42] in the NFSV4 minor versioning model.

Taking note of these changes, we can classify potential minor versions, starting with those that currently exist, based on how they affect inter-version compatibility.

5.6. The Role of Minor Version Number in NFSv4

Minor versions which may affect inter-version compatibility, form an ascending sequence in which we also have a versioning paradigm, implemented principally using XDR extension.

Optional-feature-only versions are fundamentally different. Each NFSv4.2 server implements the same protocol as NFSv4.1 with a particular set of optional or recommended features beyond those that are required. This set may range from the null set all the way to all of the non-required features. Here, it appears that the versioning paradigm is not appropriate to the reality of the extension mechanism.

As a way of illustrating the basic point here, let us consider two servers each of which only supports operations within NFSv4.1:

Although this obeys the rules as they stand, there is no obvious value for the client, the server, or the protocol in making these artificial distinctions. Optional-feature-only minor versions such as NFSv4.2 are not minor versions in the same sense that NFSv4.0 and NFSv4.1 are. In this case the minorversion field is not providing any information, while the set of operations supported is the important thing that the server implementer chooses and the client needs to know.

It is not clear how thus mismatch will be resolved. Nevertheless, it is an indication that the focus previously placed on the construction of minor versions was misplaced and that managing the addition of features is in most cases the fundamental issue. How minor versions are to fit within that framework is something that the group needs to decide.

5.7. Review of NFSv4 Versioning through NFSv4.2

To summarize protocol extension as it has been applied to the NFSv4 protocols:

It is important to note that NFSv4.0 (in [RFC3530] and [RFC3530bis]), both about 300 pages and NFSV4.1 (in [RFC5661]), about 600 pages documented the entire minor version. On the other hand, the NFSv4.2 specification document (in [NFSv42]) simply specified the changes from the previous minor version, in about 100 pages.

Given the difficulties of writing very large specifications, it has to be considered extremely unlikely, that any future minor versions will be documented other than as a set of changes from the previous minor version.

6. Inherited NFSv4 Versioning Approach

6.1. Non-XDR-based Changes

Although not recognized at the time, the existence of non-XDR-based protocol changes is part of the existing NFSv4 versioning approach and must be addressed in any revision of NFSv4 versioning.

Such changes have been of two types:

All such changes have been implemented as required with implementations using the minor version field of the COMPOUND to determine whether the change applies to a particular request.

6.2. Inherited NFS Versioning Practices

The following pattern was followed for NFSv4.2, and, unless changes are made, seems likely to persist.

This pattern of development is not a good fit for the kind of minor version that NFSv4.2 is and many future such minor versions will be. Such versions consist of a set of mostly unrelated features, each individually selectable or not by implementers, artificially yoked together. In essence, we have a "feature batch" rather than a minor version.

6.3. Problems with Inherited NFS Versioning Approach

A number of issues have been noted with the existing process for NFSv4.2, leading to the conclusion that the process needs to be revised in some way for future minor versions, of the same sort.

Some instances of problems/issues ascribable to a lack of searching document review are described below. Rather than requiring the necessary review prior to feature acceptance, a common pattern has been that important issues are only discovered on those occasions in which it appears that work on the minor version is coming to a close and that there are issues that have to be addressed before they create difficulties for prospective implementers.

If we look at the problems above, we can understand better how such problems can arise. In short, the decision as to what features to include within a minor version, is not a good use of the rough consensus model and in proceeding on that basis, the group created a set of perverse incentives that undercut the process. Also, as the process goes on for a long time, as is likely, these perverse incentives are intensified. Consider the following points:

7. Formulating a New NFSv4 Extension Approach

The following issues led the working group to consider formulation of a new approach to NFSv4 versioning:

8. Current Versioning-related Work

8.1. New Working Group Versioning Document

The working group has started work on a standards-track document ([NFSv4-vers]) defining an approach to version management that is intended to apply to NFSv4 as a whole. Noteworthy advances in that document include

8.2. Related Changes to Other Documents

During this period, changes were made to some related documents, as they moved toward publication.

Some of these changes were made to simplify handling of the transition in versioning models that would occur upon publication of [NFSv4-vers] as an RFC.

As a result of these changes, upon publication of an NFSv4 version management RFC, it will only need to be marked as updating [RFC5661].

Another relevant change concerned the use of the term "RECOMMENDED" regarding attributes which are not REQUIRED. As it appeared that this usage is inconsistent with [RFC2119], [RFC3530bis] was modified to include the following statement:

A reasonable conclusion to draw from this is that while certain attributes are indeed REQUIRED, the other ones cannot be designated as "RECOMMENDED" as that term is defined in [RFC2119]. The following issues remain to be resolved:

9. Issues Going Forward

As of now, the versioning document incorporates two conceptual models which need to be better integrated as the document moves toward RFC status

9.1. Dealing with Minor Version Scope Issues

With the exception of the incorporation of minor versioning rules (based on those in [RFC5661]), the current NFSv4 versioning document is focused on addressing the problems that have been seen with minor versions that are like NFSv4.2, in that they add non-required features and do nothing else. Such versions may not make any of the following types of changes:

Each of the above types of change has occurred as part of NFSv4.1. While it is quite likely that the working group is prepared to foreclose future minor versions with as large a scope as NFSv4.1, it is not clear that the working group is prepared to decide that only changes like those in NFSv4.2 be made in all future minor versions.

As work proceeds on [NFSv4-vers], the working group will have to decide which, if any of the above sorts of changes to allow in minor versions, even if most minor versions do not use these additional forms of change. As part of that, the working group will have to decide:

9.2. Issues with Versioning Rules

One way of dealing with the issues surrounding these rules is to re-organize them so as to move away from a single set of minor versioning rules, while adapting them to the evolving versioning model in [NFSv4-vers].

Although the result may not have the format of a numbered list of rules, there will be sets of guidelines that serve the function. One possible organization is the following:

Depending on the decisions the working group makes, some of the above rule categories may not exist.

10. Security Considerations

Since no substantive protocol changes are proposed here, no security considerations apply.

As features and minor versions designed and specified in standards-track documents, their security issues will be addressed and each RFC candidate will receive the appropriate security review from the NFSv4 working group and IESG.

11. IANA Considerations

The current document does not require any actions by IANA.

Depending on decisions that the working group makes about how to address the issues raised in this document, future documents may require actions by IANA.

12. References

12.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

12.2. Informative References

[NFSv4-vers] Haynes, T. and D. Noveck, "NFSv4 Version Management", November 2014.

Work in progress.

[NFSv42] Haynes, T., "NFS Version 4 Minor Version 2", March 2015.

Work in progress.

[NFSv42-dotx] Haynes, T., "NFS Version 4 Minor Version 2 External Data Representation Standard (XDR) Description", March 2015.

Work in progress.

[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC1094] Nowicki, B., "NFS: Network File System Protocol specification", RFC 1094, March 1989.
[RFC1813] Callaghan, B., Pawlowski, B. and P. Staubach, "NFS Version 3 Protocol Specification", RFC 1813, June 1995.
[RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers", BCP 37, RFC 2780, March 2000.
[RFC3010] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame, C., Eisler, M. and D. Noveck, "NFS version 4 Protocol", RFC 3010, December 2000.
[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, April 2003.
[RFC3530bis] Haynes, T. and D. Noveck, "Network File System (NFS) Version 4 Protocol", December 2014.

Work in progress.

[RFC3530bis-dotx] Haynes, T. and D. Noveck, "Network File System (NFS) Version 4 Protocol External Data Representation Standard (XDR) Description", December 2014.

Work in progress.

[RFC5661] Shepler, S., Eisler, M. and D. Noveck, "Network File System (NFS) Version 4 Minor Version 1 Protocol", RFC 5661, January 2010.
[RFC5662] Shepler, S., Eisler, M. and D. Noveck, "Network File System (NFS) Version 4 Minor Version 1 External Data Representation Standard (XDR) Description", RFC 5662, January 2010.

Appendix A. Acknowledgements

The author wishes to thank Chuck Lever of Oracle for his helpful document review and many important suggestions.

Author's Address

David Noveck Dell 300 Innovative Way Nashua, NH 03062 US Phone: +1 781 572 8038 EMail: davenoveck@gmail.com