Internet Engineering Task Force (IETF) N. Kumar, Ed.
Request for Comments: 8287 C. Pignataro, Ed.
Category: Standards Track Cisco
ISSN: 2070-1721 G. Swallow
Southend Technical Center
N. Akiya
Big Switch Networks
S. Kini
Individual
M. Chen
Huawei
December 2017
Internet Engineering Task Force (IETF) N. Kumar, Ed.
Request for Comments: 8287 C. Pignataro, Ed.
Category: Standards Track Cisco
ISSN: 2070-1721 G. Swallow
Southend Technical Center
N. Akiya
Big Switch Networks
S. Kini
Individual
M. Chen
Huawei
December 2017
Label Switched Path (LSP) Ping/Traceroute for Segment Routing (SR) IGP-Prefix and IGP-Adjacency Segment Identifiers (SIDs) with MPLS Data Planes
使用MPLS数据平面为段路由（SR）IGP前缀和IGP邻接段标识符（SID）标记交换路径（LSP）Ping/Traceroute
Abstract
摘要
A Segment Routing (SR) architecture leverages source routing and tunneling paradigms and can be directly applied to the use of a Multiprotocol Label Switching (MPLS) data plane. A node steers a packet through a controlled set of instructions called "segments" by prepending the packet with an SR header.
段路由（SR）体系结构利用源路由和隧道范例，可直接应用于多协议标签交换（MPLS）数据平面的使用。节点通过在数据包前面加上SR报头来控制数据包通过一组称为“段”的受控指令。
The segment assignment and forwarding semantic nature of SR raises additional considerations for connectivity verification and fault isolation for a Label Switched Path (LSP) within an SR architecture. This document illustrates the problem and defines extensions to perform LSP Ping and Traceroute for Segment Routing IGP-Prefix and IGP-Adjacency Segment Identifiers (SIDs) with an MPLS data plane.
SR的段分配和转发语义特性为SR体系结构中的标签交换路径（LSP）的连接验证和故障隔离提出了额外的考虑因素。本文档说明了该问题，并定义了使用MPLS数据平面对段路由IGP前缀和IGP邻接段标识符（SID）执行LSP Ping和Traceroute的扩展。
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/rfc8287.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8287.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 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 . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Coexistence of SR-Capable and Non-SR-Capable Node
Scenarios . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Challenges with Existing Mechanisms . . . . . . . . . . . . . 5
4.1. Path Validation in Segment Routing Networks . . . . . . . 5
5. Segment ID Sub-TLV . . . . . . . . . . . . . . . . . . . . . 7
5.1. IPv4 IGP-Prefix Segment ID . . . . . . . . . . . . . . . 7
5.2. IPv6 IGP-Prefix Segment ID . . . . . . . . . . . . . . . 8
5.3. IGP-Adjacency Segment ID . . . . . . . . . . . . . . . . 9
6. Extension to Downstream Detailed Mapping TLV . . . . . . . . 11
7. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.1. FECs in Target FEC Stack TLV . . . . . . . . . . . . . . 11
7.2. FEC Stack Change Sub-TLV . . . . . . . . . . . . . . . . 12
7.3. Segment ID POP Operation . . . . . . . . . . . . . . . . 13
7.4. Segment ID Check . . . . . . . . . . . . . . . . . . . . 13
7.5. TTL Consideration for Traceroute . . . . . . . . . . . . 19
8. Backward Compatibility with Non-SR Devices . . . . . . . . . 19
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
9.1. New Target FEC Stack Sub-TLVs . . . . . . . . . . . . . . 20
9.2. Protocol in the Segment ID Sub-TLV . . . . . . . . . . . 20
9.3. Adjacency Type in the IGP-Adjacency Segment ID . . . . . 20
9.4. Protocol in the Label Stack Sub-TLV of the Downstream
Detailed Mapping TLV . . . . . . . . . . . . . . . . . . 21
9.5. Return Code . . . . . . . . . . . . . . . . . . . . . . . 21
10. Security Considerations . . . . . . . . . . . . . . . . . . . 21
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
11.1. Normative References . . . . . . . . . . . . . . . . . . 22
11.2. Informative References . . . . . . . . . . . . . . . . . 22
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 24
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Coexistence of SR-Capable and Non-SR-Capable Node
Scenarios . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Challenges with Existing Mechanisms . . . . . . . . . . . . . 5
4.1. Path Validation in Segment Routing Networks . . . . . . . 5
5. Segment ID Sub-TLV . . . . . . . . . . . . . . . . . . . . . 7
5.1. IPv4 IGP-Prefix Segment ID . . . . . . . . . . . . . . . 7
5.2. IPv6 IGP-Prefix Segment ID . . . . . . . . . . . . . . . 8
5.3. IGP-Adjacency Segment ID . . . . . . . . . . . . . . . . 9
6. Extension to Downstream Detailed Mapping TLV . . . . . . . . 11
7. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.1. FECs in Target FEC Stack TLV . . . . . . . . . . . . . . 11
7.2. FEC Stack Change Sub-TLV . . . . . . . . . . . . . . . . 12
7.3. Segment ID POP Operation . . . . . . . . . . . . . . . . 13
7.4. Segment ID Check . . . . . . . . . . . . . . . . . . . . 13
7.5. TTL Consideration for Traceroute . . . . . . . . . . . . 19
8. Backward Compatibility with Non-SR Devices . . . . . . . . . 19
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
9.1. New Target FEC Stack Sub-TLVs . . . . . . . . . . . . . . 20
9.2. Protocol in the Segment ID Sub-TLV . . . . . . . . . . . 20
9.3. Adjacency Type in the IGP-Adjacency Segment ID . . . . . 20
9.4. Protocol in the Label Stack Sub-TLV of the Downstream
Detailed Mapping TLV . . . . . . . . . . . . . . . . . . 21
9.5. Return Code . . . . . . . . . . . . . . . . . . . . . . . 21
10. Security Considerations . . . . . . . . . . . . . . . . . . . 21
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
11.1. Normative References . . . . . . . . . . . . . . . . . . 22
11.2. Informative References . . . . . . . . . . . . . . . . . 22
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 24
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
"Detecting Multiprotocol Label Switched (MPLS) Data-Plane Failures" [RFC8029] defines a simple and efficient mechanism to detect data-plane failures in Label Switched Paths (LSPs) by specifying information to be carried in an MPLS "echo request" and "echo reply" for the purposes of fault detection and isolation. Mechanisms for reliably sending the echo reply are defined. The functionality defined in [RFC8029] is modeled after the Ping/Traceroute paradigm (ICMP echo request [RFC792]) and is typically referred to as "LSP Ping" and "LSP Traceroute". [RFC8029] supports hierarchical and stitching LSPs.
“检测多协议标签交换（MPLS）数据平面故障”[RFC8029]定义了一种简单有效的机制，通过指定MPLS“回送请求”和“回送回复”中要携带的信息来检测标签交换路径（LSP）中的数据平面故障，以便进行故障检测和隔离。定义了可靠发送回显应答的机制。[RFC8029]中定义的功能按照Ping/Traceroute范式（ICMP echo request[RFC792]）建模，通常称为“LSP Ping”和“LSP Traceroute”。[RFC8029]支持分层和缝合LSP。
[SR] introduces and describes an SR architecture that leverages the source routing and tunneling paradigms. A node steers a packet through a controlled set of instructions called "segments" by prepending the packet with an SR header. A detailed definition of the SR architecture is available in [SR].
[SR]介绍并描述了利用源路由和隧道范例的SR体系结构。节点通过在数据包前面加上SR报头来控制数据包通过一组称为“段”的受控指令。SR架构的详细定义见[SR]。
As described in [SR] and [SR-MPLS], the SR architecture can be directly applied to an MPLS data plane, the SID will be 20 bits, and the SR header is the label stack. Consequently, the mechanics of data-plane validation of [RFC8029] can be directly applied to SR MPLS.
如[SR]和[SR-MPLS]中所述，SR体系结构可直接应用于MPLS数据平面，SID为20位，SR报头为标签堆栈。因此，[RFC8029]的数据平面验证机制可以直接应用于SR MPLS。
Unlike LDP or RSVP, which are the other well-known MPLS control plane protocols, the basis of Segment ID assignment in SR architecture is not always on a hop-by-hop basis. Depending on the type of Segment ID, the assignment can be unique to the node or within a domain.
与其他众所周知的MPLS控制平面协议LDP或RSVP不同，SR体系结构中的段ID分配的基础并不总是逐跳的。根据段ID的类型，分配可以是节点或域内唯一的。
This nature of SR raises additional considerations for validation of fault detection and isolation in an SR network. This document illustrates the problem and describes a mechanism to perform LSP Ping and Traceroute for Segment Routing IGP-Prefix and IGP-Adjacency SIDs within an MPLS data plane.
SR的这种性质为验证SR网络中的故障检测和隔离提出了额外的考虑因素。本文档说明了该问题，并描述了在MPLS数据平面内为段路由IGP前缀和IGP邻接SID执行LSP Ping和Traceroute的机制。
[INTEROP] describes how SR operates in a network where SR-capable and non-SR-capable nodes coexist. In such a network, one or more SR-based LSPs and non-SR-based LSPs are stitched together to achieve an end-to-end LSP. This is similar to a network where LDP and RSVP nodes coexist and the mechanism defined in Section 4.5.2 of [RFC8029] is applicable for LSP Ping and Trace.
[INTEROP]描述SR如何在支持SR和不支持SR的节点共存的网络中运行。在这样的网络中，将一个或多个基于SR的LSP和非基于SR的LSP缝合在一起以实现端到端LSP。这类似于LDP和RSVP节点共存的网络，[RFC8029]第4.5.2节中定义的机制适用于LSP Ping和Trace。
Section 8 of this document explains one of the potential gaps that is specific to SR-Capable and non-SR-capable node scenarios and explains how the existing mechanism defined in [RFC8029] handles it.
本文档第8节解释了特定于支持SR和不支持SR的节点场景的潜在差距之一，并解释了[RFC8029]中定义的现有机制如何处理这些差距。
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]所述进行解释。
This document uses the terminology defined in [SR] and [RFC8029]; readers are expected to be familiar with those terms.
本文件使用[SR]和[RFC8029]中定义的术语；读者应该熟悉这些术语。
The following example describes the challenges with using the current MPLS Operations, Administration, and Maintenance (OAM) mechanisms on an SR network.
以下示例描述了在SR网络上使用当前MPLS操作、管理和维护（OAM）机制所面临的挑战。
[RFC8029] defines the MPLS OAM mechanisms that help with fault detection and isolation for an MPLS data-plane path by the use of various Target Forwarding Equivalence Class (FEC) Stack sub-TLVs that are carried in MPLS echo request packets and used by the responder for FEC validation. While it is obvious that new sub-TLVs need to be assigned for SR, the unique nature of the SR architecture raises the need for additional operational considerations for path validation. This section discusses the challenges.
[RFC8029]定义了MPLS OAM机制，该机制通过使用MPLS回波请求数据包中携带并由响应者用于FEC验证的各种目标转发等价类（FEC）堆栈子TLV，帮助MPLS数据平面路径的故障检测和隔离。虽然显然需要为SR分配新的子TLV，但SR体系结构的独特性质提出了路径验证的额外操作考虑。本节讨论这些挑战。
L1
+--------+
| L2 |
R3-------R6
/ \
/ \
R1----R2 R7----R8
\ /
\ /
R4-------R5
L1
+--------+
| L2 |
R3-------R6
/ \
/ \
R1----R2 R7----R8
\ /
\ /
R4-------R5
Figure 1: Segment Routing Network
图1：分段路由网络
The Node Segment IDs for R1, R2, R3, R4, R5, R6, R7, and R8 are 5001, 5002, 5003, 5004, 5005, 5006, 5007, and 5008, respectively.
R1、R2、R3、R4、R5、R6、R7和R8的节点段ID分别为5001、5002、5003、5004、5005、5006、5007和5008。
9136 --> Adjacency Segment ID from R3 to R6 over link L1. 9236 --> Adjacency Segment ID from R3 to R6 over link L2. 9124 --> Adjacency segment ID from R2 to R4. 9123 --> Adjacency Segment ID from R2 to R3.
9136-->链路L1上从R3到R6的邻接段ID。9236-->链路L2上从R3到R6的邻接段ID。9124-->从R2到R4的邻接段ID。9123-->从R2到R3的邻接段ID。
The forwarding semantic of the Adjacency Segment ID is to pop the Segment ID and send the packet to a specific neighbor over a specific link. A malfunctioning node may forward packets using the Adjacency Segment ID to an incorrect neighbor or over an incorrect link. The exposed Segment ID (of an incorrectly forwarded Adjacency Segment ID) might still allow such a packet to reach the intended destination, even though the intended strict traversal was broken.
邻接段ID的转发语义是弹出段ID并通过特定链路将数据包发送给特定邻居。发生故障的节点可能会使用邻接段ID将数据包转发给不正确的邻居或通过不正确的链路。暴露的段ID（不正确转发的邻接段ID）可能仍然允许这样的数据包到达预期的目的地，即使预期的严格遍历被破坏。
In the topology above, assume that R1 sends traffic with a segment stack as {9124, 5008} so that the path taken will be R1-R2-R4-R5-R7-R8. If the Adjacency Segment ID 9124 is misprogrammed in R2 to send the packet to R1 or R3, the packet may still be delivered to R8 (if the nodes are configured with the same SR Global Block (SRGB)) [SR] but not via the expected path.
在上面的拓扑中，假设R1使用段堆栈{91245008}发送流量，因此所采用的路径为R1-R2-R4-R5-R7-R8。如果在R2中对邻接段ID 9124进行了错误编程以将分组发送到R1或R3，则分组仍然可以被发送到R8（如果节点被配置为具有相同的SR全局块（SRGB））[SR]，但不通过预期路径。
MPLS traceroute may help with detecting such a deviation in the above-mentioned scenario. However, in a different example, it may not be helpful, for example, if R3 forwards a packet with Adjacency Segment ID 9236 via link L1 (due to misprogramming) when it was expected to be forwarded over link L2.
MPLS跟踪路由可有助于在上述场景中检测这种偏差。然而，在不同的示例中，例如，如果R3在预期通过链路L2转发时经由链路L1转发具有邻接段ID 9236的分组（由于编程错误），则这可能没有帮助。
The format of the following Segment ID sub-TLVs follows the philosophy of the Target FEC Stack TLV carrying FECs corresponding to each label in the label stack. When operated with the procedures defined in [RFC8029], this allows LSP Ping/Traceroute operations to function when the Target FEC Stack TLV contains more FECs than received label stacks at the responder nodes.
以下段ID子TLV的格式遵循目标FEC堆栈TLV的原理，该目标FEC堆栈TLV承载对应于标签堆栈中每个标签的FEC。当使用[RFC8029]中定义的程序操作时，当目标FEC堆栈TLV包含的FEC多于响应节点处接收的标签堆栈时，这允许LSP Ping/Traceroute操作起作用。
Three new sub-TLVs are defined for the Target FEC Stack TLV (Type 1), the Reverse-Path Target FEC Stack TLV (Type 16), and the Reply Path TLV (Type 21).
为目标FEC堆栈TLV（类型1）、反向路径目标FEC堆栈TLV（类型16）和应答路径TLV（类型21）定义了三个新的子TLV。
Sub-Type Sub-TLV Name
-------- ---------------
34 IPv4 IGP-Prefix Segment ID
35 IPv6 IGP-Prefix Segment ID
36 IGP-Adjacency Segment ID
Sub-Type Sub-TLV Name
-------- ---------------
34 IPv4 IGP-Prefix Segment ID
35 IPv6 IGP-Prefix Segment ID
36 IGP-Adjacency Segment ID
See Section 9.2 for the registry for the Protocol field specified within these sub-TLVs.
有关这些子TLV中指定的协议字段的注册表，请参见第9.2节。
The IPv4 IGP-Prefix Segment ID is defined in [SR]. The format is as specified below:
IPv4 IGP前缀段ID在[SR]中定义。格式如下所示：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Prefix Length | Protocol | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Prefix Length | Protocol | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4 Prefix
IPv4前缀
This field carries the IPv4 Prefix to which the Segment ID is assigned. In case of an Anycast Segment ID, this field will carry the IPv4 Anycast address. If the prefix is shorter than 32 bits, trailing bits SHOULD be set to zero.
此字段包含分配了段ID的IPv4前缀。如果是选播段ID，此字段将携带IPv4选播地址。如果前缀短于32位，则尾随位应设置为零。
Prefix Length
前缀长度
The Prefix Length field is one octet. It gives the length of the prefix in bits (values can be 1-32).
前缀长度字段是一个八位字节。它以位为单位给出前缀的长度（值可以是1-32）。
Protocol
协议
This field is set to 1, if the responder MUST perform FEC validation using OSPF as the IGP protocol. Set to 2, if the responder MUST perform Egress FEC validation using the Intermediate System to Intermediate System (IS-IS) as the IGP protocol. Set to 0, if the responder can use any IGP protocol for Egress FEC validation.
如果响应者必须使用OSPF作为IGP协议执行FEC验证，则该字段设置为1。如果响应者必须使用中间系统到中间系统（IS-IS）作为IGP协议执行出口FEC验证，则设置为2。如果响应者可以使用任何IGP协议进行出口FEC验证，则设置为0。
Reserved
含蓄的
The Reserved field MUST be set to 0 when sent and MUST be ignored on receipt.
发送时必须将保留字段设置为0，并且在接收时必须忽略该字段。
The IPv6 IGP-Prefix Segment ID is defined in [SR]. The format is as specified below:
IPv6 IGP前缀段ID在[SR]中定义。格式如下所示：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 Prefix |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Prefix Length | Protocol | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 Prefix |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Prefix Length | Protocol | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6 Prefix
IPv6前缀
This field carries the IPv6 prefix to which the Segment ID is assigned. In case of an Anycast Segment ID, this field will carry the IPv4 Anycast address. If the prefix is shorter than 128 bits, trailing bits SHOULD be set to zero.
此字段包含分配了段ID的IPv6前缀。如果是选播段ID，此字段将携带IPv4选播地址。如果前缀短于128位，则尾随位应设置为零。
Prefix Length
前缀长度
The Prefix Length field is one octet, it gives the length of the prefix in bits (values can be 1-128).
前缀长度字段是一个八位字节，它以位为单位给出前缀的长度（值可以是1-128）。
Protocol
协议
Set to 1 if the responder MUST perform FEC validation using OSPF as the IGP protocol. Set to 2 if the responder MUST perform Egress FEC validation using IS-IS as the IGP protocol. Set to 0 if the responder can use any IGP protocol for Egress FEC validation.
如果响应者必须使用OSPF作为IGP协议执行FEC验证，则设置为1。如果响应者必须使用IS-IS作为IGP协议执行出口FEC验证，则设置为2。如果响应者可以使用任何IGP协议进行出口FEC验证，则设置为0。
Reserved
含蓄的
MUST be set to 0 on send and MUST be ignored on receipt.
发送时必须设置为0，接收时必须忽略。
This sub-TLV is applicable for any IGP-Adjacency defined in [SR]. The format is as specified below:
该子TLV适用于[SR]中定义的任何IGP邻接。格式如下所示：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Adj. Type | Protocol | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
| Local Interface ID (4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
| Remote Interface ID (4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
| Advertising Node Identifier (4 or 6 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
| Receiving Node Identifier (4 or 6 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Adj. Type | Protocol | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
| Local Interface ID (4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
| Remote Interface ID (4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
| Advertising Node Identifier (4 or 6 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
| Receiving Node Identifier (4 or 6 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Adj. Type (Adjacency Type)
形容词。类型（邻接类型）
Set to 1 when the Adjacency Segment is a Parallel Adjacency as defined in [SR]. Set to 4 when the Adjacency Segment is IPv4 based and is not a Parallel Adjacency. Set to 6 when the Adjacency Segment is IPv6 based and is not a Parallel Adjacency. Set to 0 when the Adjacency Segment is over an unnumbered interface.
当邻接线段是[SR]中定义的平行邻接时，设置为1。当邻接段基于IPv4且不是平行邻接段时，设置为4。当邻接段基于IPv6且不是平行邻接时，设置为6。当相邻段位于未编号的接口上时，设置为0。
Protocol
协议
Set to 1 if the responder MUST perform FEC validation using OSPF as the IGP protocol. Set to 2 if the responder MUST perform Egress FEC validation using IS-IS as the IGP protocol. Set to 0 if the responder can use any IGP protocol for Egress FEC validation.
如果响应者必须使用OSPF作为IGP协议执行FEC验证，则设置为1。如果响应者必须使用IS-IS作为IGP协议执行出口FEC验证，则设置为2。如果响应者可以使用任何IGP协议进行出口FEC验证，则设置为0。
Reserved
含蓄的
MUST be set to 0 on send and MUST be ignored on receipt.
发送时必须设置为0，接收时必须忽略。
Local Interface ID
本地接口ID
An identifier that is assigned by the local Label Switching Router (LSR) for a link to which the Adjacency Segment ID is bound. This field is set to a local link address (IPv4 or IPv6). For IPv4, this field is 4 octets; for IPv6, this field is 16 octets. If unnumbered, this field is 4 octets and includes a 32-bit link identifier as defined in [RFC4203] and [RFC5307]. If the Adjacency Segment ID represents Parallel Adjacencies [SR], this field is 4 octets and MUST be set to 4 octets of zeroes.
由本地标签交换路由器（LSR）为邻接段ID绑定到的链路分配的标识符。此字段设置为本地链路地址（IPv4或IPv6）。对于IPv4，此字段为4个八位字节；对于IPv6，此字段为16个八位字节。如果未编号，该字段为4个八位字节，包括[RFC4203]和[RFC5307]中定义的32位链路标识符。如果邻接段ID表示平行邻接[SR]，则此字段为4个八位字节，必须设置为4个八位字节的零。
Remote Interface ID
远程接口ID
An identifier that is assigned by the remote LSR for a link on which the Adjacency Segment ID is bound. This field is set to the remote (downstream neighbor) link address (IPv4 or IPv6). For IPv4, this field is 4 octets; for IPv6, this field is 16 octets. If unnumbered, this field is 4 octets and includes a 32-bit link identifier as defined in [RFC4203] and [RFC5307]. If the Adjacency Segment ID represents Parallel Adjacencies [SR], this field is 4 octets and MUST be set to 4 octets of zeroes.
一种标识符，由远程LSR为相邻段ID绑定的链路分配。此字段设置为远程（下游邻居）链路地址（IPv4或IPv6）。对于IPv4，此字段为4个八位字节；对于IPv6，此字段为16个八位字节。如果未编号，该字段为4个八位字节，包括[RFC4203]和[RFC5307]中定义的32位链路标识符。如果邻接段ID表示平行邻接[SR]，则此字段为4个八位字节，必须设置为4个八位字节的零。
Advertising Node Identifier
广告节点标识符
This specifies the Advertising Node Identifier. When the Protocol field is set to 1, then this field is 4 octets and carries the 32-bit OSPF Router ID. If the Protocol field is set to 2, then this field is 6 octets and carries the 48-bit IS-IS System ID. If the Protocol field is set to 0, then this field is 4 octets and MUST be set to zero.
这将指定播发节点标识符。当协议字段设置为1时，则该字段为4个八位字节，携带32位OSPF路由器ID。如果协议字段设置为2，则该字段为6个八位字节，携带48位is-is系统ID。如果协议字段设置为0，则该字段为4个八位字节，必须设置为零。
Receiving Node Identifier
接收节点标识符
This specifies the downstream node identifier. When the Protocol field is set to 1, then this field is 4 octets and carries the 32-bit OSPF Router ID. If the Protocol field is set to 2, then this field is 6 octets and carries the 48-bit IS-IS System ID. If the Protocol field is set to 0, then this field is 4 octets and MUST be set to zero.
这将指定下游节点标识符。当协议字段设置为1时，则该字段为4个八位字节，携带32位OSPF路由器ID。如果协议字段设置为2，则该字段为6个八位字节，携带48位is-is系统ID。如果协议字段设置为0，则该字段为4个八位字节，必须设置为零。
In an echo reply, the Downstream Detailed Mapping TLV [RFC8029] is used to report for each interface over which a FEC could be forwarded. For a FEC, there are multiple protocols that may be used to distribute label mapping. The Protocol field of the Downstream Detailed Mapping TLV is used to return the protocol that is used to distribute the label carried in the Downstream Label field. The following protocols are defined in [RFC8029]:
在回送应答中，下游详细映射TLV[RFC8029]用于报告每个可转发FEC的接口。对于FEC，可以使用多个协议来分发标签映射。下游详细映射TLV的协议字段用于返回用于分发下游标签字段中携带的标签的协议。[RFC8029]中定义了以下协议：
Protocol # Signaling Protocol
---------- ------------------
0 Unknown
1 Static
2 BGP
3 LDP
4 RSVP-TE
Protocol # Signaling Protocol
---------- ------------------
0 Unknown
1 Static
2 BGP
3 LDP
4 RSVP-TE
With SR, OSPF or IS-IS can be used for label distribution. This document adds two new protocols as follows:
通过SR，OSPF或IS-IS可用于标签分发。本文档添加了两个新协议，如下所示：
Protocol # Signaling Protocol
---------- ------------------
5 OSPF
6 IS-IS
Protocol # Signaling Protocol
---------- ------------------
5 OSPF
6 IS-IS
See Section 9.4.
见第9.4节。
This section describes aspects of LSP Ping and Traceroute operations that require further considerations beyond [RFC8029].
本节描述了LSP Ping和跟踪路由操作的各个方面，这些方面需要[RFC8029]以外的进一步考虑。
When LSP echo request packets are generated by an initiator, FECs carried in the Target FEC Stack TLV may need to differ to support an SR architecture. The following defines the Target FEC Stack TLV construction mechanics by an initiator for SR scenarios.
当发起方生成LSP回波请求分组时，目标FEC堆栈TLV中携带的FEC可能需要不同以支持SR架构。以下定义了发起人针对SR场景的目标FEC堆栈TLV构造机制。
Ping
发出砰的声响
The initiator MUST include FEC(s) corresponding to the destination segment.
启动器必须包括与目标段对应的FEC。
The initiator MAY include FECs corresponding to some or all of the segments imposed in the label stack by the initiator to communicate the segments traversed.
发起者可以包括与发起者施加在标签堆栈中的部分或全部段相对应的fec，以通信所穿越的段。
Traceroute
追踪路线
The initiator MUST initially include FECs corresponding to all segments imposed in the label stack.
启动器最初必须包括与标签堆栈中施加的所有段相对应的FEC。
When a received echo reply contains the FEC Stack Change TLV with one or more of the original segments being popped, the initiator MAY remove a corresponding FEC(s) from the Target FEC Stack TLV in the next (TTL+1) traceroute request, as defined in Section 4.6 of [RFC8029].
当接收到的回音应答包含FEC堆栈更改TLV且弹出一个或多个原始段时，启动器可在下一个（TTL+1）跟踪路由请求中从目标FEC堆栈TLV中移除相应的FEC，如[RFC8029]第4.6节中所定义。
When a received echo reply does not contain the FEC Stack Change TLV, the initiator MUST NOT attempt to remove any FECs from the Target FEC Stack TLV in the next (TTL+1) traceroute request.
当收到的回显回复不包含FEC堆栈更改TLV时，发起方不得在下一个（TTL+1）跟踪路由请求中尝试从目标FEC堆栈TLV中删除任何FEC。
As defined in [SR-OSPF] and [SR-IS-IS], the Prefix SID can be advertised as an absolute value, an index, or as a range. In any of these cases, the initiator MUST derive the Prefix mapped to the Prefix SID and use it in the IGP-Prefix Segment ID defined in Sections 5.1 and 5.2. How the responder uses the details in the SR-FEC sub-TLV to perform the validation is a local implementation matter.
如[SR-OSPF]和[SR-IS-IS]中所定义，前缀SID可以作为绝对值、索引或范围进行公布。在上述任何情况下，启动器必须派生映射到前缀SID的前缀，并在第5.1节和第5.2节中定义的IGP前缀段ID中使用它。响应者如何使用SR-FEC子TLV中的细节来执行验证是本地实现问题。
[RFC8029] defines a FEC Stack Change sub-TLV that a router must include when the FEC stack changes.
[RFC8029]定义FEC堆栈更改子TLV，路由器在FEC堆栈更改时必须包括该子TLV。
The network node that advertised the Node Segment ID is responsible for generating a FEC Stack Change sub-TLV with the Post Office Protocol (POP) operation type for the Node Segment ID, regardless of whether or not Penultimate Hop Popping (PHP) is enabled.
公布节点段ID的网络节点负责为节点段ID生成具有邮局协议（POP）操作类型的FEC堆栈更改子TLV，无论是否启用倒数第二跳弹出（PHP）。
The network node that is immediately downstream of the node that advertised the Adjacency Segment ID is responsible for generating the FEC Stack Change sub-TLV for POP operation for the Adjacency Segment ID.
紧邻公布邻接段ID的节点下游的网络节点负责为邻接段ID的POP操作生成FEC堆栈更改子TLV。
The forwarding semantic of the Node Segment ID with the PHP flag is equivalent to usage of Implicit Null in MPLS protocols. The Adjacency Segment ID is also similar in a sense that it can be thought of as a locally allocated segment that has PHP enabled when destined for the next-hop IGP Adjacency Node. Procedures described in Section 4.4 of [RFC8029] rely on the Stack-D and Stack-R explicitly having the Implicit Null value. Implementations SHOULD use the Implicit Null for the Node Segment ID PHP and Adjacency Segment ID PHP cases.
带有PHP标志的节点段ID的转发语义相当于在MPLS协议中使用隐式Null。邻接段ID在某种意义上也很相似，它可以被认为是本地分配的段，在发送到下一跳IGP邻接节点时启用了PHP。[RFC8029]第4.4节中描述的过程依赖于堆栈D和堆栈R显式地具有隐式空值。实现应该为节点段ID PHP和邻接段ID PHP用例使用隐式Null。
This section modifies the procedure defined in Section 4.4.1 of [RFC8029]. Step 4 defined in Section 4.4.1 of [RFC8029] is modified as below:
本节修改了[RFC8029]第4.4.1节中定义的程序。[RFC8029]第4.4.1节中定义的步骤4修改如下：
4. If the label mapping for FEC is Implicit Null, set the FEC-status to 2 and proceed to step 4a. Otherwise, if the label mapping for FEC is Label-L, proceed to step 4a. Otherwise, set the FEC-return-code to 10 ("Mapping for this FEC is not the given label at stack-depth"), set the FEC-status to 1, and return.
4. 如果FEC的标签映射为隐式Null，则将FEC状态设置为2并转至步骤4a。否则，如果FEC的标签映射为label-L，则转至步骤4a。否则，将FEC返回代码设置为10（“此FEC的映射不是堆栈深度处的给定标签”），将FEC状态设置为1，然后返回。
4a. Segment Routing IGP-Prefix and IGP-Adjacency SID Validation:
4a。段路由IGP前缀和IGP邻接SID验证：
If the Label-stack-depth is 0 and the Target FEC Stack sub-TLV at FEC-stack-depth is 34 (IPv4 IGP-Prefix Segment ID), {
如果标签堆栈深度为0，且FEC堆栈深度处的目标FEC堆栈子TLV为34（IPv4 IGP前缀段ID）{
Set the Best-return-code to 10, "Mapping for this FEC is not the given label at stack-depth <RSC>" if any below conditions fail:
将最佳返回代码设置为10，“如果以下任何条件失败，则此FEC的映射不是堆栈深度<RSC>处的给定标签”：
/* The responder LSR is to check if it is the egress of the
IPv4 IGP-Prefix Segment ID described in the Target FEC Stack
sub-TLV, and if the FEC was advertised with the PHP bit
set.*/
/* The responder LSR is to check if it is the egress of the
IPv4 IGP-Prefix Segment ID described in the Target FEC Stack
sub-TLV, and if the FEC was advertised with the PHP bit
set.*/
- Validate that the Node Segment ID is advertised for the IPv4 Prefix by IGP Protocol {
- 验证是否通过IGP协议播发IPv4前缀的节点段ID{
o When the Protocol field in the received IPv4 IGP-Prefix Segment ID sub-TLV is 0, use any locally enabled IGP protocol.
o 当收到的IPv4 IGP前缀段ID子TLV中的协议字段为0时，请使用任何本地启用的IGP协议。
o When the Protocol field in the received IPv4 IGP-Prefix Segment ID sub-TLV is 1, use OSPF as the IGP protocol.
o 当收到的IPv4 IGP前缀段ID子TLV中的协议字段为1时，请使用OSPF作为IGP协议。
o When the Protocol field in the received IPv4 IGP-Prefix Segment ID sub-TLV is 2, use IS-IS as the IGP protocol.
o 当收到的IPv4 IGP前缀段ID子TLV中的协议字段为2时，使用is-is作为IGP协议。
o When the Protocol field in the received IPv4 IGP-Prefix Segment ID sub-TLV is an unrecognized value, it MUST be treated as a Protocol value of 0.
o 当收到的IPv4 IGP前缀段ID子TLV中的协议字段为无法识别的值时，必须将其视为协议值0。
}
}
- Validate that the Node Segment ID is advertised with the No-PHP flag. {
- 验证节点段ID是否使用No PHP标志播发。{
o When the Protocol is OSPF, the NP-Flag defined in Section 5 of [SR-OSPF] MUST be set to 0.
o 当协议为OSPF时，[SR-OSPF]第5节中定义的NP标志必须设置为0。
o When the Protocol is IS-IS, the P-Flag defined in Section 6.1 of [SR-IS-IS] MUST be set to 0.
o 当协议为is-is时，[SR-is-is]第6.1节中定义的P标志必须设置为0。
}
}
If it can be determined that no protocol associated with the Interface-I would have advertised the FEC-Type at FEC-stack-depth, set the Best-return-code to 12, "Protocol not associated with interface at FEC-stack-depth" and return.
如果可以确定没有与接口关联的协议-I会在FEC堆栈深度播发FEC类型，则将最佳返回码设置为12，“与FEC堆栈深度的接口无关的协议”并返回。
Set FEC-Status to 1 and return.
将FEC状态设置为1并返回。
}
}
Else, if the Label-stack-depth is greater than 0 and the Target FEC Stack sub-TLV at FEC-stack-depth is 34 (IPv4 IGP-Prefix Segment ID), {
否则，如果标签堆栈深度大于0，且FEC堆栈深度处的目标FEC堆栈子TLV为34（IPv4 IGP前缀段ID）{
Set the Best-return-code to 10 if any below conditions fail:
如果以下任何条件失败，请将最佳返回代码设置为10：
- Validate that the Node Segment ID is advertised for the IPv4 Prefix by the IGP protocol {
- 验证IGP协议是否为IPv4前缀播发节点段ID{
o When the Protocol field in the received IPv4 IGP-Prefix Segment ID sub-TLV is 0, use any locally enabled IGP protocol.
o 当收到的IPv4 IGP前缀段ID子TLV中的协议字段为0时，请使用任何本地启用的IGP协议。
o When the Protocol field in the received IPv4 IGP-Prefix Segment ID sub-TLV is 1, use OSPF as the IGP protocol.
o 当收到的IPv4 IGP前缀段ID子TLV中的协议字段为1时，请使用OSPF作为IGP协议。
o When the Protocol field in the received IPv4 IGP-Prefix Segment ID sub-TLV is 2, use IS-IS as the IGP protocol.
o 当收到的IPv4 IGP前缀段ID子TLV中的协议字段为2时，使用is-is作为IGP协议。
o When the Protocol field in the received IPv4 IGP-Prefix Segment ID sub-TLV is an unrecognized value, it MUST be treated as a Protocol value of 0.
o 当收到的IPv4 IGP前缀段ID子TLV中的协议字段为无法识别的值时，必须将其视为协议值0。
}
}
If it can be determined that no protocol associated with Interface-I would have advertised the FEC-Type at FEC-stack-depth, set the Best-return-code to 12, "Protocol not associated with interface at FEC stack-depth" and return.
如果可以确定没有与接口I关联的协议会在FEC堆栈深度播发FEC类型，则将最佳返回码设置为12，“与FEC堆栈深度的接口不关联的协议”并返回。
Set FEC-Status to 1 and return.
将FEC状态设置为1并返回。
}
}
Else, if the Label-stack-depth is 0 and the Target FEC sub-TLV at FEC-stack-depth is 35 (IPv6 IGP-Prefix Segment ID), {
否则，如果标签堆栈深度为0，且FEC堆栈深度处的目标FEC子TLV为35（IPv6 IGP前缀段ID）{
Set the Best-return-code to 10 if any of the below conditions fail:
如果以下任一条件失败，则将最佳返回代码设置为10：
/* The LSR needs to check if it is being a tail-end for the
LSP and have the prefix advertised with the PHP bit set*/
/* The LSR needs to check if it is being a tail-end for the
LSP and have the prefix advertised with the PHP bit set*/
- Validate that the Node Segment ID is advertised for the IPv6 Prefix by the IGP protocol {
- 验证IGP协议是否为IPv6前缀播发节点段ID{
o When the Protocol field in the received IPv6 IGP-Prefix Segment ID sub-TLV is 0, use any locally enabled IGP protocol.
o 当收到的IPv6 IGP前缀段ID子TLV中的协议字段为0时，请使用任何本地启用的IGP协议。
o When the Protocol field in the received IPv6 IGP-Prefix Segment ID sub-TLV is 1, use OSPF as the IGP protocol.
o 当接收到的IPv6 IGP前缀段ID子TLV中的协议字段为1时，使用OSPF作为IGP协议。
o When the Protocol field in the received IPv6 IGP-Prefix Segment ID sub-TLV is 2, use IS-IS as the IGP protocol.
o 当收到的IPv6 IGP前缀段ID子TLV中的协议字段为2时，使用is-is作为IGP协议。
o When the Protocol field in the received IPv6 IGP-Prefix Segment ID sub-TLV is an unrecognized value, it MUST be treated as a Protocol value of 0.
o 当接收到的IPv6 IGP前缀段ID子TLV中的协议字段为无法识别的值时，必须将其视为协议值0。
}
}
- Validate that the Node Segment ID is advertised with the No-PHP flag. {
- 验证节点段ID是否使用No PHP标志播发。{
o When the Protocol is OSPF, the NP-flag defined in Section 5 of [SR-OSPFV3] MUST be set to 0.
o 当协议为OSPF时，[SR-OSPFV3]第5节中定义的NP标志必须设置为0。
o When the Protocol is IS-IS, the P-Flag defined in Section 6.1 of [SR-IS-IS] MUST be set to 0.
o 当协议为is-is时，[SR-is-is]第6.1节中定义的P标志必须设置为0。
}
}
If it can be determined that no protocol associated with Interface-I would have advertised the FEC-Type at FEC-stack-depth, set the Best-return-code to 12, "Protocol not associated with interface at FEC stack-depth" and return.
如果可以确定没有与接口I关联的协议会在FEC堆栈深度播发FEC类型，则将最佳返回码设置为12，“与FEC堆栈深度的接口不关联的协议”并返回。
Set the FEC-Status to 1 and return.
将FEC状态设置为1并返回。
}
}
Else, if the Label-stack-depth is greater than 0 and the Target FEC sub-TLV at FEC-stack-depth is 35 (IPv6 IGP-Prefix Segment ID), {
否则，如果标签堆栈深度大于0，且FEC堆栈深度处的目标FEC子TLV为35（IPv6 IGP前缀段ID）{
Set the Best-return-code to 10 if any below conditions fail:
如果以下任何条件失败，请将最佳返回代码设置为10：
- Validate that the Node Segment ID is advertised for the IPv4 Prefix by the IGP protocol {
- 验证IGP协议是否为IPv4前缀播发节点段ID{
o When the Protocol field in the received IPv6 IGP-Prefix Segment ID sub-TLV is 0, use any locally enabled IGP protocol.
o 当收到的IPv6 IGP前缀段ID子TLV中的协议字段为0时，请使用任何本地启用的IGP协议。
o When the Protocol field in the received IPv6 IGP-Prefix Segment ID sub-TLV is 1, use OSPF as the IGP protocol.
o 当接收到的IPv6 IGP前缀段ID子TLV中的协议字段为1时，使用OSPF作为IGP协议。
o When the Protocol field in the received IPv6 IGP-Prefix Segment ID sub-TLV is 2, use IS-IS as the IGP protocol.
o 当收到的IPv6 IGP前缀段ID子TLV中的协议字段为2时，使用is-is作为IGP协议。
o When the Protocol field in the received IPv6 IGP-Prefix Segment ID sub-TLV is an unrecognized value, it MUST be treated as a Protocol value of 0.
o 当接收到的IPv6 IGP前缀段ID子TLV中的协议字段为无法识别的值时，必须将其视为协议值0。
}
}
If it can be determined that no protocol associated with Interface-I would have advertised the FEC-Type at FEC-stack-depth, set the Best-return-code to 12, "Protocol not associated with interface at FEC stack-depth" and return.
如果可以确定没有与接口I关联的协议会在FEC堆栈深度播发FEC类型，则将最佳返回码设置为12，“与FEC堆栈深度的接口不关联的协议”并返回。
Set the FEC-Status to 1 and return.
将FEC状态设置为1并返回。
}
}
Else, if the Target FEC sub-TLV at FEC-stack-depth is 36 (IGP-Adjacency Segment ID), {
否则，如果FEC堆栈深度处的目标FEC子TLV为36（IGP邻接段ID）{
Set the Best-return-code to 35 (Section 9.5) if any below conditions fail:
如果以下任何条件失败，则将最佳返回代码设置为35（第9.5节）：
When the Adj. Type is 1 (Parallel Adjacency):
当。类型为1（平行邻接）：
o Validate that the Receiving Node Identifier is the local IGP identifier.
o 验证接收节点标识符是否为本地IGP标识符。
o Validate that the IGP-Adjacency Segment ID is advertised by the Advertising Node Identifier of the Protocol in the local IGP database {
o 验证IGP邻接段ID是否由本地IGP数据库中协议的播发节点标识符播发{
* When the Protocol field in the received IGP-Adjacency Segment ID sub-TLV is 0, use any locally enabled IGP protocol.
* 当接收到的IGP邻接段ID sub TLV中的协议字段为0时，使用任何本地启用的IGP协议。
* When the Protocol field in the received IGP-Adjacency Segment ID sub-TLV is 1, use OSPF as the IGP protocol.
* 当接收到的IGP邻接段ID sub TLV中的协议字段为1时，使用OSPF作为IGP协议。
* When the Protocol field in the received IGP-Adjacency Segment ID sub-TLV is 2, use IS-IS as the IGP protocol.
* 当接收到的IGP邻接段ID子TLV中的协议字段为2时，使用is-is作为IGP协议。
* When the Protocol field in the received IGP-Adjacency Segment ID sub-TLV is an unrecognized value, it MUST be treated as a Protocol value of 0.
* 当接收到的IGP邻接段ID子TLV中的协议字段为无法识别的值时，必须将其视为协议值0。
}
}
When the Adj. Type is 4 or 6 (IGP Adjacency or LAN Adjacency):
当。类型为4或6（IGP邻接或LAN邻接）：
o Validate that the Remote Interface ID matches the local identifier of the interface (Interface-I) on which the packet was received.
o 验证远程接口ID是否与接收数据包的接口（接口-I）的本地标识符匹配。
o Validate that the Receiving Node Identifier is the local IGP identifier.
o 验证接收节点标识符是否为本地IGP标识符。
o Validate that the IGP-Adjacency Segment ID is advertised by the Advertising Node Identifier of Protocol in the local IGP database {
o 验证IGP邻接段ID是否由本地IGP数据库中协议的播发节点标识符播发{
* When the Protocol field in the received IGP-Adjacency Segment ID sub-TLV is 0, use any locally enabled IGP protocol.
* 当接收到的IGP邻接段ID sub TLV中的协议字段为0时，使用任何本地启用的IGP协议。
* When the Protocol field in the received IGP-Adjacency Segment ID sub-TLV is 1, use OSPF as the IGP protocol.
* 当接收到的IGP邻接段ID sub TLV中的协议字段为1时，使用OSPF作为IGP协议。
* When the Protocol field in the received IGP-Adjacency Segment ID sub-TLV is 2, use IS-IS as the IGP protocol.
* 当接收到的IGP邻接段ID子TLV中的协议字段为2时，使用is-is作为IGP协议。
* When the Protocol field in the received IGP-Adjacency Segment ID sub-TLV is an unrecognized value, it MUST be treated as a Protocol value of 0.
* 当接收到的IGP邻接段ID子TLV中的协议字段为无法识别的值时，必须将其视为协议值0。
}
}
Set the FEC-Status to 1 and return.
将FEC状态设置为1并返回。
}
}
The LSP Traceroute operation can properly traverse every hop of the SR network for the Uniform Model as described in [RFC3443]. If one or more LSRs employ a Short Pipe Model, as described in [RFC3443], then the LSP Traceroute may not be able to properly traverse every hop of the SR network due to the absence of TTL copy operation when the outer label is popped. The Short Pipe is one of the most commonly used models. The following TTL manipulation technique MAY be used when the Short Pipe Model is used.
对于[RFC3443]中所述的统一模型，LSP跟踪路由操作可以正确地遍历SR网络的每个跃点。如[RFC3443]中所述，如果一个或多个LSR采用短管模型，则当弹出外部标签时，由于缺少TTL复制操作，LSP跟踪路由可能无法正确遍历SR网络的每个跃点。短管是最常用的型号之一。当使用短管模型时，可以使用以下TTL操纵技术。
When tracing an LSP according to the procedures in [RFC8029], the TTL is incremented by one in order to trace the path sequentially along the LSP. However, when a source-routed LSP has to be traced, there are as many TTLs as there are labels in the stack. The LSR that initiates the traceroute SHOULD start by setting the TTL to 1 for the tunnel in the LSP's label stack it wants to start the tracing from, the TTL of all outer labels in the stack to the max value, and the TTL of all the inner labels in the stack to zero. Thus, a typical start to the traceroute would have a TTL of 1 for the outermost label and all the inner labels would have a TTL of 0. If the FEC Stack TLV is included, it should contain only those for the inner-stacked tunnels. The Return Code/Subcode and FEC Stack Change TLV should be used to diagnose the tunnel as described in [RFC8029]. When the tracing of a tunnel in the stack is complete, then the next tunnel in the stack should be traced. The end of a tunnel can be detected from the Return Code when it indicates that the responding LSR is an egress for the stack at depth 1. Thus, the traceroute procedures in [RFC8029] can be recursively applied to traceroute a source-routed LSP.
当根据[RFC8029]中的程序跟踪LSP时，TTL增加1，以便沿LSP顺序跟踪路径。但是，当必须跟踪源路由LSP时，TTL的数量与堆栈中的标签数量相同。启动跟踪路由的LSR应首先将要开始跟踪的LSP标签堆栈中的隧道的TTL设置为1，将堆栈中所有外部标签的TTL设置为最大值，将堆栈中所有内部标签的TTL设置为零。因此，典型的traceroute起点最外层标签的TTL为1，所有内部标签的TTL为0。如果包括FEC堆叠TLV，则其应仅包含用于内部堆叠隧道的TLV。返回码/子码和FEC堆栈更改TLV应用于诊断隧道，如[RFC8029]所述。当堆栈中隧道的跟踪完成时，应跟踪堆栈中的下一个隧道。当返回代码指示响应的LSR是深度1处堆栈的出口时，可以从返回代码中检测隧道末端。因此，[RFC8029]中的跟踪路由过程可以递归地应用于源路由LSP的跟踪路由。
[INTEROP] describes how SR operates in a network where SR-capable and non-SR-capable nodes coexist. In such networks, there may not be any FEC mapping in the responder when the initiator is SR-capable, while the responder is not (or vice-versa). But this is not different from RSVP and LDP interoperation scenarios. When LSP Ping is triggered, the responder will set the FEC-return-code to Return 4, "Replying router has no mapping for the FEC at stack-depth".
[INTEROP]描述SR如何在支持SR和不支持SR的节点共存的网络中运行。在这种网络中，当发起方具有SR能力时，响应方中可能没有任何FEC映射，而响应方没有（反之亦然）。但这与RSVP和LDP互操作场景没有什么不同。当触发LSP Ping时，响应者将FEC返回码设置为返回4，“应答路由器在堆栈深度没有FEC的映射”。
Similarly, when an SR-capable node assigns Adj-SID for a non-SR-capable node, the LSP traceroute may fail as the non-SR-capable node is not aware of the "IGP Adjacency Segment ID" sub-TLV and may not reply with the FEC Stack Change sub-TLVs. This may result in any further downstream nodes replying back with a Return Code of 4, "Replying router has no mapping for the FEC at stack-depth".
类似地，当支持SR的节点为不支持SR的节点分配Adj SID时，LSP跟踪路由可能会失败，因为不支持SR的节点不知道“IGP邻接段ID”子TLV，并且可能不会使用FEC堆栈更改子TLV进行回复。这可能导致任何进一步的下游节点以4的返回码进行应答，“应答路由器在堆栈深度没有FEC的映射”。
IANA has assigned three new sub-TLVs from the "sub-TLVs for TLV Types 1, 16, and 21" subregistry of the "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry [IANA].
IANA已从“多协议标签交换（MPLS）标签交换路径（LSP）Ping参数”注册表[IANA]的“TLV类型1、16和21的子TLV”子区分配了三个新的子TLV。
Sub-Type Sub-TLV Name Reference
-------- ----------------- ------------
34 IPv4 IGP-Prefix Segment ID Section 5.1
35 IPv6 IGP-Prefix Segment ID Section 5.2
36 IGP-Adjacency Segment ID Section 5.3
Sub-Type Sub-TLV Name Reference
-------- ----------------- ------------
34 IPv4 IGP-Prefix Segment ID Section 5.1
35 IPv6 IGP-Prefix Segment ID Section 5.2
36 IGP-Adjacency Segment ID Section 5.3
IANA has created a new "Protocol in the Segment ID sub-TLV" (see Section 5) registry under the "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry. Code points in the range of 0-250 will be assigned by Standards Action [RFC8126]. The range of 251-254 is reserved for experimental use and will not be assigned. The value of 255 is marked "Reserved". The initial entries into the registry are:
IANA在“多协议标签交换（MPLS）标签交换路径（LSP）Ping参数”注册表下创建了一个新的“段ID子TLV中的协议”（见第5节）注册表。标准行动[RFC8126]将分配0-250范围内的代码点。251-254的范围保留供实验使用，不会分配。255的值标记为“保留”。注册表中的初始条目为：
Value Meaning Reference
---------- ---------------- ------------
0 Any IGP protocol This document
1 OSPF This document
2 IS-IS This document
Value Meaning Reference
---------- ---------------- ------------
0 Any IGP protocol This document
1 OSPF This document
2 IS-IS This document
IANA has created a new "Adjacency Type in the IGP-Adjacency Segment ID" registry (see Section 5.3) under the "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry. Code points in the range of 0-250 will be assigned by Standards Action. The range of 251-254 is reserved for experimental use and will not be assigned. The value of 255 is marked "Reserved". The initial entries into the registry are:
IANA在“多协议标签交换（MPLS）标签交换路径（LSP）Ping参数”注册表下创建了一个新的“IGP邻接段ID中的邻接类型”注册表（见第5.3节）。标准行动将分配0-250范围内的代码点。251-254的范围保留供实验使用，不会分配。255的值标记为“保留”。注册表中的初始条目为：
Value Meaning
---------- ----------------
0 Unnumbered Interface Adjacency
1 Parallel Adjacency
4 IPv4, Non-parallel Adjacency
6 IPv6, Non-parallel Adjacency
Value Meaning
---------- ----------------
0 Unnumbered Interface Adjacency
1 Parallel Adjacency
4 IPv4, Non-parallel Adjacency
6 IPv6, Non-parallel Adjacency
9.4. Protocol in the Label Stack Sub-TLV of the Downstream Detailed Mapping TLV
9.4. 下游详细映射TLV的标签堆栈子TLV中的协议
IANA has created a new "Protocol in the Label Stack sub-TLV of the Downstream Detailed Mapping TLV" registry under the "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry. Code points in the range of 0-250 will be assigned by Standards Action. The range of 251-254 is reserved for experimental use and will not be assigned. The value of 255 is marked "Reserved". The initial entries into the registry are:
IANA在“多协议标签交换（MPLS）标签交换路径（LSP）Ping参数”注册表下创建了一个新的“下游详细映射TLV的标签堆栈子TLV协议”注册表。标准行动将分配0-250范围内的代码点。251-254的范围保留供实验使用，不会分配。255的值标记为“保留”。注册表中的初始条目为：
Value Meaning Reference
---------- ---------------- ------------
0 Unknown Section 3.4.1.2 of RFC 8029
1 Static Section 3.4.1.2 of RFC 8029
2 BGP Section 3.4.1.2 of RFC 8029
3 LDP Section 3.4.1.2 of RFC 8029
4 RSVP-TE Section 3.4.1.2 of RFC 8029
5 OSPF Section 6 of this document
6 IS-IS Section 6 of this document
7-250 Unassigned
251-254 Reserved for
Experimental Use This document
255 Reserved This document
Value Meaning Reference
---------- ---------------- ------------
0 Unknown Section 3.4.1.2 of RFC 8029
1 Static Section 3.4.1.2 of RFC 8029
2 BGP Section 3.4.1.2 of RFC 8029
3 LDP Section 3.4.1.2 of RFC 8029
4 RSVP-TE Section 3.4.1.2 of RFC 8029
5 OSPF Section 6 of this document
6 IS-IS Section 6 of this document
7-250 Unassigned
251-254 Reserved for
Experimental Use This document
255 Reserved This document
IANA has assigned a new Return Code from the "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" in the 0-191 (Standards Action) range from the "Return Codes" subregistry.
IANA已从“返回码”子区0-191（标准操作）范围内的“多协议标签交换（MPLS）标签交换路径（LSP）Ping参数”中分配了一个新的返回码。
Value Meaning Reference
---------- ----------------- ------------
35 Mapping for this FEC is not associated Section 7.4 of
with the incoming interface this document
Value Meaning Reference
---------- ----------------- ------------
35 Mapping for this FEC is not associated Section 7.4 of
with the incoming interface this document
This document defines additional MPLS LSP Ping sub-TLVs and follows the mechanisms defined in [RFC8029]. All the security considerations defined in [RFC8029] will be applicable for this document and, in addition, they do not impose any additional security challenges to be considered.
本文档定义了额外的MPLS LSP Ping子TLV，并遵循[RFC8029]中定义的机制。[RFC8029]中定义的所有安全注意事项将适用于本文件，此外，它们不会带来任何需要考虑的额外安全挑战。
[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>.
[RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks", RFC 3443, DOI 10.17487/RFC3443, January 2003, <https://www.rfc-editor.org/info/rfc3443>.
[RFC3443]Agarwal，P.和B.Akyol，“多协议标签交换（MPLS）网络中的生存时间（TTL）处理”，RFC 3443，DOI 10.17487/RFC3443，2003年1月<https://www.rfc-editor.org/info/rfc3443>.
[RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005, <https://www.rfc-editor.org/info/rfc4203>.
[RFC4203]Kompella，K.，Ed.和Y.Rekhter，Ed.，“支持通用多协议标签交换（GMPLS）的OSPF扩展”，RFC 4203，DOI 10.17487/RFC4203，2005年10月<https://www.rfc-editor.org/info/rfc4203>.
[RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008, <https://www.rfc-editor.org/info/rfc5307>.
[RFC5307]Kompella，K.，Ed.和Y.Rekhter，Ed.，“支持通用多协议标签交换（GMPLS）的IS-IS扩展”，RFC 5307，DOI 10.17487/RFC5307，2008年10月<https://www.rfc-editor.org/info/rfc5307>.
[RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., Aldrin, S., and M. Chen, "Detecting Multiprotocol Label Switched (MPLS) Data-Plane Failures", RFC 8029, DOI 10.17487/RFC8029, March 2017, <https://www.rfc-editor.org/info/rfc8029>.
[RFC8029]Kompella，K.，Swallow，G.，Pignataro，C.，Ed.，Kumar，N.，Aldrin，S.，和M.Chen，“检测多协议标签交换（MPLS）数据平面故障”，RFC 8029，DOI 10.17487/RFC8029，2017年3月<https://www.rfc-editor.org/info/rfc8029>.
[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>.
[IANA] IANA, "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters", <http://www.iana.org/assignments/ mpls-lsp-ping-parameters>.
[IANA]IANA，“多协议标签交换（MPLS）标签交换路径（LSP）Ping参数”<http://www.iana.org/assignments/ mpls lsp ping参数>。
[INTEROP] Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., and S. Litkowski, "Segment Routing interworking with LDP", Work in Progress, draft-ietf-spring-segment-routing-ldp-interop-09, September 2017.
[INTEROP]Filsfils，C.，Previdi，S.，Bashandy，A.，DeClaene，B.，和S.Litkowski，“段路由与LDP的互通”，正在进行的工作，草案-ietf-spring-Segment-Routing-LDP-INTEROP-092017年9月。
[RFC792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, DOI 10.17487/RFC0792, September 1981, <https://www.rfc-editor.org/info/rfc792>.
[RFC792]Postel，J.，“互联网控制消息协议”，STD 5，RFC 792，DOI 10.17487/RFC0792，1981年9月<https://www.rfc-editor.org/info/rfc792>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]Cotton，M.，Leiba，B.，和T.Narten，“在RFC中编写IANA考虑事项部分的指南”，BCP 26，RFC 8126，DOI 10.17487/RFC8126，2017年6月<https://www.rfc-editor.org/info/rfc8126>.
[SR] Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", Work in Progress, draft-ietf-spring-segment-routing-14, December 2017.
[SR]Filsfils，C.，Previdi，S.，Ginsberg，L.，Decarene，B.，Litkowski，S.，和R.Shakir，“分段布线架构”，正在进行的工作，草案-ietf-spring-Segment-Routing-142017年12月。
[SR-IS-IS] Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A., Gredler, H., Litkowski, S., Decraene, B., and J. Tantsura, "IS-IS Extensions for Segment Routing", Work in Progress, draft-ietf-isis-segment-routing-extensions-15, December 2017.
[SR-IS-IS]Previdi，S.，Ginsberg，L.，Filsfils，C.，Bashandy，A.，Gredler，H.，Litkowski，S.，Decarene，B.，和J.Tantsura，“分段布线的IS-IS扩展”，正在进行中，草案-ietf-isis-Segment-Routing-Extensions-15，2017年12月。
[SR-MPLS] Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing with MPLS data plane", Work in Progress, draft-ietf-spring-segment-routing-mpls-11, October 2017.
[SR-MPLS]Filsfils，C.，Previdi，S.，Bashandy，A.，DeClaene，B.，Litkowski，S.，和R.Shakir，“使用MPLS数据平面的段路由”，正在进行的工作，草稿-ietf-spring-Segment-Routing-MPLS-112017年10月。
[SR-OSPF] Psenak, P., Previdi, S., Filsfils, C., Gredler, H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF Extensions for Segment Routing", Work in Progress, draft-ietf-ospf-segment-routing-extensions-24, December 2017.
[SR-OSPF]Psenak，P.，Previdi，S.，Filsfils，C.，Gredler，H.，Shakir，R.，Henderickx，W.，和J.Tantsura，“用于段路由的OSPF扩展”，正在进行的工作，草案-ietf-OSPF-Segment-Routing-Extensions-242017年12月。
[SR-OSPFV3] Psenak, P., Previdi, S., Filsfils, C., Gredler, H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPFv3 Extensions for Segment Routing", Work in Progress, draft-ietf-ospf-ospfv3-segment-routing-extensions-10, September 2017.
[SR-OSPFV3]Psenak，P.，Previdi，S.，Filsfils，C.，Gredler，H.，Shakir，R.，Henderickx，W.，和J.Tantsura，“用于段路由的OSPFV3扩展”，正在进行中的工作，草案-ietf-ospf-OSPFV3-段路由-扩展-10，2017年9月。
Acknowledgements
致谢
The authors would like to thank Stefano Previdi, Les Ginsberg, Balaji Rajagopalan, Harish Sitaraman, Curtis Villamizar, Pranjal Dutta, Lizhong Jin, Tom Petch, Victor Ji, Mustapha Aissaoui, Tony Przygienda, Alexander Vainshtein, and Deborah Brungard for their review and comments.
作者要感谢Stefano Previdi、Les Ginsberg、Balaji Rajagopalan、Harish Sitaraman、Curtis Villamizar、Pranjal Dutta、Lizhong Jin、Tom Petch、Victor Ji、Mustapha Aissaoui、Tony Przygienda、Alexander Vainstein和Deborah Brungard的评论。
The authors would like to thank Loa Andersson for his comments and recommendation to merge documents.
作者要感谢Loa Andersson对合并文档的评论和建议。
Contributors
贡献者
The following are key contributors to this document:
以下是本文件的主要贡献者：
Hannes Gredler, RtBrick, Inc. Tarek Saad, Cisco Systems, Inc. Siva Sivabalan, Cisco Systems, Inc. Balaji Rajagopalan, Juniper Networks Faisal Iqbal, Cisco Systems, Inc.
Hannes Gredler、RtBrick公司、Tarek Saad、思科系统公司、Siva Sivabalan、思科系统公司、Balaji Rajagopalan、Juniper Networks Faisal Iqbal、思科系统公司。
Authors' Addresses
作者地址
Nagendra Kumar (editor) Cisco Systems, Inc. 7200-12 Kit Creek Road Research Triangle Park, NC 27709-4987 United States of America
Nagendra Kumar（编辑）思科系统公司，地址：美国北卡罗来纳州吉溪路研究三角公园7200-12号，邮编：27709-4987
Email: naikumar@cisco.com
Email: naikumar@cisco.com
Carlos Pignataro (editor) Cisco Systems, Inc. 7200-11 Kit Creek Road Research Triangle Park, NC 27709-4987 United States of America
卡洛斯·皮格纳塔罗（编辑）思科系统公司，地址：美国北卡罗来纳州基特克里克路三角研究公园7200-11号，邮编：27709-4987
Email: cpignata@cisco.com
Email: cpignata@cisco.com
George Swallow Southend Technical Center
乔治·斯沃恩·索森德技术中心
Email: swallow.ietf@gmail.com
Email: swallow.ietf@gmail.com
Nobo Akiya Big Switch Networks
Nobo Akiya大交换网络
Email: nobo.akiya.dev@gmail.com
Email: nobo.akiya.dev@gmail.com
Sriganesh Kini Individual
斯里甘尼什-基尼个体
Email: sriganeshkini@gmail.com
Email: sriganeshkini@gmail.com
Mach(Guoyi) Chen Huawei
马赫（国一）陈华为
Email: mach.chen@huawei.com
Email: mach.chen@huawei.com