Internet Engineering Task Force (IETF) N. Akiya
Request for Comments: 7737 Big Switch Networks
Updates: 7110 G. Swallow
Category: Standards Track C. Pignataro
ISSN: 2070-1721 Cisco Systems
L. Andersson
M. Chen
Huawei
January 2016
Internet Engineering Task Force (IETF) N. Akiya
Request for Comments: 7737 Big Switch Networks
Updates: 7110 G. Swallow
Category: Standards Track C. Pignataro
ISSN: 2070-1721 Cisco Systems
L. Andersson
M. Chen
Huawei
January 2016
Label Switched Path (LSP) Ping and Traceroute Reply Mode Simplification
标签交换路径（LSP）Ping和跟踪路由回复模式简化
Abstract
摘要
The Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Ping and Traceroute use the Reply Mode field to signal the method to be used in the MPLS echo reply. This document updates the procedures for the "Reply via Specified Path" Reply Mode. The value of this Reply Mode is 5. The update creates a simple way to indicate that the reverse LSP should be used as the return path. This document also adds an optional TLV that can carry an ordered list of Reply Mode values.
多协议标签交换（MPLS）标签交换路径（LSP）Ping和Traceroute使用应答模式字段向MPLS回送应答中使用的方法发送信号。本文档更新了“通过指定路径回复”回复模式的过程。此回复模式的值为5。更新创建了一种简单的方法来指示应该将反向LSP用作返回路径。本文档还添加了一个可选的TLV，它可以携带应答模式值的有序列表。
This document updates RFC 7110.
本文件更新了RFC 7110。
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 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7737.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7737.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 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 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文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Problem Statements . . . . . . . . . . . . . . . . . . . . . 4
3. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. "Reply via Specified Path" Reply Mode Update . . . . . . 5
3.2. Reply Mode Order TLV . . . . . . . . . . . . . . . . . . 6
4. Relationships to Other LSP Ping and Traceroute Features . . . 8
4.1. Backwards Compatibility with "Reply via Specified Path"
Reply Mode . . . . . . . . . . . . . . . . . . . . . . . 8
4.2. Reply Path TLV . . . . . . . . . . . . . . . . . . . . . 8
4.2.1. Example 1: Reply Mode Order TLV Usage with Reply Path
TLV . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2.2. Example 2: Reply Mode Order TLV Usage with Reply Path
TLV . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.3. Proxy LSP Ping . . . . . . . . . . . . . . . . . . . . . 10
4.3.1. Proxy LSR Sending an MPLS Echo Request . . . . . . . 10
4.3.2. Proxy LSR Sending an MPLS Proxy Ping Reply . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. Manageability Considerations . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7.1. New Reply Mode Order TLV . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . 13
Appendix A. Reply Mode Order TLV Beneficial Scenarios . . . . . 14
A.1. Incorrect Forwarding Scenario . . . . . . . . . . . . . . 14
A.2. Non-Co-Routed Bidirectional LSP Scenario . . . . . . . . 15
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 16
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Problem Statements . . . . . . . . . . . . . . . . . . . . . 4
3. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. "Reply via Specified Path" Reply Mode Update . . . . . . 5
3.2. Reply Mode Order TLV . . . . . . . . . . . . . . . . . . 6
4. Relationships to Other LSP Ping and Traceroute Features . . . 8
4.1. Backwards Compatibility with "Reply via Specified Path"
Reply Mode . . . . . . . . . . . . . . . . . . . . . . . 8
4.2. Reply Path TLV . . . . . . . . . . . . . . . . . . . . . 8
4.2.1. Example 1: Reply Mode Order TLV Usage with Reply Path
TLV . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2.2. Example 2: Reply Mode Order TLV Usage with Reply Path
TLV . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.3. Proxy LSP Ping . . . . . . . . . . . . . . . . . . . . . 10
4.3.1. Proxy LSR Sending an MPLS Echo Request . . . . . . . 10
4.3.2. Proxy LSR Sending an MPLS Proxy Ping Reply . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. Manageability Considerations . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7.1. New Reply Mode Order TLV . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . 13
Appendix A. Reply Mode Order TLV Beneficial Scenarios . . . . . 14
A.1. Incorrect Forwarding Scenario . . . . . . . . . . . . . . 14
A.2. Non-Co-Routed Bidirectional LSP Scenario . . . . . . . . 15
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 16
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Ping, as described in [RFC4379], allows an initiator Label Switching Router (LSR) to encode instructions (Reply Mode) on how a responder LSR should send the response back to the initiator LSR. [RFC7110] also allows the initiator LSR to encode a TLV (Reply Path TLV) that can instruct the responder LSR to use a specific LSP to send the response back to the initiator LSR. Both approaches are powerful, as they provide the ability for the initiator LSR to control the return path.
多协议标签交换（MPLS）标签交换路径（LSP）Ping，如[RFC4379]中所述，允许启动器标签交换路由器（LSR）编码关于应答器LSR应如何将响应发送回启动器LSR的指令（应答模式）。[RFC7110]还允许启动器LSR编码TLV（应答路径TLV），该TLV可指示应答器LSR使用特定LSP将响应发送回启动器LSR。这两种方法都很强大，因为它们为启动器LSR提供了控制返回路径的能力。
However, it is becoming increasingly difficult for an initiator LSR to select a valid return path to encode in the MPLS LSP echo request packets. If the initiator LSR does not select a valid return path, the MPLS LSP echo reply will not get back to the initiator LSR. This results in a false failure of MPLS LSP Ping and Traceroute operations. In an effort to minimize such false failures, different implementations have chosen different default return path encoding for different LSP types and LSP operations. The problem with implementations having different default return path encoding is that the MPLS echo reply will not work in many cases, and the default value may not be the preferred choice of the operators.
然而，对于发起者LSR来说，选择有效的返回路径以在MPLS LSP echo请求分组中编码变得越来越困难。如果启动器LSR未选择有效的返回路径，MPLS LSP回显回复将不会返回到启动器LSR。这将导致MPLS LSP Ping和跟踪路由操作的错误失败。为了尽量减少此类错误故障，不同的实现为不同的LSP类型和LSP操作选择了不同的默认返回路径编码。具有不同默认返回路径编码的实现存在的问题是，MPLS回送应答在许多情况下不起作用，并且默认值可能不是运营商的首选。
This document describes the following:
本文件描述了以下内容：
o In Section 2, further description of the problems;
o 第2节，对问题的进一步描述；
o In Section 3, a solution to minimize false failures while accommodating operator preferences;
o 在第3节中，一种在满足操作员偏好的同时最小化错误故障的解决方案；
o In Section 4, relationships to other LSP Ping and Traceroute features;
o 在第4节中，与其他LSP Ping和Traceroute功能的关系；
o In Appendix A, examples of scenarios where the mechanism described in this document provides benefits.
o 在附录A中，本文档中描述的机制提供好处的场景示例。
This document updates [RFC7110] by allowing the usage of the "Reply via Specified Path" (value=5) Reply Mode without including the Reply Path TLV. The update creates a simple way to indicate that the reverse LSP should be used as the return path.
本文档通过允许使用“通过指定路径回复”（值=5）回复模式而不包括回复路径TLV来更新[RFC7110]。更新创建了一种简单的方法来指示应该将反向LSP用作返回路径。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
It is becoming increasingly difficult for implementations to automatically supply a workable return path encoding for all MPLS LSP Ping and Traceroute operations across all LSP types. There are several factors that contribute to this complication.
实现自动为所有MPLS LSP Ping和跟踪路由操作跨所有LSP类型提供可行的返回路径编码变得越来越困难。有几个因素导致了这种复杂性。
o Some LSPs have a control channel, and some do not. Some LSPs have a reverse LSP, and some do not. Some LSPs have IP reachability in the reverse direction, and some do not.
o 有些LSP有控制通道，有些没有。有些LSP有反向LSP，有些则没有。有些LSP具有反向的IP可达性，有些则没有。
o LSRs on some LSPs can have different available return path(s). Available return path(s) can depend on whether the responder LSR is a transit LSR or an egress LSR. In the case of a bidirectional LSP, available return path(s) on transit LSRs can also depend on whether the LSP is completely co-routed, partially co-routed, or associated (i.e., the LSPs in the two directions are not co-routed).
o 某些LSP上的LSR可以具有不同的可用返回路径。可用的返回路径可取决于响应者LSR是中转LSR还是出口LSR。在双向LSP的情况下，公交LSR上的可用返回路径还取决于LSP是完全共路由、部分共路由还是关联（即，两个方向上的LSP不是共路由）。
o MPLS echo request packets may incorrectly terminate on an unintended target that can have different available return path(s) than the intended target.
o MPLS回送请求数据包可能会错误地终止在可能具有不同于预期目标的可用返回路径的非预期目标上。
o The MPLS LSP Ping operation is expected to terminate on an egress LSR. However, MPLS LSP Ping operations with specific TTL values and MPLS LSP Traceroute operations can terminate on both transit LSR(s) and the egress LSR.
o MPLS LSP Ping操作预计将在出口LSR上终止。然而，具有特定TTL值的MPLS LSP Ping操作和MPLS LSP跟踪路由操作可以在传输LSR和出口LSR上终止。
Except for the case where the responder LSR does not have an IP route back to the initiator LSR, it is possible to use the "Reply via an IPv4/IPv6 UDP packet" (value=2) Reply Mode value in all cases. However, some operators prefer the control channel and a reverse LSP as the default return path if they are both available, although this is not always the case.
除了响应者LSR没有返回到启动器LSR的IP路由的情况外，在所有情况下都可以使用“通过IPv4/IPv6 UDP数据包进行回复”（值=2）回复模式值。但是，如果控制通道和反向LSP都可用，一些运营商更喜欢将它们作为默认返回路径，尽管情况并非总是如此。
When specific return path encoding is supplied by users or applications, then there are no issues in choosing the return path encoding. When specific return path encoding is not supplied by users or applications, then implementations use extra logic to compute, and sometimes guess, the default return path encodings. If a responder LSR receives an MPLS echo request containing return path instructions that cannot be accommodated due to unavailability, then the responder LSR often drops such packets. This failure mode results in the initiator LSR not receiving the intended MPLS LSP echo reply packets. The scenario described here is a potentially acceptable result in some failure cases, like a broken LSP, where the MPLS echo request terminated on an unintended target. However, if the initiator LSR does not receive an MPLS echo reply even after the
当用户或应用程序提供特定的返回路径编码时，选择返回路径编码就没有问题。当用户或应用程序未提供特定的返回路径编码时，实现将使用额外的逻辑来计算（有时是猜测）默认的返回路径编码。如果响应者LSR接收到包含由于不可用而无法容纳的返回路径指令的MPLS回显请求，则响应者LSR通常丢弃此类数据包。此故障模式导致启动器LSR未接收到预期的MPLS LSP回显回复数据包。这里描述的场景在某些故障情况下可能是可接受的结果，如LSP中断，其中MPLS回送请求在非预期目标上终止。但是，如果发起方LSR即使在
responder LSR receives the MPLS echo request and is able to verify the request, information is still sent back to the user(s); this is considered a false failure.
响应者LSR接收MPLS回波请求并能够验证该请求，信息仍然发送回用户；这被认为是错误的失败。
Many operators prefer particular return path(s) over other return path(s) for specific LSP types. To accommodate operator-preferred paths, implementations may default to operator-preferred return paths for particular operations or allow a default return path to be configured. It would not be considered beneficial to use a preferred return path for an intended target LSR if there is previous knowledge at the initiator LSR that the return path is not available. Using an unavailable preferred return path would undesirably result in the initiator LSR not receiving the MPLS echo return packets. It would be considered beneficial, for given operations, if the sender of the MPLS echo request would be able to determine return path availability before the operation is initiated.
对于特定的LSP类型，许多操作员更喜欢特定的返回路径，而不是其他返回路径。为了适应操作员首选路径，实现可以默认为特定操作的操作员首选返回路径，或者允许配置默认返回路径。如果发起者LSR先前知道返回路径不可用，则认为使用预期目标LSR的首选返回路径是不利的。使用不可用的首选返回路径将不希望地导致启动器LSR不接收MPLS回波返回包。对于给定的操作，如果MPLS echo请求的发送方能够在操作启动之前确定返回路径的可用性，则认为这是有益的。
This document (1) updates the procedures for the "Reply via Specified Path" Reply Mode to easily indicate the reverse LSP and (2) adds one optional TLV to describe an ordered list of Reply Modes. Based on operational needs, the TLV can list multiple Reply Mode values in a preferred order to allow the responder LSR to use the first available Reply Mode from the list. This eliminates the need for the initiator LSR to compute, or sometimes guess, the default return path encoding. This new mode of operation would result in simplified implementations across the various vendors and improve both usability and operational needs.
本文件（1）更新了“通过指定路径回复”回复模式的程序，以方便指示反向LSP；（2）添加了一个可选TLV，以描述回复模式的有序列表。基于操作需要，TLV可以以优选顺序列出多个应答模式值，以允许应答器LSR使用列表中的第一个可用应答模式。这消除了启动器LSR计算或有时猜测默认返回路径编码的需要。这种新的操作模式将简化各个供应商的实现，并提高可用性和操作需求。
This document updates the procedures for the "Reply via Specified Path" Reply Mode to easily indicate the reverse LSP. This document also adds an optional TLV that can carry an ordered list of Reply Modes.
本文档更新了“通过指定路径回复”回复模式的程序，以方便指示反向LSP。本文档还添加了一个可选的TLV，它可以携带回复模式的有序列表。
Some LSP types are capable of having a related LSP in the reverse direction, through signaling or other association mechanisms. Examples of such LSP types are bidirectional Resource Reservation Protocol-Traffic Engineering (RSVP-TE) LSPs [RFC3473] and MPLS Transport Profile (MPLS-TP) LSPs [RFC5960]. This document uses the term "reverse LSP" to refer to the LSP in the reverse direction of such LSP types. Note that this document restricts the scope of "reverse LSP" applicability to those reverse LSPs that are capable and allowed to carry the IP encapsulated MPLS echo reply.
一些LSP类型能够通过信令或其他关联机制在相反方向上具有相关LSP。此类LSP类型的示例为双向资源预留协议流量工程（RSVP-TE）LSP[RFC3473]和MPLS传输配置文件（MPLS-TP）LSP[RFC5960]。本文件使用术语“反向LSP”指此类LSP类型反向的LSP。请注意，本文档将“反向LSP”的适用范围限制为能够并允许携带IP封装的MPLS回显应答的反向LSP。
[RFC7110] has defined the Reply Mode "Reply via Specified Path", which allows the initiator LSR to instruct the responder LSR to send the MPLS echo reply message on the reverse LSP. However, the instruction also requires the initiator LSR to include the Reply Path TLV with the B bit (Bidirectional bit) set in the Flags field. Additionally, [RFC7110] specifies that if the "Reply via Specified Path" Reply Mode is used the Reply Path TLV MUST be present.
[RFC7110]定义了应答模式“通过指定路径进行应答”，该模式允许发起方LSR指示应答方LSR在反向LSP上发送MPLS回显应答消息。但是，该指令还要求启动器LSR包含应答路径TLV，并在标志字段中设置B位（双向位）。此外，[RFC7110]指定如果使用“通过指定路径回复”回复模式，则回复路径TLV必须存在。
This document updates the procedures for the "Reply via Specified Path" Reply Mode as follows:
本文件更新了“通过指定路径回复”回复模式的程序，如下所示：
o The "Reply via Specified Path" Reply Mode MAY be used without including a Reply Path TLV.
o “通过指定路径回复”回复模式可在不包括回复路径TLV的情况下使用。
o The usage of the "Reply via Specified Path" Reply Mode without the inclusion of a Reply Path TLV implies the reverse LSP. In other words, the usage of the "Reply via Specified Path" Reply Mode without the inclusion of a Reply Path TLV has the same semantics as the usage of the "Reply via Specified Path" Reply Mode with the inclusion of a Reply Path TLV with the B bit set in the Flags field.
o 在不包含回复路径TLV的情况下使用“通过指定路径回复”回复模式意味着反向LSP。换句话说，不包括应答路径TLV的“通过指定路径应答”应答模式的使用与包括在标志字段中设置了B位的应答路径TLV的“通过指定路径应答”应答模式的使用具有相同的语义。
This document updates the first sentence of Section 5.1 of [RFC7110] as follows:
本文件将[RFC7110]第5.1节的第一句更新如下：
o When sending an echo request, in addition to the rules and procedures defined in Section 4.3 of [RFC4379], the Reply Mode of the echo request MUST be set to "Reply via Specified Path", and a Reply Path TLV SHOULD be carried in the echo request message correspondingly; if the Reply Path TLV is not carried in the message, then it indicates the reverse LSP as the reply path.
o 发送回显请求时，除[RFC4379]第4.3节定义的规则和程序外，回显请求的回复模式必须设置为“通过指定路径回复”，回显请求报文中应相应携带回复路径TLV；如果消息中未携带回复路径TLV，则它将反向LSP指示为回复路径。
Note that the reverse LSP is in relation to the last Forwarding Equivalence Class (FEC) specified in the Target FEC Stack TLV.
请注意，反向LSP与目标FEC堆栈TLV中指定的最后一个转发等价类（FEC）有关。
This document also introduces a new optional TLV to describe a list of Reply Mode values. The new TLV will contain one or more Reply Mode values in preferred order. The first Reply Mode value is the most preferred, and the last Reply Mode value is the least preferred. The following rules apply when using the Reply Mode Order TLV:
本文档还引入了一个新的可选TLV来描述回复模式值列表。新TLV将按首选顺序包含一个或多个应答模式值。第一个应答模式值是最首选的，最后一个应答模式值是最不首选的。使用回复模式订单TLV时，以下规则适用：
1. The Reply Mode Order TLV MUST NOT be included in any MPLS echo reply. If the initiator LSR receives an MPLS echo reply with the Reply Mode Order TLV, the initiator LSR MUST ignore the whole Reply Mode Order TLV and MUST only use the value from the Reply
1. 回复模式顺序TLV不得包含在任何MPLS回送回复中。如果启动器LSR接收到带有回复模式顺序TLV的MPLS回显回复，则启动器LSR必须忽略整个回复模式顺序TLV，并且必须仅使用回复中的值
Mode field of the received MPLS echo reply. It may be beneficial for implementations to provide counters and/or logs, with appropriate log dampening, to record this error case.
接收到的MPLS回显回复的模式字段。为实现提供计数器和/或日志（具有适当的日志缓冲）来记录此错误情况可能是有益的。
2. The Reply Mode Order TLV MAY be included in MPLS echo requests.
2. 应答模式顺序TLV可以包括在MPLS回送请求中。
3. The Reply Mode field of an MPLS echo request MUST be set to a valid value even when supplying the Reply Mode Order TLV. The initiator LSR SHOULD set the Reply Mode field of an MPLS echo request to a value that corresponds to a return path that is most likely to be available, in case the responder LSR does not understand the Reply Mode Order TLV.
3. 即使在提供应答模式顺序TLV时，MPLS回送请求的应答模式字段也必须设置为有效值。发起方LSR应将MPLS回送请求的回复模式字段设置为与最有可能可用的返回路径相对应的值，以防响应方LSR不理解回复模式顺序TLV。
4. If a responder LSR understands the Reply Mode Order TLV but the TLV is not valid (due to the conditions described in items 6, 7, 8, and 9 below), then the responder LSR MUST ignore the whole Reply Mode Order TLV and MUST only use the value from the Reply Mode field of the received MPLS echo request. It may be beneficial for implementations to provide counters and/or logs, with appropriate log dampening, to record this error case.
4. 如果响应者LSR了解回复模式顺序TLV，但TLV无效（由于以下第6、7、8和9项中所述的条件），则响应者LSR必须忽略整个回复模式顺序TLV，并且只能使用接收到的MPLS回显请求的回复模式字段中的值。为实现提供计数器和/或日志（具有适当的日志缓冲）来记录此错误情况可能是有益的。
5. If a responder LSR understands the Reply Mode Order TLV and the TLV is valid, then the responder LSR MUST consider the Reply Mode values specified in the TLV and MUST NOT use the value specified in the Reply Mode field of the received MPLS echo request. In other words, a valid Reply Mode Order TLV overrides the value specified in the Reply Mode field of the received MPLS echo request.
5. 如果应答器LSR理解应答模式顺序TLV和TLV是有效的，那么应答器LSR必须考虑TLV中指定的应答模式值，并且不能使用接收到的MPLS回波请求的应答模式字段中指定的值。换句话说，有效的应答模式顺序TLV覆盖在接收到的MPLS回显请求的应答模式字段中指定的值。
6. The Reply Mode Order TLV MUST contain at least one Reply Mode value.
6. 回复模式顺序TLV必须至少包含一个回复模式值。
7. A Reply Mode value, except for Reply Mode value 5 (Reply via Specified Path), MUST NOT be repeated (i.e., MUST NOT appear multiple times) in the Reply Mode Order TLV.
7. 回复模式值（回复模式值5（通过指定路径回复）除外）不得在回复模式顺序TLV中重复（即不得出现多次）。
8. Reply Mode value 5 (Reply via Specified Path) MAY be included more than once in the Reply Mode Order TLV. However, in such a case, a Reply Path TLV MUST be included for all instances of Reply Mode value 5 that are included in the Reply Mode Order TLV. In other words, three instances of Reply Mode value 5 in the Reply Mode Order TLV will each require a Reply Path TLV.
8. 回复模式值5（通过指定路径回复）可以在回复模式顺序TLV中包含多次。然而，在这种情况下，对于应答模式顺序TLV中包括的应答模式值5的所有实例，必须包括应答路径TLV。换句话说，回复模式顺序TLV中的回复模式值5的三个实例将各自需要回复路径TLV。
9. The Reply Mode value 1 (Do not reply) MUST NOT be used in the Reply Mode Order TLV.
9. 回复模式值1（不回复）不得在回复模式顺序TLV中使用。
The responder LSR SHOULD select the first available return path in this TLV. The Reply Mode value corresponding to the selected return path MUST be set in the Reply Mode field of the MPLS echo reply to communicate back to the initiator LSR which return path was chosen.
响应者LSR应选择此TLV中的第一条可用返回路径。必须在MPLS回送回复的回复模式字段中设置与所选返回路径相对应的回复模式值，以便与所选返回路径的启动器LSR通信。
The format of the TLV is as follows:
TLV的格式如下所示：
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reply Mode Order TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Reply Mode 1 | Reply Mode 2 | Reply Mode 3 | Reply Mode 4 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reply Mode Order TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Reply Mode 1 | Reply Mode 2 | Reply Mode 3 | Reply Mode 4 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Reply Mode Order TLV
图1：回复模式订单TLV
This is a variable-length optional TLV. The Reply Mode Order TLV Type is 32770.
这是一个可变长度的可选TLV。回复模式订单TLV类型为32770。
The Length field is 2 octets in length. It defines the length, in octets, of the list of Reply Mode values.
长度字段的长度为2个八位字节。它定义了应答模式值列表的长度（以八位字节为单位）。
Each Reply Mode field is 1 octet, and there is no padding.
每个回复模式字段为1个八位字节，并且没有填充。
[RFC7110] introduces the "Reply via Specified Path" (value=5) Reply Mode. [RFC7110] also specifies that if this Reply Mode is used the Reply Path TLV MUST be included. This document relaxes the semantics and specifies that this Reply Mode MAY be used without the Reply Path TLV. This MAY be done to indicate that the reverse LSP SHALL be used as the return path.
[RFC7110]引入“通过指定路径回复”（值=5）回复模式。[RFC7110]还指定，如果使用此回复模式，则必须包括回复路径TLV。本文档放松了语义，并指定可以在没有回复路径TLV的情况下使用此回复模式。这可能是为了表明反向LSP应用作返回路径。
If an initiator LSR that sent an MPLS echo request message with the "Reply via Specified Path" Reply Mode but without including the Reply Path TLV receives back an MPLS echo reply message with a return code of "Malformed echo request received", then the initiator LSR SHOULD assume that the responder LSR does not support the mechanism defined in this document.
如果发送带有“通过指定路径回复”回复模式但不包括回复路径TLV的MPLS回显请求消息的启动器LSR收到返回码为“收到格式错误的回显请求”的MPLS回显回复消息，然后，发起方LSR应该假设响应方LSR不支持本文档中定义的机制。
A Reply Path TLV [RFC7110] is defined to identify a single return path. When the initiator LSR wants to use the Reply Mode Order TLV to specify multiple return paths, then the initiator LSR SHOULD
应答路径TLV[RFC7110]被定义为标识单个返回路径。当启动器LSR想要使用应答模式顺序TLV来指定多个返回路径时，启动器LSR应该
include multiple "Reply via Specified Path" (value=5) Reply Mode values and multiple corresponding Reply Path TLV objects (one Reply Path TLV corresponding to a "Reply via Specified Path" Reply Mode and one Reply Path TLV identifying a return path).
包括多个“通过指定路径回复”（值=5）回复模式值和多个对应的回复路径TLV对象（一个回复路径TLV对应于“通过指定路径回复”回复模式，一个回复路径TLV标识返回路径）。
As described in Section 3.1, it is valid to use the "Reply via Specified Path" Reply Mode without inclusion in a Reply Path TLV. For the Reply Mode Order TLV, it is also valid to include a "Reply via Specified Path" Reply Mode value without a corresponding Reply Path TLV; this implies that the reverse LSP is the preferred return path. When multiple consecutive "Reply via Specified Path" Reply Mode values are included but fewer corresponding Reply Path TLV objects exist, the responder LSR SHOULD think that the former "Reply via Specified Path" Reply Mode values have corresponding Reply Path TLVs. The latter "Reply via Specified Path" Reply Mode values have no corresponding Reply Path TLVs. For example, if the Reply Mode Order TLV carries Reply Modes {5, 5, 5} and only two Reply Path TLVs carry FEC X and FEC Y, respectively, then the reply path order is as follows:
如第3.1节所述，使用“通过指定路径回复”回复模式而不包含在回复路径TLV中是有效的。对于回复模式顺序TLV，在没有相应回复路径TLV的情况下包括“通过指定路径回复”回复模式值也是有效的；这意味着反向LSP是首选返回路径。当包含多个连续的“通过指定路径回复”回复模式值但存在较少的对应回复路径TLV对象时，响应者LSR应认为前一个“通过指定路径回复”回复模式值具有对应的回复路径TLV。后一种“通过指定路径回复”回复模式值没有对应的回复路径TLV。例如，如果应答模式顺序TLV携带应答模式{5,5,5}，并且只有两个应答路径TLV分别携带FEC X和FEC Y，则应答路径顺序如下：
1. Reply via Specified Path (FEC X)
1. 通过指定路径回复（FEC X）
2. Reply via Specified Path (FEC Y)
2. 通过指定路径回复（FEC Y）
3. Reply via Specified Path (reverse LSP)
3. 通过指定路径回复（反向LSP）
If the initiator LSR was interested in encoding the following return paths:
如果启动器LSR对编码以下返回路径感兴趣：
1. Reply via application level control channel
1. 通过应用程序级控制通道进行回复
2. FEC X
2. fecx
3. FEC Y
3. FEC-Y
4. Reply via an IPv4/IPv6 UDP packet
4. 通过IPv4/IPv6 UDP数据包进行回复
Then the MPLS echo request message is to carry:
然后，MPLS回显请求消息将携带：
o The Reply Mode Order TLV carrying Reply Modes {4, 5, 5, 2}
o 带有回复模式{4,5,5,2}的回复模式顺序TLV
o One Reply Path TLV carrying FEC X
o 携带FEC X的一个应答路径TLV
o One Reply Path TLV carrying FEC Y
o 携带FEC Y的一个应答路径TLV
The encoding specified by the Reply Mode Order TLV and the Reply Path TLV in the MPLS echo request message will cause the responder LSR to prefer "Reply via application level control channel (4)", followed by FEC X, FEC Y, and then "Reply via an IPv4/IPv6 UDP packet (2)".
MPLS回显请求消息中的应答模式顺序TLV和应答路径TLV指定的编码将导致应答器LSR首选“通过应用程序级控制通道（4）进行应答”，然后是FEC X、FEC Y，然后是“通过IPv4/IPv6 UDP数据包进行应答（2）”。
If the initiator LSR was interested in encoding the following return paths:
如果启动器LSR对编码以下返回路径感兴趣：
1. Reverse LSP
1. 反向LSP
2. Reply via an IPv4/IPv6 UDP packet
2. 通过IPv4/IPv6 UDP数据包进行回复
3. FEC X
3. fecx
4. FEC Y
4. FEC-Y
Then the MPLS echo request message is to carry:
然后，MPLS回显请求消息将携带：
o The Reply Mode Order TLV carrying Reply Modes {5, 2, 5, 5}
o 带有回复模式{5,2,5,5}的回复模式顺序TLV
o One Reply Path TLV with the B bit set
o 设置了B位的一个应答路径TLV
o One Reply Path TLV carrying FEC X
o 携带FEC X的一个应答路径TLV
o One Reply Path TLV carrying FEC Y
o 携带FEC Y的一个应答路径TLV
The encoding specified by the Reply Mode Order TLV and the Reply Path TLV in the MPLS echo request message will cause the responder LSR to prefer the reverse LSP, followed by "Reply via an IPv4/IPv6 UDP packet (2)", FEC X, and then FEC Y.
MPLS回显请求消息中的应答模式顺序TLV和应答路径TLV指定的编码将导致应答器LSR首选反向LSP，然后是“通过IPv4/IPv6 UDP数据包（2）”进行应答、FEC X，然后是FEC Y。
The mechanism defined in this document will work with Proxy LSP Ping as defined by [RFC7555]. The MPLS proxy ping request message can carry a Reply Mode value in the header and one or more Reply Mode values in the Reply Mode Order TLV. It is RECOMMENDED that Reply Mode 2 (Reply via an IPv4/IPv6 UDP packet) be used in the Reply Mode field of the MPLS proxy ping request message.
本文档中定义的机制将与[RFC7555]定义的代理LSP Ping一起使用。MPLS代理ping请求消息可以在报头中携带应答模式值，在应答模式顺序TLV中携带一个或多个应答模式值。建议在MPLS代理ping请求消息的回复模式字段中使用回复模式2（通过IPv4/IPv6 UDP数据包进行回复）。
If the proxy LSR is sending an MPLS echo request, then the proxy LSR MUST copy the following elements from the MPLS proxy ping request message to the MPLS echo request message:
如果代理LSR正在发送MPLS回显请求，则代理LSR必须将以下元素从MPLS代理ping请求消息复制到MPLS回显请求消息：
o The Reply Mode field.
o 回复模式字段。
o The Reply Mode Order TLV.
o 回复模式命令TLV。
o The Reply Path TLV(s). If there is more than one Reply Path TLV, then the ordering of the TLVs MUST be preserved when copying.
o 回复路径为TLV。如果存在多个回复路径TLV，则复制时必须保留TLV的顺序。
If the proxy LSR is sending an MPLS proxy ping reply, then it is RECOMMENDED that the Reply Mode Order TLV be ignored and the Reply Mode field in the MPLS proxy ping request message be used.
如果代理LSR正在发送MPLS代理ping应答，则建议忽略应答模式顺序TLV，并使用MPLS代理ping请求消息中的应答模式字段。
The security considerations specified in [RFC4379] and [RFC7110] also apply for this document.
[RFC4379]和[RFC7110]中规定的安全注意事项也适用于本文件。
In addition, this document introduces the Reply Mode Order TLV. It provides a new way for an unauthorized source to gather more network information, especially information regarding the potential return path(s) of an LSP. To protect against unauthorized sources using MPLS echo request messages with the Reply Mode Order TLV to obtain network information, as also specified in [RFC4379], it is RECOMMENDED that implementations provide a means of checking the source addresses of MPLS echo request messages against an access list before accepting the message.
此外，本文档还介绍了回复模式Order TLV。它为未经授权的来源提供了一种新的方法来收集更多的网络信息，特别是有关LSP潜在返回路径的信息。如[RFC4379]中所述，为了防止未经授权的来源使用带有回复模式命令TLV的MPLS回送请求消息来获取网络信息，建议实施方案提供一种在接受消息之前根据访问列表检查MPLS回送请求消息源地址的方法。
Another potential security issue is that the MPLS echo request and reply messages are not encrypted; the contents of the MPLS echo request and reply messages may therefore be potentially exposed. Although the exposure is within the MPLS domain, if such exposure is a concern, some encryption mechanisms [MPLS-OPP-ENCR] may be employed.
另一个潜在的安全问题是MPLS回送请求和回复消息未加密；因此，MPLS回送请求和回复消息的内容可能被公开。尽管公开在MPLS域内，但如果这种公开是一个问题，则可以采用一些加密机制[MPLS-OPP-ENCR]。
Section 2 described problems that increase complexity with respect to operations and implementations. In order to simplify operations and to allow LSP Ping and Traceroute to function efficiently whilst preserving code simplicity, it is RECOMMENDED that implementations allow devices to have configuration options to set operator-preferred Reply Modes. For example:
第2节描述了增加操作和实现复杂性的问题。为了简化操作并允许LSP Ping和Traceroute有效运行，同时保持代码的简单性，建议实现允许设备具有配置选项以设置操作员首选的应答模式。例如：
o For those operators who are more interested in MPLS echo reply packets reaching the initiator LSR:
o 对于那些对到达启动器LSR的MPLS回送回复数据包更感兴趣的运营商：
1. Reply via an IPv4/IPv6 UDP packet (2)
1. 通过IPv4/IPv6 UDP数据包进行回复（2）
2. Reply via application level control channel (4)
2. 通过应用级控制通道回复（4）
3. Reply via Specified Path (5)
3. 通过指定路径回复（5）
o For those operators who are more interested in MPLS echo reply packets testing the paths related to the forward LSP:
o 对于那些对MPLS回波应答包测试与转发LSP相关的路径更感兴趣的运营商：
1. Reply via Specified Path (5)
1. 通过指定路径回复（5）
2. Reply via application level control channel (4)
2. 通过应用级控制通道回复（4）
3. Reply via an IPv4/IPv6 UDP packet (2)
3. 通过IPv4/IPv6 UDP数据包进行回复（2）
IANA has assigned a new TLV type value from the "TLVs" sub-registry within the "Multiprotocol Label Switching Architecture (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry, for the Reply Mode Order TLV.
IANA已从“多协议标签交换体系结构（MPLS）标签交换路径（LSP）Ping参数”注册表中的“TLV”子注册表为应答模式顺序TLV分配了一个新的TLV类型值。
The new TLV Type value has been assigned from the range 32768-49161, as specified in Sections 3 and 7.2 of [RFC4379]; this range is for optional TLVs that can be silently dropped if not recognized.
按照[RFC4379]第3节和第7.2节的规定，新的TLV类型值已从32768-49161范围内分配；此范围适用于可选TLV，如果无法识别，则可以静默删除。
Type Meaning Reference
----- ------- ---------
32770 Reply Mode Order TLV RFC 7737
Type Meaning Reference
----- ------- ---------
32770 Reply Mode Order TLV RFC 7737
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, DOI 10.17487/RFC4379, February 2006, <http://www.rfc-editor.org/info/rfc4379>.
[RFC4379]Kompella，K.和G.Swallow，“检测多协议标签交换（MPLS）数据平面故障”，RFC 4379，DOI 10.17487/RFC4379，2006年2月<http://www.rfc-editor.org/info/rfc4379>.
[RFC7110] Chen, M., Cao, W., Ning, S., Jounay, F., and S. Delord, "Return Path Specified Label Switched Path (LSP) Ping", RFC 7110, DOI 10.17487/RFC7110, January 2014, <http://www.rfc-editor.org/info/rfc7110>.
[RFC7110]Chen，M.，Cao，W.，Ning，S.，Jounay，F.，和S.Delord，“返回路径指定标签交换路径（LSP）Ping”，RFC 7110，DOI 10.17487/RFC7110，2014年1月<http://www.rfc-editor.org/info/rfc7110>.
[MPLS-OPP-ENCR] Farrel, A. and S. Farrell, "Opportunistic Security in MPLS Networks", Work in Progress, draft-ietf-mpls-opportunistic-encrypt-00, July 2015.
[MPLS-OPP-ENCR]Farrell，A.和S.Farrell，“MPLS网络中的机会主义安全”，正在进行的工作，草稿-ietf-MPLS-Opportatic-encrypt-00，2015年7月。
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, DOI 10.17487/RFC3473, January 2003, <http://www.rfc-editor.org/info/rfc3473>.
[RFC3473]Berger，L.，Ed.“通用多协议标签交换（GMPLS）信令资源预留协议流量工程（RSVP-TE）扩展”，RFC 3473，DOI 10.17487/RFC3473，2003年1月<http://www.rfc-editor.org/info/rfc3473>.
[RFC5960] Frost, D., Ed., Bryant, S., Ed., and M. Bocci, Ed., "MPLS Transport Profile Data Plane Architecture", RFC 5960, DOI 10.17487/RFC5960, August 2010, <http://www.rfc-editor.org/info/rfc5960>.
[RFC5960]Frost，D.，Ed.，Bryant，S.，Ed.，和M.Bocci，Ed.，“MPLS传输配置文件数据平面架构”，RFC 5960，DOI 10.17487/RFC5960，2010年8月<http://www.rfc-editor.org/info/rfc5960>.
[RFC7555] Swallow, G., Lim, V., and S. Aldrin, "Proxy MPLS Echo Request", RFC 7555, DOI 10.17487/RFC7555, June 2015, <http://www.rfc-editor.org/info/rfc7555>.
[RFC7555]Swallow，G.，Lim，V.和S.Aldrin，“代理MPLS回送请求”，RFC 7555，DOI 10.17487/RFC7555，2015年6月<http://www.rfc-editor.org/info/rfc7555>.
This section lists examples of how the Reply Mode Order TLV can be beneficial.
本节列出了回复模式订单TLV如何发挥作用的示例。
As shown in Figure 2, a network has an LSP with the forwarding path A-B-C-D-E. The LSP has a control channel.
如图2所示，网络具有具有转发路径a-B-C-D-E的LSP。LSP具有控制信道。
A------B------C------D------E
|
|
F
A------B------C------D------E
|
|
F
Forward Path: A-B-C-D-E
前进路径：A-B-C-D-E
Figure 2: Incorrect Forwarding
图2：不正确的转发
If D is incorrectly label switching to F (instead of E), then LSP Traceroute with "Reply via application level control channel (4)" will result in the following:
如果D错误地标记为切换到F（而不是E），则带有“通过应用程序级控制通道（4）回复”的LSP跟踪路由将导致以下结果：
Success (Reply from B) Success (Reply from C) Success (Reply from D) Timeout... Complete
成功（从B回复）成功（从C回复）成功（从D回复）超时。。。完成
This is because F does not have a control channel on which to send the MPLS echo reply message. With the extensions described in this document, the same procedures can be performed with the Reply Mode Order TLV carrying {4, 2}. When LSP Traceroute is issued, then the following output may be displayed without any unnecessary timeout:
这是因为F没有用于发送MPLS回显回复消息的控制通道。通过本文档中描述的扩展，可以对带有{4，2}的回复模式命令TLV执行相同的过程。发出LSP跟踪路由时，可能会显示以下输出，而不会出现任何不必要的超时：
Success (Reply from B, Reply Mode: 4) Success (Reply from C, Reply Mode: 4) Success (Reply from D, Reply Mode: 4) FEC Mismatch (Reply from F, Reply Mode: 2) Complete
成功（从B回复，回复模式：4）成功（从C回复，回复模式：4）成功（从D回复，回复模式：4）FEC不匹配（从F回复，回复模式：2）完成
The result provides more diagnostic information to the initiator LSR, and without any delay (i.e., timeout from one or more downstream LSRs).
结果向启动器LSR提供了更多的诊断信息，并且没有任何延迟（即一个或多个下游LSR超时）。
As shown in Figure 3, a network has a bidirectional LSP where the forward LSP and the reverse LSP are not fully co-routed.
如图3所示，网络具有双向LSP，其中正向LSP和反向LSP未完全共同路由。
+----C------D----+
/ \
A------B G------H
\ /
+----E------F----+
+----C------D----+
/ \
A------B G------H
\ /
+----E------F----+
Forward Path: A-B-C-D-G-H (upper path) Reverse Path: H-G-F-E-B-A (lower path)
正向路径：A-B-C-D-G-H（上层路径）反向路径：H-G-F-E-B-A（下层路径）
Figure 3: Non-Co-Routed Bidirectional LSP
图3：非共路由双向LSP
Some operators may prefer and configure "Reply via Specified Path" as the default Reply Mode but without including the Reply Path TLV, to indicate that the reverse LSP is used as the return path when MPLS echo request messages are sent on bidirectional LSPs. Without the extensions described in this document, the following behaviors will be seen:
一些运营商可能更喜欢并配置“通过指定路径回复”作为默认回复模式，但不包括回复路径TLV，以指示在双向LSP上发送MPLS回送请求消息时，反向LSP用作返回路径。如果没有本文档中描述的扩展，将看到以下行为：
o When LSP Ping is issued from A, the reply will come back on the reverse LSP from H.
o 当从A发出LSP Ping时，回复将以反向LSP从H返回。
o When LSP Traceroute is issued from A, the replies will come back on the reverse LSP from B, G, and H but will encounter a timeout from C and D, as there are no reverse LSPs on those nodes.
o 当从A发出LSP跟踪路由时，应答将从B、G和H以反向LSP返回，但将遇到来自C和D的超时，因为这些节点上没有反向LSP。
o When LSP Ping with a specific TTL value is issued from A, whether a timeout will be encountered depends on the value of the TTL used (i.e., whether or not the MPLS echo request terminates on a node that has a reverse LSP).
o 当从发出具有特定TTL值的LSP Ping时，是否会遇到超时取决于所使用的TTL的值（即，MPLS echo请求是否在具有反向LSP的节点上终止）。
One can argue that the initiator LSR can automatically generate the same MPLS echo request with a different Reply Mode value to those nodes that time out. However, such a mechanism will result in an extended time for the entire operation to complete (i.e., multiple seconds to multiple minutes). This is undesirable, and perhaps unacceptable if the "user" is an application.
可以说，发起方LSR可以自动生成相同的MPLS回显请求，并向超时的节点提供不同的应答模式值。然而，这种机制将导致整个操作完成的时间延长（即，从几秒到几分钟）。如果“用户”是一个应用程序，这是不可取的，并且可能是不可接受的。
With the extensions described in this document, the same procedures can be performed with the Reply Mode Order TLV carrying {5, 2}. When LSP Traceroute is issued, then the following output may be displayed without any unnecessary timeout:
通过本文档中描述的扩展，可以对带有{5，2}的回复模式命令TLV执行相同的过程。发出LSP跟踪路由时，可能会显示以下输出，而不会出现任何不必要的超时：
Success (Reply Mode: 5) Success (Reply Mode: 2) Success (Reply Mode: 2) Success (Reply Mode: 5) Success (Reply Mode: 5) Complete
成功（回复模式：5）成功（回复模式：2）成功（回复模式：2）成功（回复模式：5）成功（回复模式：5）完成
Acknowledgements
致谢
The authors especially thank Tom Taylor, who passed away close to the time of publication of this RFC. Tom did a careful review of the document and provided useful comments.
作者特别感谢Tom Taylor，他在本RFC出版时去世。汤姆仔细审阅了这份文件，并提出了有用的意见。
The authors would also like to thank Santiago Alvarez and Faisal Iqbal for discussions that motivated the creation of this document; Sam Aldrin, Curtis Villamizar, Ross Callon, Jeffrey Zhang, Jeremy Whittaker, Mustapha Alissaoui, Qin Wu, Jie Dong, and Adrian Farrel for providing valuable comments that influenced the content of the document; and Dan Frost, Victor Kuarsingh, and Deborah Brungard for reviewing the document and providing useful comments.
作者还要感谢Santiago Alvarez和Faisal Iqbal的讨论，这些讨论推动了本文件的编写；Sam Aldrin、Curtis Villamizar、Ross Callon、Jeffrey Zhang、Jeremy Whittaker、Mustapha Alissaoui、Qin Wu、Jie Dong和Adrian Farrel提供了影响文件内容的宝贵意见；Dan Frost、Victor Kuarsingh和Deborah Brungard对该文件进行了审查，并提供了有用的意见。
Contributors
贡献者
Shaleen Saxena Brocade
沙琳萨克塞纳织锦
Email: ssaxena@brocade.com
Email: ssaxena@brocade.com
Authors' Addresses
作者地址
Nobo Akiya Big Switch Networks
Nobo Akiya大交换网络
Email: nobo.akiya.dev@gmail.com
Email: nobo.akiya.dev@gmail.com
George Swallow Cisco Systems
思科系统公司
Email: swallow@cisco.com
Email: swallow@cisco.com
Carlos Pignataro Cisco Systems
卡洛斯·皮格纳塔罗思科系统公司
Email: cpignata@cisco.com
Email: cpignata@cisco.com
Loa Andersson Huawei
安徒生华为酒店
Email: loa@mail01.huawei.com
Email: loa@mail01.huawei.com
Mach(Guoyi) Chen Huawei
马赫（国一）陈华为
Email: mach.chen@huawei.com
Email: mach.chen@huawei.com