Network Working Group S. Bryant, Ed.
Request for Comments: 5704 M. Morrow, Ed.
Category: Informational For the IAB
November 2009
Network Working Group S. Bryant, Ed.
Request for Comments: 5704 M. Morrow, Ed.
Category: Informational For the IAB
November 2009
Uncoordinated Protocol Development Considered Harmful
不协调的协议制定被认为是有害的
Abstract
摘要
This document identifies problems that may result from the absence of formal coordination and joint development on protocols of mutual interest between standards development organizations (SDOs). Some of these problems may cause significant harm to the Internet. The document suggests that a robust procedure is required prevent this from occurring in the future. The IAB has selected a number of case studies, such as Transport MPLS (T-MPLS), as recent examples to describe the hazard to the Internet architecture that results from uncoordinated adaptation of a protocol.
本文件确定了由于标准开发组织（SDO）之间缺乏正式协调和共同开发协议而可能导致的问题。其中一些问题可能对互联网造成重大危害。该文件建议，需要一个强有力的程序来防止将来发生这种情况。IAB选择了一些案例研究，例如传输MPLS（T-MPLS），作为最近的例子来描述协议不协调适应对互联网体系结构造成的危害。
This experience has resulted in a considerable improvement in the relationship between the IETF and the ITU-T. In particular, this was achieved via the establishment of the "Joint working team on MPLS-TP". In addition, the leadership of the two organizations agreed to improve inter-organizational working practices so as to avoid conflict in the future between ITU-T Recommendations and IETF RFCs.
这一经验使IETF和ITU-T之间的关系有了相当大的改善。特别是，这是通过建立“MPLS-TP联合工作组”实现的。此外，这两个组织的领导层同意改进组织间的工作做法，以避免将来ITU-T建议与IETF RFC之间的冲突。
Whilst we use ITU-T - IETF interactions in these case studies, the scope of the document extends to all SDOs that have an overlapping protocol interest with the IETF.
虽然我们在这些案例研究中使用了ITU-T-IETF交互，但本文件的范围扩展到与IETF有重叠协议利益的所有SDO。
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 IETF信托基金和确定为文件作者的人员。版权所有。
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
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您在以下方面的权利和限制：
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 BSD License.
请参阅本文件。从本文件中提取的代码组件必须包括《信托法律条款》第4.e节中所述的简化BSD许可文本，并且提供BSD许可中所述的代码组件时不提供任何担保。
Table of Contents
目录
1. Introduction ....................................................2
2. Protocol Design Rules ...........................................3
2.1. Protocol Safety ............................................3
2.2. Importance of Invariants ...................................4
2.3. Importance of Correct Identification .......................4
2.4. The Role of the Design Authority ...........................4
2.5. Ships in the Night .........................................5
3. Examples of Miscoordination .....................................6
3.1. T-MPLS as a Case Study .....................................6
3.2. PPP over SONET/SDH (Synchronous Optical Network /
Synchronous Digital Hierarchy ..............................6
4. Managing Information Flow .......................................7
4.1. Managing Information Flow within an SDO ....................7
4.2. Managing Information Flow between SDOs .....................7
5. MPLS-TP as Best Practice ........................................7
6. IETF Change Process .............................................8
7. Security Considerations .........................................8
8. Acknowledgments .................................................8
9. IAB Members at the Time of This Writing .........................8
10. Emerging Issues ................................................9
11. Conclusion .....................................................9
12. Informative References .........................................9
Appendix A. A Review of the T-MPLS Case ..........................12
A.1. Multiple Definitions of Label 14 ..........................12
A.2. Redefinition of TTL Semantics .............................13
A.3. Reservation of Additional Labels ..........................13
A.4. Redefinition of MPLS EXP Bits .............................14
A.5. The Consequences for the Network Operators ................14
A.6. The Consequences for the SDOs .............................15
1. Introduction ....................................................2
2. Protocol Design Rules ...........................................3
2.1. Protocol Safety ............................................3
2.2. Importance of Invariants ...................................4
2.3. Importance of Correct Identification .......................4
2.4. The Role of the Design Authority ...........................4
2.5. Ships in the Night .........................................5
3. Examples of Miscoordination .....................................6
3.1. T-MPLS as a Case Study .....................................6
3.2. PPP over SONET/SDH (Synchronous Optical Network /
Synchronous Digital Hierarchy ..............................6
4. Managing Information Flow .......................................7
4.1. Managing Information Flow within an SDO ....................7
4.2. Managing Information Flow between SDOs .....................7
5. MPLS-TP as Best Practice ........................................7
6. IETF Change Process .............................................8
7. Security Considerations .........................................8
8. Acknowledgments .................................................8
9. IAB Members at the Time of This Writing .........................8
10. Emerging Issues ................................................9
11. Conclusion .....................................................9
12. Informative References .........................................9
Appendix A. A Review of the T-MPLS Case ..........................12
A.1. Multiple Definitions of Label 14 ..........................12
A.2. Redefinition of TTL Semantics .............................13
A.3. Reservation of Additional Labels ..........................13
A.4. Redefinition of MPLS EXP Bits .............................14
A.5. The Consequences for the Network Operators ................14
A.6. The Consequences for the SDOs .............................15
The uncoordinated adaptation of a protocol, parameter, or code-point by a standards development organization (SDO), either through the allocation of a code-point without following the formal registration procedures or by unilaterally modifying the semantics of the protocol or intended use of the code-point itself, poses a risk of harm to the Internet [RFC4775].
标准开发组织（SDO）对协议、参数或代码点的不协调适应，通过分配代码点而不遵循正式注册程序，或通过单方面修改协议的语义或代码点本身的预期用途，对互联网造成损害的风险[RFC4775]。
The purpose of this document is to describe the various problems that may occur without formal coordination and joint development on protocols of mutual interest between SDOs. Some of the problems that arise may cause significant harm to the Internet. In particular, the IAB considers it an essential principle of the protocol development process that only one SDO maintains design authority for a given protocol, with that SDO having ultimate authority over the allocation of protocol parameter code-points and over defining the intended semantics, interpretation, and actions associated with those code-points.
本文件的目的是描述在SDO之间没有正式协调和共同制定共同利益协议的情况下可能出现的各种问题。出现的一些问题可能会对互联网造成重大危害。特别是，IAB认为协议开发过程的一个基本原则是，只有一个SDO维护给定协议的设计权限，SDO对协议参数代码点的分配和对预期语义、解释的定义具有最终权限，以及与这些代码点关联的操作。
There is currently a joint IETF - ITU-T development effort underway, known as the MPLS Transport Profile (MPLS-TP), which is progressing rapidly to extend MPLS in a way that is consistent with the MPLS architecture, and fully satisfies the requirements of the transport network provider [LS26]. By way of a case study, we will refer to the design and standardization process of the ITU-T protocol known as Transport MPLS (T-MPLS). Development of T-MPLS was abandoned [RFC5317] by ITU-T Study Group 15 due to inherent conflicts with the IETF MPLS design and, in particular, with the Internet architecture. These conflicts arose due to the lack of coordination with the IETF as the design authority for MPLS.
目前正在进行IETF-ITU-T联合开发工作，称为MPLS传输配置文件（MPLS-TP），该文件正在以与MPLS体系结构一致的方式快速扩展MPLS，并完全满足传输网络提供商的要求[LS26]。通过案例研究，我们将参考称为传输MPLS（T-MPLS）的ITU-T协议的设计和标准化过程。由于与IETF MPLS设计，特别是与互联网架构的固有冲突，ITU-T研究小组15放弃了T-MPLS的开发[RFC5317]。这些冲突是由于缺乏与作为MPLS设计机构的IETF的协调而产生的。
The goal of this document is to demonstrate the importance of a coordinated approach to successful collaboration between SDOs, and to explain a model for inter-SDO collaborative protocol development that is being used successfully by the ITU-T and IETF.
本文件的目的是证明SDO之间成功协作的协调方法的重要性，并解释ITU-T和IETF正在成功使用的SDO间协作协议开发模型。
This section describes a number of protocol design rules needed to ensure the safe operation of a network. Whilst these rules will be familiar to many protocol designers, the rules are restated here to ensure that assumptions are clear and consistent. Differing assumptions have been at the root of many miscoordinations and miscommunications between SDOs in the past.
本节介绍了确保网络安全运行所需的一些协议设计规则。虽然许多协议设计者都熟悉这些规则，但此处重申这些规则是为了确保假设清晰一致。不同的假设是过去SDO之间许多错误协调和沟通的根源。
To understand the reasons why the IAB and IETF regard uncoordinated use of code-points and/or protocol modification as posing a risk of harm to the Internet, it is necessary to recap some important principles of protocol design in large-scale networks such as the Internet. Many end users and businesses have come to rely on the Internet as part of their critical infrastructure, thus large-scale networks, such as the Internet, represent significant economic value. Any outage in a large-scale network due to a protocol failure will therefore result in significant commercial and political damage.
为了理解IAB和IETF将代码点的不协调使用和/或协议修改视为对互联网造成危害的原因，有必要重述互联网等大规模网络中协议设计的一些重要原则。许多终端用户和企业已经开始依赖互联网作为其关键基础设施的一部分，因此，互联网等大规模网络具有巨大的经济价值。因此，由于协议故障导致的大规模网络中断将导致重大的商业和政治损失。
When two incompatible protocols, or forms of the same protocol, are deployed without coordination, there is a serious risk that this may be catastrophic to the stability or security of the network.
如果在没有协调的情况下部署两个不兼容的协议或相同协议的形式，则存在严重的风险，这可能会对网络的稳定性或安全性造成灾难性的影响。
Furthermore, the scale and distributed nature of the Internet is such that it may be difficult or impossible to rid the network of the long-term consequences of the protocol incompatibility. Therefore, the following issues are of critical importance.
此外，由于互联网的规模和分布性，可能很难或不可能使网络摆脱协议不兼容的长期后果。因此，以下问题至关重要。
Invariants are core properties that are consistent across the network and do not change over extremely long time-scales. Protocol designers use such invariants as axioms in designing protocols. A protocol often places an absolute reliance on an invariant to resolve a design corner case. One example of an invariance in IP that was inherited in the design of MPLS is the invariant that a time to live (TTL) value is monotonically decreased and that a packet with TTL<=1 will not be forwarded. This is a safety mechanism to mitigate the damaging effects of packet-forwarding loops. Another example is the way that MPLS applies special semantics to the reserved label set (0..15) [RFC3032], and the notion that a Label Switched Router (LSR) is free to allocate labels with a value of 16 or greater for its own use.
不变量是在整个网络中保持一致的核心属性，并且不会在非常长的时间尺度上改变。协议设计者在设计协议时使用这些不变量作为公理。协议通常绝对依赖于不变量来解决设计角情况。在MPLS的设计中继承的IP不变性的一个例子是，生存时间（TTL）值单调减少，并且TTL≤1的分组将不会被转发。这是一种安全机制，用于减轻数据包转发循环的破坏性影响。另一个例子是MPLS对保留标签集（0..15）[RFC3032]应用特殊语义的方式，以及标签交换路由器（LSR）可以自由分配值为16或更大的标签供自己使用的概念。
A special type of invariant is the allocation of a code-point. A code-point may be used to identify a packet type or a component within a packet. Without these identifiers, a packet is an opaque sequence of bits. A packet parser operates by first identifying the code-point and then using the semantics associated with that code-point to interpret other components within the packet. Once a code-point is defined, the interpretation of associated data and the consequential actions become protocol invariants. Subsequent protocol development must adhere to those invariants. The semantics for an allocated code-point must never change. If a future enhancement requires different semantics, interpretation, or action, then a new code-point must be obtained.
一种特殊类型的不变量是代码点的分配。代码点可用于识别分组类型或分组内的组件。如果没有这些标识符，数据包就是一个不透明的位序列。数据包解析器首先识别代码点，然后使用与该代码点相关联的语义来解释数据包中的其他组件。一旦定义了一个代码点，相关数据的解释和相应的操作就成为协议不变量。随后的协议开发必须遵循这些不变量。分配的代码点的语义决不能更改。如果未来的增强需要不同的语义、解释或操作，那么必须获得新的代码点。
A code-point such as an IEEE Ethertype is allocated to a design authority such as the IETF. It is this design authority that establishes how information identified by the code-point is to be interpreted to associate appropriate invariants. Modification and extension of a protocol requires great care. In particular, it is necessary to understand the exact nature of the invariants and the
将诸如IEEE Ethertype之类的代码点分配给诸如IETF之类的设计机构。正是这种设计权威确立了如何解释由代码点标识的信息以关联适当的不变量。协议的修改和扩展需要非常小心。特别是，有必要了解不变量的确切性质和
consequences of modification. Such understanding may not always be possible when protocols are modified by organizations that don't have the experience of the original designers or the design authority expert pool. Furthermore, since there can only safely be a single interpretation of the information identified by a code-point, there must be a unique authority responsible for authorizing and documenting the semantics of the information and consequential protocol actions.
修改的后果。当没有原始设计师或设计权威专家库经验的组织修改协议时，这种理解可能并不总是可能的。此外，由于只能安全地对代码点标识的信息进行单一解释，因此必须有一个唯一的机构负责授权和记录信息的语义和相应的协议操作。
In the case of IP and MPLS technologies, the design authority is the IETF. The IETF has an internal process for evolving and maintaining the protocols for which it is the design authority. The IETF also has change processes in place [RFC4929] to work with other SDOs that require enhancements to its protocols and architectures. Similarly, the ITU-T has design authority for Recommendation E.164 [E.164] and allocates the relevant code-points, even though the IETF has design authority for the protocols ("ENUM") used to access E.164 numbers through the Internet DNS [RFC3245].
对于IP和MPLS技术，设计机构是IETF。IETF有一个内部流程，用于发展和维护其作为设计机构的协议。IETF还制定了变更流程[RFC4929]，以便与其他需要增强其协议和体系结构的SDO合作。类似地，ITU-T拥有建议E.164[E.164]的设计权限并分配相关代码点，即使IETF拥有用于通过互联网DNS[RFC3245]访问E.164号码的协议（“ENUM”）的设计权限。
It is a recommendation of this document that the IETF introduces additional change mechanisms to encompass all of the technical areas for which it has design authority.
本文件建议IETF引入额外的变更机制，以涵盖其拥有设计权限的所有技术领域。
It may be tempting for a designer to assert that the protocol extensions it proposes are safe even though it breaks the invariants of the original protocol because these protocol variants will operate as ships in the night. That is, these protocol variants will never simultaneously exist in the same network domain and will never need to inter-work. This is a fundamentally unsound assumption for a number of reasons. First, it is infeasible to ensure that the two instances will never be interconnected under any circumstances. Second, even if the operators that deploy the protocols apply appropriate due diligence to ensure that the two instances do not conflict, it is infeasible to ensure that such conflicting protocols will not be interconnected under fault conditions.
设计者可能倾向于断言它提出的协议扩展是安全的，即使它破坏了原始协议的不变量，因为这些协议变体将在夜间作为船只运行。也就是说，这些协议变体永远不会同时存在于同一网络域中，也永远不需要相互作用。这是一个根本不可靠的假设，原因有很多。首先，确保这两个实例在任何情况下都不会相互关联是不可行的。其次，即使部署协议的运营商进行适当的尽职调查以确保两个实例不冲突，也不可能确保此类冲突协议在故障条件下不会相互连接。
This assumption of ships in the night is particularly hazardous when the instances of the protocol share the same identifying code-point. This is because a system is unable to determine which variant of the protocol it has received, and hence how to correctly interpret the associated information or to determine what protocol actions may be safely executed.
当协议实例共享相同的识别代码点时，船舶在夜间的这种假设尤其危险。这是因为系统无法确定它接收到的协议变体，因此无法确定如何正确解释相关信息或确定可以安全执行哪些协议操作。
There are a variety of examples where lack of inter-SDO coordination has led to the publication of flawed protocol designs. This section describes a number of case studies that illustrate coordination issues.
有许多例子表明，SDO之间缺乏协调导致发布有缺陷的协议设计。本节介绍了一些说明协调问题的案例研究。
A recent example where another SDO created a protocol based on misunderstandings of IETF protocols is T-MPLS. T-MPLS was created in ITU-T in an attempt to design a packet-transport method for transport-oriented networks. This is an example of the success that IETF protocols have enjoyed, and ITU-T's interest and selection of MPLS is a compliment to the IETF work. Quite late in the ITU-T design and specification cycle, there were a number of liaison exchanges between the ITU-T and the IETF, where the IETF became increasingly concerned about incompatibility of IETF MPLS procedures and technologies with ITU-T T-MPLS [RFC5317]. Extensive discussions took place regarding interpretation, definition, and misunderstandings regarding aspects such as MPLS Label 14, MPLS swap operation, TTL semantics, reservation of additional labels, and EXP bits. If ITU-T had worked with IETF from the start in developing T-MPLS, these problems could have been avoided. A detailed analysis of the T-MPLS case is provided in Appendix A.
最近的一个例子是T-MPLS，其中另一个SDO基于对IETF协议的误解创建了一个协议。T-MPLS是在ITU-T中创建的，旨在为面向传输的网络设计分组传输方法。这是IETF协议取得成功的一个例子，ITU-T对MPLS的兴趣和选择是对IETF工作的补充。在ITU-T设计和规范周期的后期，ITU-T和IETF之间进行了多次联络交流，IETF越来越关注IETF MPLS程序和技术与ITU-T T-MPLS的不兼容性[RFC5317]。就MPLS标签14、MPLS交换操作、TTL语义、附加标签保留和EXP位等方面的解释、定义和误解进行了广泛的讨论。如果ITU-T从一开始就与IETF合作开发T-MPLS，这些问题本可以避免。关于T-MPLS案例的详细分析见附录A。
3.2. PPP over SONET/SDH (Synchronous Optical Network / Synchronous Digital Hierarchy)
3.2. SONET/SDH上的PPP（同步光网络/同步数字体系）
An example of where the IETF failed to coordinate with the ITU-T is [RFC1619], which defined PPP over SONET. In the text dealing with the SONET/SDH Synchronous Payload Envelope (SPE), the document erroneously stated that "no scrambling is needed during insertion into the SPE." It was later determined by SONET experts operating in the ITU-T and in ANSI that this error arose due to an incomplete understanding of the SONET scrambler. By not using a scrambler, the protocol was attempting to transport non-transparent data over SONET. This resulted in lost or misinterpreted data in the Packet over SONET (PoS) network. This impacted routing, signaling, and end-user data traffic. Details of this work are described in [PPPoSONET]. This problem would have been prevented if the IETF had worked with ITU-T and ANSI in initially developing [RFC1619] . The problem was resolved by working jointly with ITU-T and ANSI experts to publish [RFC2615], which mandated the use of scrambling.
IETF未能与ITU-T协调的一个例子是[RFC1619]，它定义了SONET上的PPP。在涉及SONET/SDH同步有效载荷包络（SPE）的文本中，该文件错误地指出“在插入SPE期间不需要加扰。”随后，在ITU-T和ANSI中运行的SONET专家确定，该错误是由于对SONET加扰器的理解不完整而产生的。通过不使用扰码器，协议试图通过SONET传输不透明数据。这导致SONET（PoS）网络上数据包中的数据丢失或误读。这会影响路由、信令和最终用户数据流量。[PPPoSONET]中描述了这项工作的细节。如果IETF在最初开发[RFC1619]时与ITU-T和ANSI合作，这个问题本可以避免。通过与ITU-T和ANSI专家合作发布[RFC2615]，强制使用加扰，问题得以解决。
Note that [RFC1619] was developed four years before the IETF and ITU-T agreed on formal procedures for cooperation, as documented in [RFC2436] (which was later obsoleted by [RFC3356]).
请注意，[RFC1619]是在IETF和ITU-T就正式合作程序达成一致之前四年开发的，如[RFC2436]所述（后来被[RFC3356]淘汰）。
This section recommends that intra- and inter-SDO information flows require careful management in order to prevent the accidental extension of protocols without complete coordination of the work with the relevant design authority.
本节建议，SDO内部和内部信息流需要仔细管理，以防止在未与相关设计机构完全协调工作的情况下意外扩展协议。
One cannot assume that an SDO is completely familiar with the internal structure, information exchange, or internal processes of another SDO. Hence, the initial contact point and the subgroup with which a long-term working relationship is formed has a duty to ensure that the work is fully notified and coordinated to all relevant parties within the SDO.
我们不能假设一个SDO完全熟悉另一个SDO的内部结构、信息交换或内部流程。因此，初始联络点和与之形成长期工作关系的小组有责任确保向SDO内的所有相关方充分通知和协调工作。
A recommendation is that, as part of their document-approval process, SDOs should confirm that all protocol parameters, code-points, TLV identifiers, etc., have been authorized by the appropriate design authority (e.g., IANA, IETF, etc. in this case) and that SDO approval from the design authority has been obtained prior to publishing protocol extensions. This confirmation should be an integral part of the approval or consent process as verifying that the normative references are qualified.
建议作为其文件批准流程的一部分，SDO应确认所有协议参数、代码点、TLV标识符等均已获得适当设计机构的授权（例如，在这种情况下，IANA、IETF等）在发布协议扩展之前，已获得设计机构的SDO批准。该确认书应作为批准或同意过程的一个组成部分，以验证规范性引用文件是否合格。
In order to bridge the gap between the two organizations, the IETF and the ITU-T established a joint working team (JWT) to assess whether it was possible to enhance existing MPLS standards to provide a best-in-class solution for transport networks. The outcome of this investigation is reported in [RFC5317].
为了弥合这两个组织之间的差距，IETF和ITU-T成立了一个联合工作组（JWT），以评估是否有可能增强现有MPLS标准，为传输网络提供一流的解决方案。[RFC5317]中报告了该调查的结果。
The JWT proposed a design that was acceptable to both SDOs. This has led to the creation of the MPLS-TP project. This is a joint project in which the ITU-T experts work with the IETF on protocol-development tasks, and IETF members work within the ITU-T to understand requirements and to assist in the creation of ITU-T recommendations that describe MPLS-TP in which the technical definition is provided through normative references to IETF RFCs.
JWT提出了一种两个SDO都能接受的设计。这导致了MPLS-TP项目的创建。这是一个联合项目，在该项目中，ITU-T专家与IETF合作完成协议开发任务，IETF成员在ITU-T内工作，以了解需求，并协助制定ITU-T建议，描述MPLS-TP，其中通过对IETF RFC的规范性引用提供技术定义。
Although the JWT approach allowed the IETF and the ITU-T to agree on a method of resolving the T-MPLS problem, this approach had a significant resource cost. The JWT required considerable protocol-design expertise and IETF management time to agree on a suitable technical solution. A lightweight process, starting with close
尽管JWT方法允许IETF和ITU-T就解决T-MPLS问题的方法达成一致，但这种方法具有巨大的资源成本。JWT需要相当多的协议设计专业知识和IETF管理时间来商定合适的技术解决方案。轻量级流程，从close开始
coordination during the requirements phase and continuing during the development phase, would likely reduce the resources needed to an acceptable level in the future.
在需求阶段进行协调，并在开发阶段继续进行协调，可能会在将来将所需资源减少到可接受的水平。
There is an MPLS-change-process [RFC4929] . However, the IETF has not yet defined a change process that is applicable to all of its work areas. The problems described in this document indicate that the IETF needs to develop a universal change process. The MPLS-change-process would seem to be a suitable starting point.
有一个MPLS更改过程[RFC4929]。然而，IETF尚未定义适用于其所有工作领域的变更过程。本文件中描述的问题表明IETF需要开发通用的变更流程。MPLS变更过程似乎是一个合适的起点。
The uncoordinated development of protocols poses a risk of harm to the Internet and must not be permitted. The enhancement or modification of a protocol can increase attack surfaces considerably and may therefore compromise the security or stability of the Internet. The IETF has a review process that combines cross-area review with specialist security review by experts familiar with the development and deployment context of the Internet protocol suite. In particular, because of the Internet infrastructure's reliance on the IP and MPLS protocol suites, this security review process must be exercised with considerable diligence. Failure to apply this review process exposes the Internet to increased risk along both security and stability vectors.
协议的不协调发展会对互联网造成危害，因此不得允许。协议的增强或修改会大大增加攻击面，因此可能危及互联网的安全性或稳定性。IETF有一个审查过程，由熟悉互联网协议套件开发和部署环境的专家进行跨领域审查和专家安全审查。特别是，由于互联网基础设施对IP和MPLS协议套件的依赖，必须认真执行此安全审查过程。未能应用此审查过程会使互联网在安全性和稳定性方面面临更大的风险。
The authors wish to acknowledge Loa Andersson for his contribution to this work.
作者希望感谢Loa Andersson对这项工作的贡献。
Marcelo Bagnulo Gonzalo Camarillo Stuart Cheshire Vijay Gill Russ Housley John Klensin Olaf Kolkman Gregory Lebovitz Andrew Malis Danny McPherson David Oran Jon Peterson Dave Thaler
马塞洛·巴格努洛·冈萨洛·卡马里洛·斯图尔特·切希尔·维杰·吉尔·罗斯·霍斯利·约翰·克莱森·奥拉夫·科尔克曼·格雷戈里·勒博维茨·安德鲁·马里·丹尼·麦克弗森·大卫·奥兰·乔恩·彼得森·戴夫·泰勒
Although we have used T-MPLS as a case study, there are other ongoing ITU-T projects and core IETF specifications that could be the subject of either improved coordination or new conflicts, depending on whether or not the principles outlined in this document are adhered to by the IETF and ITU. Two current examples are [Y.2015] and [Q.Flowsig]. New areas with potential for cooperation or conflict are emerging from the work of ITU-T SG13 Question 7, "IPv6" -- for example: [Y.ipv6split] and [Y.ipv6migration].
尽管我们使用了T-MPLS作为案例研究，但仍有其他正在进行的ITU-T项目和核心IETF规范可能成为改进协调或新冲突的主题，这取决于IETF和ITU是否遵守本文件中概述的原则。目前的两个例子是[Y.2015]和[Q.Flowsig]。在ITU-T SG13问题7“IPv6”的工作中，出现了可能存在合作或冲突的新领域，例如：[Y.ipv6split]和[Y.ipv6migration]。
Improved coordination, of course, is not limited to the relationship between IETF and ITU-T. This issue is present between a set of SDOs. The IETF - ITU-T relationship has simply been used because there is a recent example where a potential disaster was, through much hard work, not only prevented but turned into a net gain for all.
当然，改进的协调并不局限于IETF和ITU-T之间的关系。这个问题存在于一组SDO之间。之所以使用IETF-ITU-T关系，是因为最近有一个例子，通过大量的努力，一场潜在的灾难不仅得到了预防，而且变成了所有人的净收益。
It is important that all SDOs developing standards that affect the operation of the Internet learn the lessons that arise from cases cited in this document. Uncoordinated parallel work between SDOs creates significant problems with potentially damaging operation impact to those that deploy and use the Internet. Both inter- and intra-SDO information flow needs to be well managed to ensure that all impacted parties are aware of work items. Finally, the IETF needs to develop a universal change process that encompasses all of its work areas.
重要的是，所有制定影响互联网运行的标准的SDO都要从本文件中引用的案例中吸取教训。SDO之间不协调的并行工作会造成重大问题，对部署和使用互联网的人造成潜在的破坏性操作影响。SDO内部和内部的信息流都需要得到良好的管理，以确保所有受影响方都知道工作项。最后，IETF需要开发一个涵盖其所有工作领域的通用变更流程。
[E.164] ITU-T, "ITU Recommendation E.164: The international public telecommunication numbering plan", February 2005.
[E.164]ITU-T，“ITU建议E.164：国际公共电信编号计划”，2005年2月。
[LS26] ITU-T Study Group 15, "Cooperation Between IETF and ITU-T on the Development of MPLS-TP", Geneva, December 2008, <https://datatracker.ietf.org/ documents/LIAISON/file596.pdf>.
[LS26]ITU-T研究小组15，“IETF和ITU-T在MPLS-TP开发方面的合作”，日内瓦，2008年12月<https://datatracker.ietf.org/ 文件/联络/文件596.pdf>。
[PPPoSONET] Manchester, J., et al., "PPP over SONET/SDH", Work in Progress, October 1997.
[PPPoSONET]曼彻斯特，J.等人，“SONET/SDH上的PPP”，正在进行的工作，1997年10月。
[Q.Flowsig] ITU-T Study Group 11, Question 5, "Signalling protocols and procedures relating to flow state aware access QoS control in an NGN", Draft Recommendation.
[Q.Flowsig]ITU-T研究组11，问题5，“与NGN中的流状态感知接入QoS控制相关的信令协议和程序”，建议草案。
[RFC1393] Malkin, G., "Traceroute Using an IP Option", RFC 1393, January 1993.
[RFC1393]Malkin，G.“使用IP选项的跟踪路由”，RFC 1393，1993年1月。
[RFC1619] Simpson, W., "PPP over SONET/SDH", RFC 1619, May 1994.
[RFC1619]辛普森，W.“SONET/SDH上的PPP”，RFC161994年5月。
[RFC2436] Brett, R., Bradner, S., and G. Parsons, "Collaboration between ISOC/IETF and ITU-T", RFC 2436, October 1998.
[RFC2436]Brett，R.，Bradner，S.，和G.Parsons，“ISOC/IETF和ITU-T之间的合作”，RFC 2436，1998年10月。
[RFC2615] Malis, A. and W. Simpson, "PPP over SONET/SDH", RFC 2615, June 1999.
[RFC2615]Malis，A.和W.Simpson，“SONET/SDH上的PPP”，RFC 26151999年6月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031]Rosen，E.，Viswanathan，A.，和R.Callon，“多协议标签交换体系结构”，RFC 30312001年1月。
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.
[RFC3032]Rosen，E.，Tappan，D.，Fedorkow，G.，Rekhter，Y.，Farinaci，D.，Li，T.，和A.Conta，“MPLS标签堆栈编码”，RFC 3032，2001年1月。
[RFC3245] Klensin, J. and IAB, "The History and Context of Telephone Number Mapping (ENUM) Operational Decisions: Informational Documents Contributed to ITU-T Study Group 2 (SG2)", RFC 3245, March 2002.
[RFC3245]Klensin，J.和IAB，“电话号码映射（ENUM）操作决策的历史和背景：向ITU-T研究小组2（SG2）提供的信息性文件”，RFC 32452002年3月。
[RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-Protocol Label Switching (MPLS) Support of Differentiated Services", RFC 3270, May 2002.
[RFC3270]Le Faucheur，F.，Wu，L.，Davie，B.，Davari，S.，Vaananen，P.，Krishnan，R.，Cheval，P.，和J.Heinanen，“区分服务的多协议标签交换（MPLS）支持”，RFC 32702002年5月。
[RFC3356] Fishman, G. and S. Bradner, "Internet Engineering Task Force and International Telecommunication Union - Telecommunications Standardization Sector Collaboration Guidelines", RFC 3356, August 2002.
[RFC3356]Fishman，G.和S.Bradner，“互联网工程任务组和国际电信联盟-电信标准化部门协作指南”，RFC 3356，2002年8月。
[RFC3429] Ohta, H., "Assignment of the 'OAM Alert Label' for Multiprotocol Label Switching Architecture (MPLS) Operation and Maintenance (OAM) Functions", RFC 3429, November 2002.
[RFC3429]Ohta，H.，“多协议标签交换体系结构（MPLS）操作和维护（OAM）功能的‘OAM警报标签’分配”，RFC 34292002年11月。
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006.
[RFC4379]Kompella，K.和G.Swallow，“检测多协议标签交换（MPLS）数据平面故障”，RFC 4379，2006年2月。
[RFC4775] Bradner, S., Carpenter, B., and T. Narten, "Procedures for Protocol Extensions and Variations", BCP 125, RFC 4775, December 2006.
[RFC4775]Bradner，S.，Carpenter，B.，和T.Narten，“协议扩展和变更程序”，BCP 125，RFC 47752006年12月。
[RFC4929] Andersson, L. and A. Farrel, "Change Process for Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Protocols and Procedures", BCP 129, RFC 4929, June 2007.
[RFC4929]Andersson，L.和A.Farrel，“多协议标签交换（MPLS）和通用MPLS（GMPLS）协议和程序的变更过程”，BCP 129，RFC 49292007年6月。
[RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion Marking in MPLS", RFC 5129, January 2008.
[RFC5129]Davie，B.，Briscoe，B.，和J.Tay，“MPLS中的显式拥塞标记”，RFC 5129，2008年1月。
[RFC5317] Bryant, S. and L. Andersson, "Joint Working Team (JWT) Report on MPLS Architectural Considerations for a Transport Profile", RFC 5317, February 2009.
[RFC5317]Bryant，S.和L.Andersson，“联合工作组（JWT）关于传输配置文件的MPLS体系结构考虑的报告”，RFC 53172009年2月。
[RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic Class" Field", RFC 5462, February 2009.
[RFC5462]Andersson，L.和R.Asati，“多协议标签交换（MPLS）标签堆栈条目：“EXP”字段重命名为“流量类”字段”，RFC 5462，2009年2月。
[RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and S. Ueno, "Requirements of an MPLS Transport Profile", RFC 5654, September 2009.
[RFC5654]Niven Jenkins，B.，Brungard，D.，Betts，M.，Sprecher，N.，和S.Ueno，“MPLS传输配置文件的要求”，RFC 56542009年9月。
[Y.1711-2002] ITU-T Study Group 13, "ITU-T Recommendation Y.1711: OAM mechanism for MPLS networks", November 2002.
[Y.1711-2002]ITU-T研究小组13，“ITU-T建议Y.1711：MPLS网络的OAM机制”，2002年11月。
[Y.1711-2004] ITU-T Study Group 13, "ITU-T Recommendation Y.1711: OAM mechanism for MPLS networks", February 2004.
[Y.1711-2004]ITU-T研究小组13，“ITU-T建议Y.1711：MPLS网络的OAM机制”，2004年2月。
[Y.1711am1] ITU-T Study Group 13, "ITU-T Recommendation Y.1711 Amendment 1: New Function Type Codes", October 2005.
[Y.1711am1]ITU-T研究小组13，“ITU-T建议Y.1711修改件1：新功能类型代码”，2005年10月。
[Y.1711cor1] ITU-T Study Group 13, "ITU-T Recommendation Y.1711 (2004) corrigendum 1", February 2005.
[Y.1711cor1]ITU-T研究小组13，“ITU-T建议Y.1711（2004）勘误表1”，2005年2月。
[Y.2015] ITU-T Study Group 13, Question 5, "General Requirements for ID/Locator Separation in NGN".
[Y.2015]ITU-T研究小组13，问题5，“NGN中ID/定位器分离的一般要求”。
[Y.ipv6migration] ITU-T, "ITU draft Y.ipv6migration: Roadmap for IPv6 migration from NGN operators perspective", 2009.
[Y.IPv6迁移]ITU-T，“ITU草案Y.IPv6迁移：从NGN运营商角度看IPv6迁移路线图”，2009年。
[Y.ipv6split] ITU-T, "ITU draft Y.ipv6split: Framework of ID/LOC separation in IPv6-based NGN", 2009.
[Y.ipv6split]ITU-T，“ITU草案Y.ipv6split：基于IPv6的NGN中的ID/LOC分离框架”，2009年。
T-MPLS was created in ITU-T in an attempt to design an MPLS-based packet-transport method for transport-oriented networks. This appendix describes the technical issues that the IETF identified with the T-MPLS documents and their consequences.
T-MPLS是在ITU-T中创建的，旨在为面向传输的网络设计一种基于MPLS的分组传输方法。本附录描述了IETF在T-MPLS文件中确定的技术问题及其后果。
To appreciate why the use of MPLS Reserved Label 14 by the T-MPLS protocol represented a safety concern to the Internet, it is important to understand the current standards that use MPLS Reserved Label 14.
为了理解为什么T-MPLS协议使用MPLS保留标签14代表了互联网的安全问题，理解使用MPLS保留标签14的当前标准很重要。
The governing standard on the use of MPLS Reserved Label 14 is [RFC3429], "Assignment of the 'OAM Alert Label' for Multiprotocol Label Switching Architecture (MPLS) Operation and Maintenance (OAM) Functions".
MPLS保留标签14的使用管理标准为[RFC3429]，“多协议标签交换体系结构（MPLS）操作和维护（OAM）功能的‘OAM警报标签’分配”。
Label 14 is assigned to a specific protocol, namely, ITU-T Recommendation [Y.1711-2002].
标签14分配给特定协议，即ITU-T建议[Y.1711-2002]。
ITU-T Recommendation [Y.1711-2002] has been superseded by newer versions, specifically: [Y.1711-2004], [Y.1711cor1], and [Y.1711am1].
ITU-T建议[Y.1711-2002]已被较新版本取代，具体为：[Y.1711-2004]、[Y.1711cor1]和[Y.1711am1]。
All three documents are currently in force as ITU-T Recommendations.
这三份文件目前都作为ITU-T建议生效。
The problem is that the changes made to Y.1711 were never reflected in an update to RFC 3429, which only defines the protocol as specified by the now superseded 2002 Recommendation. So for example, MPLS equipment responding to an MPLS packet containing Label 14 would expect to see the 2002 version of the Y.1711 [Y.1711-2002] protocol and would not recognize any of the new function codes specified in Y.1711 Amendment 1. This problem arises because Y.1711 does not have a version field, and RFC 3429 offers no other method to disambiguate non-interoperable versions of Y.1711. Having a version number in the protocol permits an implementer to codify non-interoperability. Furthermore, the IETF as the authority over Label 14 semantics has the final say over maintaining the interoperability of the protocol employing that code-point, unless the IETF explicitly delegates such authority.
问题在于，对Y.1711所做的更改从未反映在RFC 3429的更新中，RFC 3429仅定义了现已被取代的2002年建议中规定的协议。因此，例如，响应包含标签14的MPLS数据包的MPLS设备将期望看到2002年版本的Y.1711[Y.1711-2002]协议，并且不会识别Y.1711修改件1中指定的任何新功能代码。出现此问题是因为Y.1711没有版本字段，并且RFC 3429没有提供其他方法来消除Y.1711的不可互操作版本的歧义。协议中有一个版本号允许实现者对非互操作性进行编码。此外，IETF作为标签14语义的权威，对使用该代码点的协议的互操作性具有最终决定权，除非IETF明确授权。
With regard to T-MPLS, there was a lack of coordination between the ITU-T and the IETF over the redefinition of the semantics of MPLS Label 14, which resulted in protocol definitions that conflicted with the IETF MPLS architecture.
关于T-MPLS，在重新定义MPLS标签14的语义方面，ITU-T和IETF之间缺乏协调，这导致协议定义与IETF MPLS体系结构冲突。
The MPLS architecture [RFC3031], defines a swap operation as an atomic function that replaces the top label in an MPLS label stack with another label, which provides context for the next hop LSR. However, the ITU-T Recommendations that specified the new OAM functions defined by Label 14 redefined the label-swap operation as a POP, followed by a PUSH, thereby causing all LSRs to inspect the label stack for the presence of Label 14 at each hop. This proposed new behaviour conflicts with the IETF definition of a swap operation.
MPLS体系结构[RFC3031]将交换操作定义为一个原子函数，用另一个标签替换MPLS标签堆栈中的顶部标签，该标签为下一跳LSR提供上下文。然而，ITU-T建议指定标签14定义的新OAM功能，将标签交换操作重新定义为POP，然后是推送，从而使所有LSR在每个跃点检查标签堆栈是否存在标签14。这一提议的新行为与IETF对交换操作的定义相冲突。
The behaviour proposed in these specifications would have had major consequences for deployed hardware designs. The outcome would have been that the equipments built according to the two different specifications would have been incompatible. It is important that the atomic procedure defined in [RFC3031] is kept unchanged.
这些规范中提出的行为将对部署的硬件设计产生重大影响。结果是，根据两种不同规格制造的设备不兼容。[RFC3031]中定义的原子程序必须保持不变。
The standard method of delivering an OAM message to an entity on a Label Switched Path (LSP), such that the OAM message shares its fate with the data traffic, is to use TTL expiry. The IETF's Internet Protocol (IP) utilizes this mechanism for traceroute [RFC1393], as does MPLS ping [RFC4379].
将OAM消息传递给标签交换路径（LSP）上的实体，以使OAM消息与数据通信共享其命运的标准方法是使用TTL到期。IETF的互联网协议（IP）将此机制用于跟踪路由[RFC1393]，MPLS ping[RFC4379]也是如此。
At one stage, the T-MPLS designers considered a multi-level OAM design in which the OAM packet was steered to its target by a process in which some nodes increased the TTL as they forwarded the OAM packet to its next hop. TTL is a safety device in the IETF IP and MPLS architecture that prevents a packet from continuously looping under fault conditions. Thus, the proposed extension to support an enhanced OAM mechanism violated an MPLS design invariant specifically introduced to ensure safe operation of the Internet by preventing persistent forwarding loops.
在一个阶段，T-MPLS设计者考虑了多级OAM设计，其中OAM分组通过一个过程被引导到其目标，在该过程中，一些节点在将OAM分组转发到其下一跳时增加TTL。TTL是IETF IP和MPLS体系结构中的一种安全设备，可防止数据包在故障条件下连续循环。因此，所提议的支持增强OAM机制的扩展违反了专门引入的MPLS设计不变量，该不变量通过防止持久转发循环来确保互联网的安全运行。
The IETF MPLS protocol uses a small number of reserved labels [RFC3032] as a mechanism to provide additional context and to trigger some special processing operations in the forwarder. All other labels used for forwarding use semantics defined by the forwarding equivalence class (FEC). In an early implementation of T-MPLS, the designers determined that they needed some additional labels to alert the forwarder that the packet needed special processing. Thus, a conflict was thereby introduced between the behaviour of an IETF MPLS LSR and LSRs that operate according to the specification in the ITU-T Recommendation. Thus, some LSRs would attribute special semantics to Labels 16..31, whilst other LSRs would perform normal forwarding on them.
IETF MPLS协议使用少量保留标签[RFC3032]作为一种机制，以提供额外的上下文并触发转发器中的一些特殊处理操作。用于转发的所有其他标签使用转发等价类（FEC）定义的语义。在T-MPLS的早期实现中，设计者确定他们需要一些额外的标签来提醒转发器数据包需要特殊处理。因此，IETF MPLS LSR的行为与根据ITU-T建议中的规范运行的LSR之间产生了冲突。因此，一些LSR会将特殊语义赋予标签16..31，而其他LSR会对其执行正常转发。
The early MPLS documents defined the form of the MPLS label stack entry [RFC3032]. This includes a three-bit field called the "EXP field". The exact use of this field was not defined by these documents, except to state that it was to be "reserved for experimental use".
早期的MPLS文档定义了MPLS标签堆栈项的形式[RFC3032]。这包括一个称为“EXP字段”的三位字段。这些文件并未对该领域的确切用途进行定义，只是说明该领域将“保留供实验使用”。
Although the intended use of the EXP field was as a "Class of Service" (CoS) field, it was not named a CoS field by these early documents because the use of such a CoS field was not considered to be sufficiently defined. Today, a number of standards documents define its usage as a CoS field ([RFC3270], [RFC5129]), and hardware is deployed that assumes this exclusive usage.
尽管EXP字段的预期用途是作为“服务类别”（CoS）字段，但这些早期文档并未将其命名为CoS字段，因为此类CoS字段的使用未被充分定义。今天，许多标准文档将其用法定义为CoS字段（[RFC3270]、[RFC5129]），并且部署的硬件假定了这种独占用法。
The T-MPLS designers, unaware of the historic reason for the "provisional" naming of this field, assumed that they were available for any experimental use and re-purposed them to indicate the maintenance-entity level (a hierarchical maintenance mechanism).
T-MPLS设计人员不知道该字段“临时”命名的历史原因，他们假设这些字段可用于任何实验用途，并将其重新用于指示维护实体级别（分层维护机制）。
The intended use of the EXP field was subsequently carried in [RFC5462], which reinforces this use by formally changing the name to Traffic Class (TC).
EXP字段的预期用途随后在[RFC5462]中进行了说明，通过将名称正式更改为Traffic Class（TC），强化了该用途。
Transport network operators need a way to realize the statistical gain inherent in packet networking while retaining the familiar operational structure of their SONET/SDH networks. T-MPLS was an attempt to provide that functionality. However, creating an incompatible variant of MPLS without tight coordination with IETF created a number of problems for network operators.
传输网络运营商需要一种方法来实现分组网络固有的统计增益，同时保留其SONET/SDH网络熟悉的操作结构。T-MPLS试图提供这种功能。然而，在没有与IETF密切协调的情况下创建不兼容的MPLS变体，给网络运营商带来了许多问题。
Firstly, those operators that deployed T-MPLS in production networks will need to address the risk and complexity of transitioning their network to MPLS-TP. Secondly, there has been a consequential delay of the necessary enhancements to MPLS to meet their needs [RFC5654] as the IETF and ITU-T executed a redevelopment of MPLS-based transport network protocols.
首先，在生产网络中部署T-MPLS的运营商需要解决将其网络过渡到MPLS-TP的风险和复杂性。其次，随着IETF和ITU-T对基于MPLS的传输网络协议进行重新开发，为满足其需求而对MPLS进行的必要增强[RFC5654]也随之延迟。
Fortunately, the two organizations are now working together to design the necessary enhancements
幸运的是，这两个组织现在正在合作设计必要的增强功能
The resulting technology, MPLS-TP, brings significant benefits to all. However, this has not been without cost. Had things continued, we are not sure what would have happened -- at the least, the larger
由此产生的技术MPLS-TP为所有人带来了巨大的好处。然而，这并非没有成本。如果事情继续下去，我们不确定会发生什么——至少，更大的事情会发生
MPLS community would have been denied the benefit of better OAM, and the transport community would have been denied the many benefits of an interoperable solution.
MPLS社区将无法获得更好的OAM带来的好处，而传输社区将无法获得互操作解决方案带来的诸多好处。
The process of resolution required considerable resources and introduced a great deal of conflict between the IETF and the ITU-T, much of which was exposed to public scrutiny, to the detriment of both organizations. In particular, this conflict-resolution process consumed the very resources required to develop an optimal architecture for MPLS in transport networks.
解决过程需要大量资源，并在IETF和ITU-T之间引入了大量冲突，其中大部分受到公众监督，对两个组织都不利。特别是，这种冲突解决过程消耗了为传输网络中的MPLS开发最佳体系结构所需的资源。
Authors' Addresses
作者地址
Stewart Bryant (editor)
斯图尔特·布莱恩特（编辑）
EMail: stbryant@cisco.com
EMail: stbryant@cisco.com
Monique Morrow (editor)
莫妮克·莫罗（编辑）
EMail: mmorrow@cisco.com
EMail: mmorrow@cisco.com
Internet Architecture Board
互联网架构委员会
EMail: iab@iab.org
EMail: iab@iab.org