Extended Experimental Path Attributes for BGP
draft-haas-idr-extended-experimental-00

Abstract

BGP's primary feature extension mechanism, Optional-Transitive Path Attributes, has proven to be a successful mechanism to permit BGP to be extended. In order to ease various issues during the development of new BGP features, this document proposes an extended experimental path attribute to carry prototype features.

Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in [RFC2119] only when they appear in all upper case. They may also appear in lower or mixed case as English words, without normative meaning.

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 May 3, 2017.

Copyright Notice

Copyright (c) 2016 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
• 2. Extended Experimental Path Attribute
• 3. Usage
• 4. Error Handling
• 5. Moving to an Allocated Code Point
• 6. Security Considerations
• 7. IANA Considerations
• 8. References
• 8.1. Normative References
• 8.2. Informative References
• Appendix A. Comparisons to Other Features
• Author's Address

1. Introduction

BGP's [RFC4271] primary feature extension mechanism, Optional-Transitive Path Attributes, has proven to be a successful mechanism to permit BGP to be extended. It permits implementations to propagate unknown Path Attributes without understanding their contents, so long as they are syntactically valid.

Path Attributes are encoded in BGP UPDATE messages using a single octet. While this code point space is relatively small, the rate at which new BGP features are introduced has proven to be slow enough that the potential for exhaustion is not a significant concern more than twenty years into the deployment of BGP-4. This code point space is managed by IANA under the Standards Action policy [RFC5226], one of the more restrictive policies in IETF's repertoire. Early allocation [RFC7120] provides some latitude for allocation of these code points compared to the original RFC 5226 policy, but is reserved for features that are considered appropriately stable.

Development work on the BGP protocol often requires a code point be assigned to a feature in progress. While code point 255 has been reserved to be Experimental, developers will often face collisions when attempting to do development on more than a single in-progress feature. Once the feature has reached a level of stability, early allocation should be strongly pursued. It may take some time, however, for features to reach that level of stability.

Due to the general difficulty of getting a public code point during the development process, code point "squatting" (use of a code point that has not been officially allocated) is unfortunately common. In many cases, this is done completely internally and has no impact on the Internet. But sometimes accidents happen and pre-release features ship. Prior to the deployment of the Revised BGP Error Handling Procedures [RFC7606], this could often be disastrous as different features, or different versions of the same feature, collided with each other and were interpreted as syntax errors and caused BGP peering sessions to reset per RFC 4271 error handling procedures. While it is less disastrous for such collisions to happen in terms of stability of the Internet, what's needed is a way for BGP protocol development to proceed with a little more safety.

This document proposes a new BGP Path Attribute, the BGP Extended Experimental Path Attribute. This Attribute is intended to be used solely for BGP Protocol development and is not intended to replace the allocation policies for the BGP Protocol.

2. Extended Experimental Path Attribute

The Extended Experimental Path Attribute is an Optional-Transitive Path Attribute with a code of TBD. Its contents are a series of TLVs in the following format:

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Implementor IANA Private Enterprise Number (4 octets)     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Implementor Feature Code Point Number (4 octets)        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Version Number (2 octets)   |  Feature Length (2 octets)    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Feature Data (0 or more octets)                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            

• Implementor IANA Private Enterprise Number is a Private Enterprise Number (PEN) assigned by IANA. [IANA-PEN]
• Feature Code Point Number is a code point space under the control of the holder of the PEN.
• Feature Version is unsigned number intended to convey the version of the feature covered by the Feature Code Point Number for the implementor. Implementors are encouraged to sequentially number versions of their feature beginning at 1.
• Feature Length is the length of this TLV. It MUST be at least 12 octets.
• Feature Data will be encoded as a BGP Path Attribute value for the experimental feature.

3. Usage

A BGP implementor intending to introduce a new standards oriented Path Attribute will select a code point number for their new Path Attribute and assign an initial Version Number. Whenever the format of the feature needs to change, the Version Number MUST also change. This prevents implementations understanding different versions of a pre-standards feature from improperly parsing the attribute.

BGP Experimental features MUST require explicit configuration to recognize a specific Feature Code Point Number, for a given Version Number, for a given PEN. If such configuration is not present, the TLV MUST be ignored.

BGP Experimental features SHOULD NOT carry more than one Version Number of the same Feature Code Point in a given UPDATE. Implementations are encouraged to strip inconsistent Version Numbered TLVs for a given feature when appropriate. For example, if the BGP speaker is configured to support Version Number 2 of an experimental feature, it may discard all TLVs for the Feature Code Point Number that are not 2.

BGP implementations supporting the Extended Experimental Path Attribute SHOULD strip this attribute by default on external BGP sessions. Explicit configuration SHOULD be required to permit a given PEN+FCPN+VN tuple into the network.

4. Error Handling

If the Extended Experimental Path Attribute is determined to be syntactically invalid, the Attribute discard behavior from [RFC7606] MUST be used.

5. Moving to an Allocated Code Point

Once an evolving BGP protocol feature reaches a reasonable level of stability, implementations MUST move to a Path Attribute Code Point allocated using the IETF sanctioned procedures. Implementors that publish their PEN+FCN+VN allocations for a given version of their feature in progress are recommended to publish this binding as part of their allocation request to enable short term backward compatibility with their experimental work.

While it is possible for implementations of a new feature to rely on experimental deployment for some time, the procedures noted in Section 3 are intended to discourage this behavior by making inter-domain distribution of the experiment fail by default.

6. Security Considerations

This document does not introduce any new security considerations into the BGP-4 protocol. While the injection of unknown or badly formatted Optional-Transitive Path Attributes has been and remains an issue impacting the stability of the Internet, this proposal doesn't increase exposure to that issue. It is rather expected that this proposal helps remediate the accidental attack surface that incremental BGP protocol work exposes to the Internet at large.

7. IANA Considerations

This document is primarily about issues related to IANA Considerations. At some point, IANA will be requested to assign a BGP Path Attribute Code number, referenced as TBD early in the document.

8. References

8.1. Normative References

8.2. Informative References

Appendix A. Comparisons to Other Features

Astute readers will note that this is not the first time BGP Path Attributes have been "tunneled" inside of other Path Attributes. [RFC6368] provided a mechanism by which an entire set of Path Attributes could be tunneled inside of attribute 128 for purposes of transparently passing received BGP Path Attributes in an Internet Layer 3 VPN context from one Customer Edge (CE) router to another.

[RFC6368] suffered from two issues:

1. During its initial development, 4-byte AS numbers were starting to be deployed. This lead to a change in the packet format of the feature to accommodate the 4-byte ASes instead of the previous 2-byte versions.
2. While this feature was intended solely to be used in a VPN context, implementations that did not understand it similarly did not strip it. This caused the VPN routes to carry attribute 128 in an Internet context after they were delivered to the target CE router.

Due to these two issues, routes containing one version of this feature that "escaped into the wild" eventually to be received by other BGP speakers supporting a different version of the feature. Each version would treat their opposite's encoding as a syntax error. This resulted in BGP peering sessions being reset. This, and other similar issues, was a motivation for [RFC6368].

The second issue noted above is the motivation for [I-D.ietf-idr-bgp-attribute-announcement].

Author's Address