Internet Engineering Task Force (IETF) S. Bryant
Request for Comments: 8469 A. Malis
Updates: 4448 Huawei
Category: Standards Track I. Bagdonas
ISSN: 2070-1721 Equinix
November 2018
Internet Engineering Task Force (IETF) S. Bryant
Request for Comments: 8469 A. Malis
Updates: 4448 Huawei
Category: Standards Track I. Bagdonas
ISSN: 2070-1721 Equinix
November 2018
Recommendation to Use the Ethernet Control Word
建议使用以太网控制字
Abstract
摘要
The pseudowire (PW) encapsulation of Ethernet, as defined in RFC 4448, specifies that the use of the control word (CW) is optional. In the absence of the CW, an Ethernet PW packet can be misidentified as an IP packet by a label switching router (LSR). This may lead to the selection of the wrong equal-cost multipath (ECMP) path for the packet, leading in turn to the misordering of packets. This problem has become more serious due to the deployment of equipment with Ethernet Media Access Control (MAC) addresses that start with 0x4 or 0x6. The use of the Ethernet PW CW addresses this problem. This document RECOMMENDS the use of the Ethernet PW CW in all but exceptional circumstances.
RFC 4448中定义的以太网的伪线（PW）封装指定控制字（CW）的使用是可选的。在没有CW的情况下，标签交换路由器（LSR）可以将以太网PW分组错误地识别为IP分组。这可能会导致为数据包选择错误的等成本多路径（ECMP）路径，进而导致数据包顺序错误。由于部署了以太网媒体访问控制（MAC）地址以0x4或0x6开头的设备，此问题变得更加严重。以太网PW CW的使用解决了这个问题。本文件建议在除特殊情况外的所有情况下使用以太网PW CW。
This document updates RFC 4448.
本文档更新了RFC 4448。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8469.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8469.
Copyright Notice
版权公告
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2018 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
2. Specification of Requirements ...................................3
3. Background ......................................................4
4. Recommendation ..................................................5
5. Equal-Cost Multipath (ECMP) .....................................5
6. Mitigations .....................................................6
7. Operational Considerations ......................................6
8. Security Considerations .........................................7
9. IANA Considerations .............................................7
10. References .....................................................7
10.1. Normative References ......................................7
10.2. Informative References ....................................8
Acknowledgments ....................................................9
Authors' Addresses .................................................9
1. Introduction ....................................................3
2. Specification of Requirements ...................................3
3. Background ......................................................4
4. Recommendation ..................................................5
5. Equal-Cost Multipath (ECMP) .....................................5
6. Mitigations .....................................................6
7. Operational Considerations ......................................6
8. Security Considerations .........................................7
9. IANA Considerations .............................................7
10. References .....................................................7
10.1. Normative References ......................................7
10.2. Informative References ....................................8
Acknowledgments ....................................................9
Authors' Addresses .................................................9
The pseudowire (PW) encapsulation of Ethernet, as defined in [RFC4448], specifies that the use of the control word (CW) is optional. It is common for label switching routers (LSRs) to search past the end of the label stack to determine whether the payload is an IP packet and then, if it is, select the next hop based on the so-called "five-tuple" (IP source address, IP destination address, protocol/next-header, transport-layer source port, and transport-layer destination port). In the absence of a PW CW, an Ethernet PW packet can be misidentified as an IP packet by a label switching router (LSR) selecting the ECMP path based on the five-tuple. This may lead to the selection of the wrong ECMP path for the packet, leading in turn to the misordering of packets. Further discussion of this topic is published in [RFC4928].
[RFC4448]中定义的以太网伪线（PW）封装规定，控制字（CW）的使用是可选的。标签交换路由器（LSR）通常会搜索标签堆栈的末尾，以确定有效负载是否为IP数据包，如果是，则根据所谓的“五元组”（IP源地址、IP目的地地址、协议/下一报头、传输层源端口和传输层目的地端口）选择下一跳。在没有PW-CW的情况下，标签交换路由器（LSR）可以基于五元组选择ECMP路径，从而将以太网PW分组错误地识别为IP分组。这可能导致为数据包选择错误的ECMP路径，进而导致数据包顺序错误。关于该主题的进一步讨论发表在[RFC4928]中。
Flow misordering can also happen in a single-path scenario when traffic classification and differential forwarding treatment mechanisms are in use. These errors occur when a forwarder incorrectly assumes that the packet is IP and applies a forwarding policy based on fields in the PW payload.
当使用流量分类和差异转发处理机制时，在单路径场景中也可能发生流错序。当转发器错误地假设数据包是IP并基于PW有效负载中的字段应用转发策略时，就会发生这些错误。
IPv4 and IPv6 packets start with the values 0x4 and 0x6, respectively. Misidentification can arise if an Ethernet PW packet without a CW is carrying an Ethernet packet with a destination address that starts with either of these values.
IPv4和IPv6数据包分别以值0x4和0x6开头。如果没有CW的Ethernet PW数据包携带的Ethernet数据包的目标地址以其中任何一个值开头，则可能会出现错误识别。
This problem has recently become more serious for a number of reasons. First, the IEEE Registration Authority Committee (RAC) has assigned Ethernet MAC addresses that start with 0x4 or 0x6, and equipment that uses MAC addresses in these series has been deployed in networks. Second, concerns over privacy have led to the use of MAC address randomization, which assigns local MAC addresses randomly for privacy. Random assignment results in addresses starting with one of these two values approximately one time in eight.
由于一些原因，这个问题最近变得更加严重。首先，IEEE注册管理委员会（RAC）分配了以0x4或0x6开头的以太网MAC地址，并且在这些系列中使用MAC地址的设备已部署在网络中。其次，对隐私的担忧导致了MAC地址随机化的使用，即随机分配本地MAC地址以保护隐私。随机分配会导致地址以这两个值中的一个开始，大约八分之一的时间。
The use of the Ethernet PW CW addresses this problem.
以太网PW CW的使用解决了这个问题。
This document RECOMMENDS the use of the Ethernet PW CW in all but exceptional circumstances.
本文件建议在除特殊情况外的所有情况下使用以太网PW CW。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
Ethernet PW encapsulation is specified in [RFC4448]. Of particular relevance is Section 4.6, part of which is quoted below for the convenience of the reader. Note that RFC 4448 uses the citation [PWE3-CW] to refer to [RFC4385] and the citation [VCCV] to refer to the document that was eventually published as [RFC5085].
[RFC4448]中规定了以太网PW封装。特别相关的是第4.6节，为了方便读者，下文引用了部分内容。请注意，RFC 4448使用引文[PWE3-CW]引用[RFC4385]，并使用引文[VCCV]引用最终发布为[RFC5085]的文件。
The control word defined in this section is based on the Generic PW MPLS Control Word as defined in [PWE3-CW]. It provides the ability to sequence individual frames on the PW, avoidance of equal-cost multiple-path load-balancing (ECMP) [RFC2992], and Operations and Management (OAM) mechanisms including VCCV [VCCV].
本节中定义的控制字基于[PWE3-CW]中定义的通用PW MPLS控制字。它提供对PW上的各个帧进行排序的能力，避免等成本多路径负载平衡（ECMP）[RFC2992]，以及包括VCCV[VCCV]在内的操作和管理（OAM）机制。
[PWE3-CW] states, "If a PW is sensitive to packet misordering and is being carried over an MPLS PSN that uses the contents of the MPLS payload to select the ECMP path, it MUST employ a mechanism which prevents packet misordering." This is necessary because ECMP implementations may examine the first nibble after the MPLS label stack to determine whether the labeled packet is IP or not. Thus, if the source MAC address of an Ethernet frame carried over the PW without a control word present begins with 0x4 or 0x6, it could be mistaken for an IPv4 or IPv6 packet. This could, depending on the configuration and topology of the MPLS network, lead to a situation where all packets for a given PW do not follow the same path. This may increase out-of-order frames on a given PW, or cause OAM packets to follow a different path than actual traffic (see Section 4.4.3, "Frame Ordering").
[PWE3-CW]指出，“如果PW对数据包错序非常敏感，并且正在通过使用MPLS有效载荷的内容来选择ECMP路径的MPLS PSN进行传输，则必须采用防止数据包错序的机制。”这是必要的，因为ECMP实现可能会检查MPLS标签堆栈之后的第一个半字节，以确定标记的数据包是否为IP。因此，如果在PW上携带的以太网帧的源MAC地址（不存在控制字）以0x4或0x6开头，则可能会将其误认为IPv4或IPv6数据包。根据MPLS网络的配置和拓扑，这可能导致给定PW的所有数据包不遵循相同路径的情况。这可能会增加给定PW上的无序帧，或导致OAM数据包遵循与实际流量不同的路径（参见第4.4.3节“帧顺序”）。
The features that the control word provides may not be needed for a given Ethernet PW. For example, ECMP may not be present or active on a given MPLS network, strict frame sequencing may not be required, etc. If this is the case, the control word provides little value and is therefore optional. Early Ethernet PW implementations have been deployed that do not include a control word or the ability to process one if present. To aid in backwards compatibility, future implementations MUST be able to send and receive frames without the control word present.
给定以太网PW可能不需要控制字提供的功能。例如，ECMP在给定MPLS网络上可能不存在或不活动，可能不需要严格的帧排序等。如果是这种情况，则控制字提供的值很小，因此是可选的。早期的以太网PW实现已经部署，不包括控制字或处理控制字（如果存在）的能力。为了帮助实现向后兼容性，未来的实现必须能够在不存在控制字的情况下发送和接收帧。
When PWs were first deployed, some equipment of commercial significance was unable to process the Ethernet CW. In addition, at that time, it was believed that no Ethernet MAC address had been issued by the IEEE Registration Authority Committee (RAC) that started with 0x4 or 0x6; thus, it was thought to be safe to deploy Ethernet PWs without the CW.
当PWs首次部署时，一些具有商业意义的设备无法处理以太网CW。此外，当时认为IEEE注册管理委员会（RAC）没有发布以0x4或0x6开头的以太网MAC地址；因此，在没有CW的情况下部署以太网PWs被认为是安全的。
Since that time, the RAC has issued Ethernet MAC addresses that start with 0x4 or with 0x6. Therefore, the assumption that, in practical networks, there would be no confusion between an Ethernet PW packet without the CW and an IP packet is no longer correct.
自那时起，RAC已发出以0x4或0x6开头的以太网MAC地址。因此，在实际网络中，在没有CW的以太网PW分组和IP分组之间不会存在混淆的假设不再正确。
Possibly through the use of unauthorized Ethernet MAC addresses, this assumption has been unsafe for a while, leading some equipment vendors to implement more complex, proprietary methods to discriminate between Ethernet PW packets and IP packets. Such mechanisms rely on the heuristics of examining the transit packets to try to find out the exact payload type of the packet and cannot be reliable due to the random nature of the payload carried within such packets.
可能通过使用未经授权的以太网MAC地址，这种假设已经不安全了一段时间，导致一些设备供应商实施更复杂的专有方法来区分以太网PW数据包和IP数据包。这种机制依赖于检查传输数据包的启发式方法，以试图找出数据包的确切有效载荷类型，并且由于这些数据包中携带的有效载荷的随机性，因此不可靠。
A posting on the NANOG email list highlighted this problem:
NANOG电子邮件列表上的一条帖子突出了这个问题：
<https://mailman.nanog.org/pipermail/nanog/2016-December/089395.html>
<https://mailman.nanog.org/pipermail/nanog/2016-December/089395.html>
The ambiguity between an MPLS payload that is an Ethernet PW and one that is an IP packet is resolved when the Ethernet PW CW is used. This document updates [RFC4448] to state that both the ingress provider edge (PE) and the egress PE SHOULD support the Ethernet PW CW and that, if supported, the CW MUST be used.
当使用以太网PW CW时，作为以太网PW的MPLS有效负载和作为IP分组的MPLS有效负载之间的模糊性得到解决。本文档更新了[RFC4448]以说明入口提供程序边缘（PE）和出口PE均应支持以太网PW CW，如果支持，则必须使用CW。
Where the application of ECMP to Ethernet PW traffic is required and where both the ingress and the egress PEs support Entropy Label Indicator / Entropy Label (ELI/EL) [RFC6790] and Flow-Aware Transport of Pseudowires (FAT PW) [RFC6391], then either method may be used. The use of both methods on the same PW is not normally necessary and should be avoided unless circumstances require it. In the case of multi-segment PWs, if ELI/EL is used, then it SHOULD be used on every segment of the PW. The method by which usage of ELI/EL on every segment is guaranteed is out of the scope of this document.
如果需要将ECMP应用于以太网PW流量，并且入口和出口PE都支持熵标签指示器/熵标签（ELI/EL）[RFC6790]和伪线的流量感知传输（FAT PW）[RFC6391]，则可以使用任何一种方法。通常不需要在同一PW上使用这两种方法，除非情况需要，否则应避免使用这两种方法。对于多段PW，如果使用ELI/EL，则应在PW的每个段上使用。保证在每个分段上使用ELI/EL的方法不在本文件范围内。
Where the volume of traffic on an Ethernet PW is such that ECMP is required, then one of two methods may be used:
如果以太网PW上的通信量需要ECMP，则可以使用以下两种方法之一：
o Flow-Aware Transport of Pseudowires over an MPLS Packet Switched Network, specified in [RFC6391], or
o [RFC6391]中规定的通过MPLS分组交换网络的伪线流感知传输，或
o Label Switched Path (LSP) entropy labels, specified in [RFC6790].
o 标签交换路径（LSP）熵标签，在[RFC6790]中指定。
RFC 6391 works by increasing the entropy of the bottom-of-stack label. It requires that both the ingress and egress PEs support this feature. It also requires that sufficient LSRs on the LSP between the ingress and egress PE be able to select an ECMP path on an MPLS packet with the resultant stack depth.
RFC6391的工作原理是增加堆栈底部标签的熵。它要求入口和出口PEs都支持此功能。它还要求入口和出口PE之间的LSP上有足够的LSR能够选择MPLS数据包上具有结果堆栈深度的ECMP路径。
RFC 6790 works by including an entropy value in the LSP part of the label stack. This requires that the ingress and egress PEs support the insertion and removal of the EL and the ELI and that sufficient LSRs on the LSP are able to perform ECMP based on the EL.
RFC 6790的工作原理是在标签堆栈的LSP部分包含一个熵值。这要求入口和出口PE支持EL和ELI的插入和移除，并且LSP上的足够LSR能够基于EL执行ECMP。
In both cases, there are considerations in getting Operations, Administration, and Maintenance (OAM) packets to follow the same path as a data packet. This is described in detail in Section 7 of [RFC6391] and Section 6 of [RFC6790]. However, in both cases, the situation is improved compared to the ECMP behavior in the case where the Ethernet PW CW was not used, since there is currently no known method of getting a PW OAM packet to follow the same path as a PW data packet subjected to ECMP based on the five-tuple of the IP payload.
在这两种情况下，都需要考虑让操作、管理和维护（OAM）数据包遵循与数据包相同的路径。[RFC6391]第7节和[RFC6790]第6节对此进行了详细说明。然而，在这两种情况下，与未使用以太网PW CW的情况下的ECMP行为相比，情况得到了改善，因为目前没有已知的方法使PW OAM分组遵循与基于IP有效载荷的五元组进行ECMP的PW数据分组相同的路径。
The PW label is pushed before the LSP label. As the ELI/EL labels are part of the LSP layer rather than part of the PW layer, they are pushed after the PW label has been pushed.
将PW标签推到LSP标签之前。由于ELI/EL标签是LSP层的一部分，而不是PW层的一部分，因此在推送PW标签后推送它们。
Where it is not possible to use the Ethernet PW CW, the effects of ECMP can be disabled by carrying the PW over a traffic-engineered path that does not subject the payload to load balancing (for example, RSVP-TE [RFC3209]). However, such paths may be subjected to link-bundle load balancing, and, of course, the single LSP has to carry the full PW load.
在无法使用以太网PW CW的情况下，可以通过在不使有效负载服从负载平衡的流量工程路径上承载PW来禁用ECMP的影响（例如，RSVP-TE[RFC3209]）。然而，这样的路径可能受到链路束负载平衡的影响，当然，单个LSP必须承载完整的PW负载。
In some cases, the inclusion of a CW in the PW is determined by equipment configuration. Furthermore, it is possible that the default configuration in such cases is to disable use of the CW. Care needs to be taken to ensure that software that implements this recommendation does not depend on existing configuration settings that prevent the use of a CW. It is recommended that platform software emit a rate-limited message indicating that the CW can be used but is disabled due to existing configuration.
在某些情况下，PW中是否包含CW取决于设备配置。此外，在这种情况下，默认配置可能是禁用CW的使用。需要注意确保实现本建议的软件不依赖于阻止使用CW的现有配置设置。建议平台软件发出速率限制消息，指示CW可以使用，但由于现有配置而被禁用。
Instead of including a payload type in the packet, MPLS relies on the control plane to signal the payload type that follows the bottom of the label stack. Some LSRs attempt to deduce the packet type by MPLS
MPLS不在数据包中包含有效负载类型，而是依赖于控制平面来通知标签堆栈底部的有效负载类型。一些LSR试图通过MPLS推断数据包类型
payload inspection, in some cases looking past the PW CW. If the payload appears to be IP or IP carried in an Ethernet header, they perform an ECMP calculation based on what they assume to be the five-tuple fields. However, deduction of the payload type in this way is not an exact science, and where a packet that is not IP is mistaken for an IP packet, the result can be packets delivered out of order. Misordering of this type can be difficult for an operator to diagnose. When enabling capability that allows information gleaned from packet inspection past the PW CW to be used in any ECMP calculation, operators should be aware that this may cause Ethernet frames to be delivered out of order despite the presence of the CW.
有效载荷检查，在某些情况下查看PW CW。如果有效负载看起来是IP或以太网报头中承载的IP，则它们将根据假定为五元组字段的内容执行ECMP计算。然而，以这种方式推断有效负载类型并不是一门精确的科学，当非IP的数据包被误认为是IP数据包时，结果可能是数据包交付顺序混乱。操作员很难诊断这种类型的错误排序。当启用允许在任何ECMP计算中使用通过PW CW的数据包检查收集的信息的功能时，操作员应注意，这可能会导致以太网帧在CW存在的情况下无法正常传输。
This document expresses a preference for one existing and widely deployed Ethernet PW encapsulation over another. These methods have identical security considerations, which are discussed in [RFC4448]. This document introduces no additional security issues.
本文档表达了对一种现有且广泛部署的以太网PW封装的偏好。这些方法具有相同的安全注意事项，在[RFC4448]中进行了讨论。本文档不介绍其他安全问题。
This document has no IANA actions.
本文档没有IANA操作。
[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>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385, February 2006, <https://www.rfc-editor.org/info/rfc4385>.
[RFC4385]Bryant，S.，Swallow，G.，Martini，L.，和D.McPherson，“用于MPLS PSN的伪线仿真边到边（PWE3）控制字”，RFC 4385，DOI 10.17487/RFC4385，2006年2月<https://www.rfc-editor.org/info/rfc4385>.
[RFC4448] Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron, "Encapsulation Methods for Transport of Ethernet over MPLS Networks", RFC 4448, DOI 10.17487/RFC4448, April 2006, <https://www.rfc-editor.org/info/rfc4448>.
[RFC4448]Martini，L.，Ed.，Rosen，E.，El Aawar，N.，和G.Heron，“通过MPLS网络传输以太网的封装方法”，RFC 4448，DOI 10.17487/RFC4448，2006年4月<https://www.rfc-editor.org/info/rfc4448>.
[RFC4928] Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal Cost Multipath Treatment in MPLS Networks", BCP 128, RFC 4928, DOI 10.17487/RFC4928, June 2007, <https://www.rfc-editor.org/info/rfc4928>.
[RFC4928]Swallow，G.，Bryant，S.和L.Andersson，“避免MPLS网络中的等成本多路径处理”，BCP 128，RFC 4928，DOI 10.17487/RFC4928，2007年6月<https://www.rfc-editor.org/info/rfc4928>.
[RFC6391] Bryant, S., Ed., Filsfils, C., Drafz, U., Kompella, V., Regan, J., and S. Amante, "Flow-Aware Transport of Pseudowires over an MPLS Packet Switched Network", RFC 6391, DOI 10.17487/RFC6391, November 2011, <https://www.rfc-editor.org/info/rfc6391>.
[RFC6391]Bryant，S.，Ed.，Filsfils，C.，Drafz，U.，Kompella，V.，Regan，J.，和S.Amante，“MPLS分组交换网络上伪线的流感知传输”，RFC 6391，DOI 10.17487/RFC63911911<https://www.rfc-editor.org/info/rfc6391>.
[RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and L. Yong, "The Use of Entropy Labels in MPLS Forwarding", RFC 6790, DOI 10.17487/RFC6790, November 2012, <https://www.rfc-editor.org/info/rfc6790>.
[RFC6790]Kompella，K.，Drake，J.，Amante，S.，Henderickx，W.，和L.Yong，“MPLS转发中熵标签的使用”，RFC 6790，DOI 10.17487/RFC6790，2012年11月<https://www.rfc-editor.org/info/rfc6790>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[RFC2992] Hopps, C., "Analysis of an Equal-Cost Multi-Path Algorithm", RFC 2992, DOI 10.17487/RFC2992, November 2000, <https://www.rfc-editor.org/info/rfc2992>.
[RFC2992]Hopps，C.，“等成本多路径算法的分析”，RFC 2992，DOI 10.17487/RFC2992，2000年11月<https://www.rfc-editor.org/info/rfc2992>.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, <https://www.rfc-editor.org/info/rfc3209>.
[RFC3209]Awduche，D.，Berger，L.，Gan，D.，Li，T.，Srinivasan，V.，和G.Swallow，“RSVP-TE：LSP隧道RSVP的扩展”，RFC 3209，DOI 10.17487/RFC3209，2001年12月<https://www.rfc-editor.org/info/rfc3209>.
[RFC5085] Nadeau, T., Ed. and C. Pignataro, Ed., "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires", RFC 5085, DOI 10.17487/RFC5085, December 2007, <https://www.rfc-editor.org/info/rfc5085>.
[RFC5085]Nadeau，T.，Ed.和C.Pignataro，Ed.，“伪线虚拟电路连接验证（VCCV）：伪线的控制通道”，RFC 5085，DOI 10.17487/RFC5085，2007年12月<https://www.rfc-editor.org/info/rfc5085>.
Acknowledgments
致谢
The authors thank Job Snijders for drawing attention to this problem. The authors also thank Pat Thaler for clarifying the matter of local MAC address assignment. We thank Sasha Vainshtein for his valuable review comments.
作者感谢Job Snijders对这个问题的关注。作者还感谢Pat Thaler澄清了本地MAC地址分配的问题。我们感谢Sasha Vainstein的宝贵评论。
Authors' Addresses
作者地址
Stewart Bryant Huawei
斯图尔特·布莱恩特·华为
Email: stewart.bryant@gmail.com
Email: stewart.bryant@gmail.com
Andrew G. Malis Huawei
安德鲁·马里斯·华为
Email: agmalis@gmail.com
Email: agmalis@gmail.com
Ignas Bagdonas Equinix
伊格纳斯巴格多纳斯Equinix
Email: ibagdona.ietf@gmail.com>
Email: ibagdona.ietf@gmail.com>