MPLS-TP: 一场ITU和IETF的战争

啸傲江湖

ITU的SDH/Sonet技术发展遇到了瓶颈，不能满足日益增长的数据业务需求了，于是自然而然的想到找一个取代技术。而ethernet, IP/MPLS发展得如火如荼，各种新技术层出不穷，可惜，很多地方不适合做电信级传输网，于是ITU就想到对MPLS进行改良，用改良后的MPLS来做packet transport network，这就是T-MPLS。
可是ITU没料到的是，由于T-MPLS对MPLS的改动有点伤筋动骨，导致了跟MPLS的不兼容，触及到了IETF MPLS阵营的核心利益，就好像我辛辛苦苦搞了一个发明专利出来，你一声不响的拿过去，改头换面，准备推广赚钱，我自然是不答应。结果就是T-MPLS还没大面积推广，就受到了IETF的强烈抵制。于是在争持与妥协中，ITU和IETF联合工作组MEAD成立了，MPLS-TP诞生。
联合工作组MEAD中，IETF占据了强势主导地位。制定标准的过程中也不忘了利用自己的特权攻击一下ITU，RFC5704把这种行径暴露无疑，我电脑上的RFC 5704我给它还取了一个后缀，整个文件全名是RFC 5704---扯皮.txt,其实不是扯皮，是IETF攻击ITU.现摘抄几段：
2.4章我把它称为“争权”
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 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].
   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.
2.5章我把它称为“隐式攻击“
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.
3.1章我把它称为”显式攻击”
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.