Internet Engineering Task Force (IETF) C. Filsfils, Ed.
Request for Comments: 8402 S. Previdi, Ed.
Category: Standards Track L. Ginsberg
ISSN: 2070-1721 Cisco Systems, Inc.
B. Decraene
S. Litkowski
Orange
R. Shakir
Google, Inc.
July 2018
Internet Engineering Task Force (IETF) C. Filsfils, Ed.
Request for Comments: 8402 S. Previdi, Ed.
Category: Standards Track L. Ginsberg
ISSN: 2070-1721 Cisco Systems, Inc.
B. Decraene
S. Litkowski
Orange
R. Shakir
Google, Inc.
July 2018
Segment Routing Architecture
分段路由结构
Abstract
摘要
Segment Routing (SR) leverages the source routing paradigm. A node steers a packet through an ordered list of instructions, called "segments". A segment can represent any instruction, topological or service based. A segment can have a semantic local to an SR node or global within an SR domain. SR provides a mechanism that allows a flow to be restricted to a specific topological path, while maintaining per-flow state only at the ingress node(s) to the SR domain.
段路由（SR）利用源路由范例。节点引导数据包通过一个有序的指令列表，称为“段”。段可以表示任何指令、拓扑或基于服务的指令。段可以是SR节点的局部语义，也可以是SR域中的全局语义。SR提供了一种机制，允许将流限制到特定拓扑路径，同时仅在SR域的入口节点处保持每流状态。
SR can be directly applied to the MPLS architecture with no change to the forwarding plane. A segment is encoded as an MPLS label. An ordered list of segments is encoded as a stack of labels. The segment to process is on the top of the stack. Upon completion of a segment, the related label is popped from the stack.
SR可以直接应用于MPLS体系结构，而不改变转发平面。段编码为MPLS标签。段的有序列表编码为标签堆栈。要处理的段位于堆栈的顶部。完成段后，相关标签从堆栈中弹出。
SR can be applied to the IPv6 architecture, with a new type of routing header. A segment is encoded as an IPv6 address. An ordered list of segments is encoded as an ordered list of IPv6 addresses in the routing header. The active segment is indicated by the Destination Address (DA) of the packet. The next active segment is indicated by a pointer in the new routing header.
SR可以应用于IPv6体系结构，具有一种新类型的路由头。段被编码为IPv6地址。在路由报头中，段的有序列表编码为IPv6地址的有序列表。活动段由数据包的目的地地址（DA）指示。下一个活动段由新路由标头中的指针指示。
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/rfc8402.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8402.
Copyright Notice
版权公告
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2018 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Link-State IGP Segments . . . . . . . . . . . . . . . . . . . 9
3.1. IGP-Prefix Segment (Prefix-SID) . . . . . . . . . . . . . 9
3.1.1. Prefix-SID Algorithm . . . . . . . . . . . . . . . . 9
3.1.2. SR-MPLS . . . . . . . . . . . . . . . . . . . . . . . 10
3.1.3. SRv6 . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2. IGP-Node Segment (Node-SID) . . . . . . . . . . . . . . . 13
3.3. IGP-Anycast Segment (Anycast-SID) . . . . . . . . . . . . 13
3.3.1. Anycast-SID in SR-MPLS . . . . . . . . . . . . . . . 13
3.4. IGP-Adjacency Segment (Adj-SID) . . . . . . . . . . . . . 15
3.4.1. Parallel Adjacencies . . . . . . . . . . . . . . . . 17
3.4.2. LAN Adjacency Segments . . . . . . . . . . . . . . . 18
3.5. Inter-Area Considerations . . . . . . . . . . . . . . . . 18
4. BGP Segments . . . . . . . . . . . . . . . . . . . . . . . . 19
4.1. BGP-Prefix Segment . . . . . . . . . . . . . . . . . . . 19
4.2. BGP Peering Segments . . . . . . . . . . . . . . . . . . 20
5. Binding Segment . . . . . . . . . . . . . . . . . . . . . . . 21
5.1. IGP Mirroring Context Segment . . . . . . . . . . . . . . 21
6. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . 22
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
8. Security Considerations . . . . . . . . . . . . . . . . . . . 22
8.1. SR-MPLS . . . . . . . . . . . . . . . . . . . . . . . . . 22
8.2. SRv6 . . . . . . . . . . . . . . . . . . . . . . . . . . 24
8.3. Congestion Control . . . . . . . . . . . . . . . . . . . 25
9. Manageability Considerations . . . . . . . . . . . . . . . . 25
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
10.1. Normative References . . . . . . . . . . . . . . . . . . 26
10.2. Informative References . . . . . . . . . . . . . . . . . 27
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 30
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Link-State IGP Segments . . . . . . . . . . . . . . . . . . . 9
3.1. IGP-Prefix Segment (Prefix-SID) . . . . . . . . . . . . . 9
3.1.1. Prefix-SID Algorithm . . . . . . . . . . . . . . . . 9
3.1.2. SR-MPLS . . . . . . . . . . . . . . . . . . . . . . . 10
3.1.3. SRv6 . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2. IGP-Node Segment (Node-SID) . . . . . . . . . . . . . . . 13
3.3. IGP-Anycast Segment (Anycast-SID) . . . . . . . . . . . . 13
3.3.1. Anycast-SID in SR-MPLS . . . . . . . . . . . . . . . 13
3.4. IGP-Adjacency Segment (Adj-SID) . . . . . . . . . . . . . 15
3.4.1. Parallel Adjacencies . . . . . . . . . . . . . . . . 17
3.4.2. LAN Adjacency Segments . . . . . . . . . . . . . . . 18
3.5. Inter-Area Considerations . . . . . . . . . . . . . . . . 18
4. BGP Segments . . . . . . . . . . . . . . . . . . . . . . . . 19
4.1. BGP-Prefix Segment . . . . . . . . . . . . . . . . . . . 19
4.2. BGP Peering Segments . . . . . . . . . . . . . . . . . . 20
5. Binding Segment . . . . . . . . . . . . . . . . . . . . . . . 21
5.1. IGP Mirroring Context Segment . . . . . . . . . . . . . . 21
6. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . 22
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
8. Security Considerations . . . . . . . . . . . . . . . . . . . 22
8.1. SR-MPLS . . . . . . . . . . . . . . . . . . . . . . . . . 22
8.2. SRv6 . . . . . . . . . . . . . . . . . . . . . . . . . . 24
8.3. Congestion Control . . . . . . . . . . . . . . . . . . . 25
9. Manageability Considerations . . . . . . . . . . . . . . . . 25
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
10.1. Normative References . . . . . . . . . . . . . . . . . . 26
10.2. Informative References . . . . . . . . . . . . . . . . . 27
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 30
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
Segment Routing (SR) leverages the source routing paradigm. A node steers a packet through an SR Policy instantiated as an ordered list of instructions called "segments". A segment can represent any instruction, topological or service based. A segment can have a semantic local to an SR node or global within an SR domain. SR supports per-flow explicit routing while maintaining per-flow state only at the ingress nodes to the SR domain.
段路由（SR）利用源路由范例。节点通过被实例化为称为“段”的指令有序列表的SR策略引导数据包。段可以表示任何指令、拓扑或基于服务的指令。段可以是SR节点的局部语义，也可以是SR域中的全局语义。SR支持每流显式路由，同时仅在SR域的入口节点处保持每流状态。
A segment is often referred to by its Segment Identifier (SID).
段通常由其段标识符（SID）引用。
A segment may be associated with a topological instruction. A topological local segment may instruct a node to forward the packet via a specific outgoing interface. A topological global segment may instruct an SR domain to forward the packet via a specific path to a destination. Different segments may exist for the same destination, each with different path objectives (e.g., which metric is minimized, what constraints are specified).
段可以与拓扑指令相关联。拓扑本地段可以指示节点经由特定的传出接口转发分组。拓扑全局段可指示SR域经由特定路径将分组转发到目的地。同一目的地可能存在不同的区段，每个区段具有不同的路径目标（例如，最小化哪个指标，指定哪些约束）。
A segment may be associated with a service instruction (e.g., the packet should be processed by a container or Virtual Machine (VM) associated with the segment). A segment may be associated with a QoS treatment (e.g., shape the packets received with this segment at x Mbps).
段可与服务指令相关联（例如，数据包应由与该段相关联的容器或虚拟机（VM）处理）。一个段可以与QoS处理相关联（例如，以x Mbps的速率塑造用该段接收的分组）。
The SR architecture supports any type of instruction associated with a segment.
SR体系结构支持与段相关的任何类型的指令。
The SR architecture supports any type of control plane: distributed, centralized, or hybrid.
SR体系结构支持任何类型的控制平面：分布式、集中式或混合式。
In a distributed scenario, the segments are allocated and signaled by IS-IS or OSPF or BGP. A node individually decides to steer packets on an SR Policy (e.g., pre-computed local protection [RFC8355]). A node individually computes the SR Policy.
在分布式场景中，段由IS-IS或OSPF或BGP分配和发送信号。节点单独决定根据SR策略（例如，预先计算的本地保护[RFC8355]）引导数据包。节点单独计算SR策略。
In a centralized scenario, the segments are allocated and instantiated by an SR controller. The SR controller decides which nodes need to steer which packets on which source-routed policies. The SR controller computes the source-routed policies. The SR architecture does not restrict how the controller programs the network. Likely options are Network Configuration Protocol (NETCONF), Path Computation Element Communication Protocol (PCEP), and BGP. The SR architecture does not restrict the number of SR controllers. Specifically, multiple SR controllers may program the same SR domain. The SR architecture allows these SR controllers to discover which SIDs are instantiated at which nodes and which sets of local (SRLB) and global (SRGB) labels are available at which node.
在集中式场景中，段由SR控制器分配和实例化。SR控制器决定哪些节点需要控制哪些源路由策略上的哪些数据包。SR控制器计算源路由策略。SR架构不限制控制器对网络进行编程的方式。可能的选项有网络配置协议（NETCONF）、路径计算元素通信协议（PCEP）和BGP。SR架构不限制SR控制器的数量。具体而言，多个SR控制器可以对同一SR域进行编程。SR体系结构允许这些SR控制器发现在哪些节点实例化了哪些SID，以及在哪个节点上有哪些本地（SRLB）和全局（SRGB）标签集可用。
A hybrid scenario complements a base distributed control plane with a centralized controller. For example, when the destination is outside the IGP domain, the SR controller may compute an SR Policy on behalf of an IGP node. The SR architecture does not restrict how the nodes that are part of the distributed control plane interact with the SR controller. Likely options are PCEP and BGP.
一个混合场景用一个集中式控制器补充了一个基本的分布式控制平面。例如，当目的地在IGP域之外时，SR控制器可以代表IGP节点计算SR策略。SR体系结构不限制作为分布式控制平面一部分的节点如何与SR控制器交互。可能的选择是PCEP和BGP。
Hosts MAY be part of an SR domain. A centralized controller can inform hosts about policies either by pushing these policies to hosts or by responding to requests from hosts.
主机可能是SR域的一部分。集中式控制器可以通过将这些策略推送到主机或响应主机的请求来通知主机有关策略的信息。
The SR architecture can be instantiated on various data planes. This document introduces two data-plane instantiations of SR: SR over MPLS (SR-MPLS) and SR over IPv6 (SRv6).
SR架构可以在各种数据平面上实例化。本文档介绍SR的两个数据平面实例：SR over MPLS（SR-MPLS）和SR over IPv6（SRv6）。
SR can be directly applied to the MPLS architecture with no change to the forwarding plane [SR-MPLS]. A segment is encoded as an MPLS label. An SR Policy is instantiated as a stack of labels. The segment to process (the active segment) is on the top of the stack. Upon completion of a segment, the related label is popped from the stack.
SR可以直接应用于MPLS体系结构，而不改变转发平面[SR-MPLS]。段编码为MPLS标签。SR策略被实例化为标签堆栈。要处理的段（活动段）位于堆栈顶部。完成段后，相关标签从堆栈中弹出。
SR can be applied to the IPv6 architecture with a new type of routing header called the SR Header (SRH) [IPv6-SRH]. An instruction is associated with a segment and encoded as an IPv6 address. An SRv6 segment is also called an SRv6 SID. An SR Policy is instantiated as an ordered list of SRv6 SIDs in the routing header. The active segment is indicated by the Destination Address (DA) of the packet. The next active segment is indicated by the SegmentsLeft (SL) pointer in the SRH. When an SRv6 SID is completed, the SL is decremented and the next segment is copied to the DA. When a packet is steered on an SR Policy, the related SRH is added to the packet.
SR可以通过一种称为SR报头（SRH）[IPv6 SRH]的新型路由报头应用于IPv6体系结构。指令与段关联并编码为IPv6地址。SRv6段也称为SRv6 SID。SR策略被实例化为路由标头中SRv6 SID的有序列表。活动段由数据包的目的地地址（DA）指示。SRH中的SECTIONSLEFT（SL）指针指示下一个活动段。当SRv6 SID完成时，SL递减，下一段复制到DA。当根据SR策略控制数据包时，相关SRH将添加到数据包中。
In the context of an IGP-based distributed control plane, two topological segments are defined: the IGP-Adjacency segment and the IGP-Prefix segment.
在基于IGP的分布式控制平面中，定义了两个拓扑段：IGP邻接段和IGP前缀段。
In the context of a BGP-based distributed control plane, two topological segments are defined: the BGP peering segment and the BGP-Prefix segment.
在基于BGP的分布式控制平面中，定义了两个拓扑段：BGP对等段和BGP前缀段。
The headend of an SR Policy binds a SID (called a Binding segment or BSID) to its policy. When the headend receives a packet with active segment matching the BSID of a local SR Policy, the headend steers the packet into the associated SR Policy.
SR策略的头端将SID（称为绑定段或BSID）绑定到其策略。当头端接收到活动段与本地SR策略的BSID匹配的数据包时，头端将该数据包引导到关联的SR策略中。
This document defines the IGP, BGP, and Binding segments for the SR-MPLS and SRv6 data planes.
本文档定义了SR-MPLS和SRv6数据平面的IGP、BGP和绑定段。
Note: This document defines the architecture for Segment Routing, including definitions of basic objects and functions and a description of the overall design. It does NOT define the means of implementing the architecture -- that is contained in numerous referenced documents, some of which are mentioned in this document as a convenience to the reader.
注：本文件定义了分段布线的体系结构，包括基本对象和功能的定义以及总体设计的说明。它没有定义实现体系结构的方法，体系结构包含在许多参考文档中，本文档中提到了一些参考文档，以方便读者阅读。
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]所述进行解释。
SR-MPLS: the instantiation of SR on the MPLS data plane.
SR-MPLS：在MPLS数据平面上对SR进行实例化。
SRv6: the instantiation of SR on the IPv6 data plane.
SRv6：IPv6数据平面上SR的实例化。
Segment: an instruction a node executes on the incoming packet (e.g., forward packet according to shortest path to destination, or, forward packet through a specific interface, or, deliver the packet to a given application/service instance).
段：节点对传入数据包执行的指令（例如，根据到目的地的最短路径转发数据包，或通过特定接口转发数据包，或将数据包交付给给定的应用程序/服务实例）。
SID: a segment identifier. Note that the term SID is commonly used in place of the term "Segment", though this is technically imprecise as it overlooks any necessary translation.
SID：段标识符。注意，术语SID通常用来代替术语“段”，尽管这在技术上不精确，因为它忽略了任何必要的翻译。
SR-MPLS SID: an MPLS label or an index value into an MPLS label space explicitly associated with the segment.
SR-MPLS SID：与段显式关联的MPLS标签空间中的MPLS标签或索引值。
SRv6 SID: an IPv6 address explicitly associated with the segment.
SRv6 SID：与段显式关联的IPv6地址。
Segment Routing domain (SR domain): the set of nodes participating in the source-based routing model. These nodes may be connected to the same physical infrastructure (e.g., a Service Provider's network). They may as well be remotely connected to each other (e.g., an enterprise VPN or an overlay). If multiple protocol instances are deployed, the SR domain most commonly includes all of the protocol instances in a network. However, some deployments may wish to subdivide the network into multiple SR domains, each of which includes one or more protocol instances. It is expected that all nodes in an SR domain are managed by the same administrative entity.
分段路由域（SR域）：参与基于源的路由模型的节点集。这些节点可以连接到相同的物理基础设施（例如，服务提供商的网络）。它们也可以彼此远程连接（例如，企业VPN或覆盖）。如果部署了多个协议实例，SR域通常包括网络中的所有协议实例。但是，一些部署可能希望将网络细分为多个SR域，每个SR域包括一个或多个协议实例。SR域中的所有节点都应由同一管理实体管理。
Active Segment: the segment that is used by the receiving router to process the packet. In the MPLS data plane, it is the top label. In the IPv6 data plane, it is the destination address [IPv6-SRH].
活动段：接收路由器用来处理数据包的段。在MPLS数据平面中，它是顶部标签。在IPv6数据平面中，它是目标地址[IPv6 SRH]。
PUSH: the operation consisting of the insertion of a segment at the top of the segment list. In SR-MPLS, the top of the segment list is the topmost (outer) label of the label stack. In SRv6, the top of the segment list is represented by the first segment in the Segment Routing Header as defined in [IPv6-SRH].
推送：在段列表顶部插入段的操作。在SR-MPLS中，段列表的顶部是标签堆栈的最顶部（外部）标签。在SRv6中，段列表的顶部由[IPv6 SRH]中定义的段路由标头中的第一个段表示。
NEXT: when the active segment is completed, NEXT is the operation consisting of the inspection of the next segment. The next segment becomes active. In SR-MPLS, NEXT is implemented as a POP of the top label. In SRv6, NEXT is implemented as the copy of the next segment from the SRH to the destination address of the IPv6 header.
下一步：当激活段完成时，下一步是包括检查下一段的操作。下一段变为活动段。在SR-MPLS中，NEXT实现为顶部标签的POP。在SRv6中，NEXT实现为从SRH到IPv6报头的目标地址的下一段的副本。
CONTINUE: the active segment is not completed; hence, it remains active. In SR-MPLS, the CONTINUE operation is implemented as a SWAP of the top label [RFC3031]. In SRv6, this is the plain IPv6 forwarding action of a regular IPv6 packet according to its destination address.
继续：活动段未完成；因此，它仍然是活跃的。在SR-MPLS中，继续操作作为顶部标签[RFC3031]的交换来实现。在SRv6中，这是常规IPv6数据包根据其目标地址进行的普通IPv6转发操作。
SR Global Block (SRGB): the set of global segments in the SR domain. If a node participates in multiple SR domains, there is one SRGB for each SR domain. In SR-MPLS, SRGB is a local property of a node and identifies the set of local labels reserved for global segments. In SR-MPLS, using identical SRGBs on all nodes within the SR domain is strongly recommended. Doing so eases operations and troubleshooting as the same label represents the same global segment at each node. In SRv6, the SRGB is the set of global SRv6 SIDs in the SR domain.
SR全局块（SRGB）：SR域中的全局段集。如果一个节点参与多个SR域，则每个SR域有一个SRGB。在SR-MPLS中，SRGB是节点的本地属性，标识为全局段保留的本地标签集。在SR-MPLS中，强烈建议在SR域内的所有节点上使用相同的SRGBs。这样做可以简化操作和故障排除，因为相同的标签表示每个节点上的相同全局段。在SRv6中，SRGB是SR域中的一组全局SRv6 SID。
SR Local Block (SRLB): local property of an SR node. If a node participates in multiple SR domains, there is one SRLB for each SR domain. In SR-MPLS, SRLB is a set of local labels reserved for local segments. In SRv6, SRLB is a set of local IPv6 addresses reserved for local SRv6 SIDs. In a controller-driven network, some controllers or applications may use the control plane to discover the available set of local segments.
SR局部块（SRLB）：SR节点的局部属性。如果一个节点参与多个SR域，则每个SR域有一个SRLB。在SR-MPLS中，SRLB是为本地段保留的一组本地标签。在SRv6中，SRLB是为本地SRv6 SID保留的一组本地IPv6地址。在控制器驱动的网络中，一些控制器或应用程序可能使用控制平面来发现可用的本地段集。
Global Segment: a segment that is part of the SRGB of the domain. The instruction associated with the segment is defined at the SR domain level. A topological shortest-path segment to a given destination within an SR domain is a typical example of a global segment.
全局段：是域的SRGB的一部分的段。与段关联的指令在SR域级别定义。SR域中到给定目的地的拓扑最短路径段是全局段的典型示例。
Local Segment: In SR-MPLS, this is a local label outside the SRGB. It may be part of the explicitly advertised SRLB. In SRv6, this can be any IPv6 address, i.e., the address may be part of the SRGB, but used such that it has local significance. The instruction associated with the segment is defined at the node level.
本地段：在SR-MPLS中，这是SRGB之外的本地标签。它可能是明确公布的SRLB的一部分。在SRv6中，该地址可以是任何IPv6地址，即该地址可能是SRGB的一部分，但其使用方式应确保其具有本地意义。与段关联的指令在节点级别定义。
IGP Segment: the generic name for a segment attached to a piece of information advertised by a link-state IGP, e.g., an IGP prefix or an IGP adjacency.
IGP段：连接到链接状态IGP发布的信息段的段的通用名称，例如，IGP前缀或IGP邻接。
IGP-Prefix Segment: an IGP-Prefix segment is an IGP segment representing an IGP prefix. When an IGP-Prefix segment is global within the SR IGP instance/topology, it identifies an instruction to
IGP前缀段：IGP前缀段是表示IGP前缀的IGP段。当一个IGP前缀段在SR IGP实例/拓扑中是全局的时，它会标识一条要执行的指令
forward the packet along the path computed using the routing algorithm specified in the algorithm field, in the topology, and in the IGP instance where it is advertised. Also referred to as "prefix segment".
沿着使用算法字段中指定的路由算法计算的路径转发数据包，在拓扑中，以及在发布数据包的IGP实例中。也称为“前缀段”。
Prefix-SID: the SID of the IGP-Prefix segment.
前缀SID：IGP前缀段的SID。
IGP-Anycast Segment: an IGP-Anycast segment is an IGP-Prefix segment that identifies an anycast prefix advertised by a set of routers.
IGP选播段：IGP选播段是一个IGP前缀段，用于标识一组路由器播发的选播前缀。
Anycast-SID: the SID of the IGP-Anycast segment.
选播SID：IGP选播段的SID。
IGP-Adjacency Segment: an IGP-Adjacency segment is an IGP segment attached to a unidirectional adjacency or a set of unidirectional adjacencies. By default, an IGP-Adjacency segment is local (unless explicitly advertised otherwise) to the node that advertises it. Also referred to as "Adj-SID".
IGP邻接段：IGP邻接段是连接到单向邻接或一组单向邻接的IGP段。默认情况下，IGP邻接段是播发它的节点的本地（除非另有明确播发）。也称为“Adj SID”。
Adj-SID: the SID of the IGP-Adjacency segment.
Adj SID：IGP邻接段的SID。
IGP-Node Segment: an IGP-Node segment is an IGP-Prefix segment that identifies a specific router (e.g., a loopback). Also referred to as "Node Segment".
IGP节点段：IGP节点段是标识特定路由器（例如环回）的IGP前缀段。也称为“节点段”。
Node-SID: the SID of the IGP-Node segment.
节点SID：IGP节点段的SID。
SR Policy: an ordered list of segments. The headend of an SR Policy steers packets onto the SR Policy. The list of segments can be specified explicitly in SR-MPLS as a stack of labels and in SRv6 as an ordered list of SRv6 SIDs. Alternatively, the list of segments is computed based on a destination and a set of optimization objective and constraints (e.g., latency, affinity, SRLG, etc.). The computation can be local or delegated to a PCE server. An SR Policy can be configured by the operator, provisioned via NETCONF [RFC6241] or provisioned via PCEP [RFC5440]. An SR Policy can be used for Traffic Engineering (TE), Operations, Administration, and Maintenance (OAM), or Fast Reroute (FRR) reasons.
SR策略：段的有序列表。SR策略的头端将数据包导向SR策略。段列表可以在SR-MPLS中明确指定为标签堆栈，在SRv6中明确指定为SRv6 SID的有序列表。或者，基于目的地和一组优化目标和约束（例如，延迟、相关性、SRLG等）来计算段列表。计算可以是本地的，也可以委托给PCE服务器。SR策略可由操作员配置，通过NETCONF[RFC6241]或通过PCEP[RFC5440]提供。SR策略可用于流量工程（TE）、操作、管理和维护（OAM）或快速重路由（FRR）原因。
Segment List Depth: the number of segments of an SR Policy. The entity instantiating an SR Policy at a node N should be able to discover the depth-insertion capability of the node N. For example, the PCEP SR capability advertisement described in [PCEP-SR-EXT] is one means of discovering this capability.
段列表深度：SR策略的段数。在节点N实例化SR策略的实体应该能够发现节点N的深度插入能力。例如，[PCEP-SR-EXT]中描述的PCEP SR能力公告是发现该能力的一种方法。
Forwarding Information Base (FIB): the forwarding table of a node
转发信息库（FIB）：节点的转发表
Within an SR domain, an SR-capable IGP node advertises segments for its attached prefixes and adjacencies. These segments are called "IGP segments" or "IGP SIDs". They play a key role in Segment Routing and use cases as they enable the expression of any path throughout the SR domain. Such a path is either expressed as a single IGP segment or a list of multiple IGP segments.
在SR域内，支持SR的IGP节点为其附加的前缀和邻接播发段。这些区段称为“IGP区段”或“IGP小岛屿发展中国家”。它们在段路由和用例中起着关键作用，因为它们支持在整个SR域中表达任何路径。这种路径可以表示为单个IGP段，也可以表示为多个IGP段的列表。
Advertisement of IGP segments requires extensions in link-state IGP protocols. These extensions are defined in [ISIS-SR-EXT], [OSPF-SR-EXT], and [OSPFv3-SR-EXT].
IGP段的公布需要在链路状态IGP协议中进行扩展。这些扩展在[ISIS-SR-EXT]、[OSPF-SR-EXT]和[OSPFv3 SR EXT]中定义。
An IGP-Prefix segment is an IGP segment attached to an IGP prefix. An IGP-Prefix segment is global (unless explicitly advertised otherwise) within the SR domain. The context for an IGP-Prefix segment includes the prefix, topology, and algorithm. Multiple SIDs MAY be allocated to the same prefix so long as the tuple <prefix, topology, algorithm> is unique.
IGP前缀段是附加到IGP前缀的IGP段。IGP前缀段在SR域中是全局的（除非另有明确通告）。IGP前缀段的上下文包括前缀、拓扑和算法。只要tuple<prefix，topology，algorithm>是唯一的，就可以将多个SID分配给同一前缀。
Multiple instances and topologies are defined in IS-IS and OSPF in: [RFC5120], [RFC8202], [RFC6549], and [RFC4915].
IS-IS和OSPF在[RFC5120]、[RFC8202]、[RFC6549]和[RFC4915]中定义了多个实例和拓扑。
Segment Routing supports the use of multiple routing algorithms, i.e, different constraint-based shortest-path calculations can be supported. An algorithm identifier is included as part of a Prefix-SID advertisement. Specification of how an algorithm-specific path calculation is done is required in the document defining the algorithm.
分段布线支持使用多种布线算法，即可以支持基于不同约束的最短路径计算。算法标识符包括在前缀SID播发中。定义算法的文档中需要说明如何进行特定于算法的路径计算。
This document defines two algorithms:
本文件定义了两种算法：
o Shortest Path First: this algorithm is the default behavior. The packet is forwarded along the well known ECMP-aware Shortest Path First (SPF) algorithm employed by the IGPs. However, it is explicitly allowed for a midpoint to implement another forwarding based on local policy. The Shortest Path First algorithm is, in fact, the default and current behavior of most of the networks where local policies may override the SPF decision.
o 最短路径优先：此算法是默认行为。数据包沿着IGPs采用的众所周知的ECMP感知最短路径优先（SPF）算法转发。但是，明确允许中点基于本地策略实现另一个转发。事实上，最短路径优先算法是大多数网络的默认和当前行为，其中本地策略可能会覆盖SPF决策。
o Strict Shortest Path First (Strict-SPF): This algorithm mandates that the packet be forwarded according to the ECMP-aware SPF algorithm and instructs any router in the path to ignore any possible local policy overriding the SPF decision. The SID
o 严格最短路径优先（Strict SPF）：该算法要求根据ECMP感知SPF算法转发数据包，并指示路径中的任何路由器忽略覆盖SPF决策的任何可能的本地策略。SID
advertised with the Strict-SPF algorithm ensures that the path the packet is going to take is the expected, and not altered, SPF path. Note that Fast Reroute (FRR) [RFC5714] mechanisms are still compliant with the Strict Shortest Path First algorithm. In other words, a packet received with a Strict-SPF SID may be rerouted through an FRR mechanism. Strict-SPF uses the same topology used by the Shortest Path First algorithm. Obviously, nodes that do not support Strict-SPF will not install forwarding entries for this algorithm. Restricting the topology only to those nodes that support this algorithm will not produce the desired forwarding paths since the desired behavior is to follow the path calculated by the Shortest Path First algorithm. Therefore, a source SR node MUST NOT use an SR Policy containing a strict SPF segment if the path crosses a node not supporting the Strict-SPF algorithm.
使用严格的SPF算法进行广告，确保数据包将采用的路径是预期的，而不是改变的SPF路径。请注意，快速重路由（FRR）[RFC5714]机制仍然符合严格的最短路径优先算法。换句话说，使用严格SPF SID接收的数据包可以通过FRR机制重新路由。严格SPF使用与最短路径优先算法相同的拓扑。显然，不支持严格SPF的节点不会为此算法安装转发条目。仅将拓扑限制到支持此算法的节点将不会产生所需的转发路径，因为所需的行为是遵循最短路径优先算法计算的路径。因此，如果路径穿过不支持严格SPF算法的节点，则源SR节点不得使用包含严格SPF段的SR策略。
An IGP-Prefix segment identifies the path, to the related prefix, computed as per the associated algorithm. A packet injected anywhere within the SR domain with an active Prefix-SID is expected to be forwarded along a path computed using the specified algorithm. For this to be possible, a fully connected topology of routers supporting the specified algorithm is required.
IGP前缀段标识根据相关算法计算的相关前缀的路径。在SR域内的任何位置注入的带有活动前缀SID的数据包，预期将沿着使用指定算法计算的路径转发。为了实现这一点，需要支持指定算法的路由器的完全连接拓扑。
When SR is used over the MPLS data plane, SIDs are an MPLS label or an index into an MPLS label space (either SRGB or SRLB).
在MPLS数据平面上使用SR时，SID是MPLS标签或MPLS标签空间（SRGB或SRLB）的索引。
Where possible, it is recommended that identical SRGBs be configured on all nodes in an SR domain. This simplifies troubleshooting as the same label will be associated with the same prefix on all nodes. In addition, it simplifies support for anycast as detailed in Section 3.3.
如果可能，建议在SR域中的所有节点上配置相同的SRGBs。这简化了故障排除，因为相同的标签将与所有节点上的相同前缀相关联。此外，它简化了对anycast的支持，如第3.3节所述。
The following behaviors are associated with SR operating over the MPLS data plane:
以下行为与在MPLS数据平面上运行的SR相关：
o The IGP signaling extension for IGP-Prefix segment includes a flag to indicate whether directly connected neighbors of the node on which the prefix is attached should perform the NEXT operation or the CONTINUE operation when processing the SID. This behavior is equivalent to Penultimate Hop Popping (NEXT) or Ultimate Hop Popping (CONTINUE) in MPLS.
o IGP前缀段的IGP信令扩展包括一个标志，用于指示在处理SID时，前缀所连接的节点的直接连接的邻居是否应执行下一个操作或继续操作。此行为相当于MPLS中倒数第二跳弹出（NEXT）或倒数第二跳弹出（CONTINUE）。
o A Prefix-SID is allocated in the form of an MPLS label (or an index in the SRGB) according to a process similar to IP address allocation. Typically, the Prefix-SID is allocated by policy by the operator (or Network Management System (NMS)), and the SID very rarely changes.
o 根据类似于IP地址分配的过程，以MPLS标签（或SRGB中的索引）的形式分配前缀SID。通常，前缀SID由运营商（或网络管理系统（NMS））根据策略分配，并且SID很少更改。
o While SR allows a local segment to be attached to an IGP prefix, where the terminology "IGP-Prefix segment" or "Prefix-SID" is used, the segment is assumed to be global (i.e., the SID is defined from the advertised SRGB). This is consistent with all the described use cases that require global segments attached to IGP prefixes.
o 当SR允许将本地段附加到IGP前缀时，如果使用术语“IGP前缀段”或“前缀SID”，则假定该段为全局段（即SID是根据公布的SRGB定义的）。这与所有描述的需要全局段附加到IGP前缀的用例一致。
o The allocation process MUST NOT allocate the same Prefix-SID to different prefixes.
o 分配过程不得将相同的前缀SID分配给不同的前缀。
o If a node learns of a Prefix-SID that has a value that falls outside the locally configured SRGB range, then the node MUST NOT use the Prefix-SID and SHOULD issue an error log reporting a misconfiguration.
o 如果节点获悉前缀SID的值超出本地配置的SRGB范围，则该节点不得使用前缀SID，并应发出错误日志，报告配置错误。
o If a node N advertises Prefix-SID SID-R for a prefix R that is attached to N and specifies CONTINUE as the operation to be performed by directly connected neighbors, then N MUST maintain the following FIB entry:
o 如果节点N播发附加到N的前缀R的前缀SID-R，并指定CONTINUE作为要由直接连接的邻居执行的操作，则N必须维护以下FIB条目：
Incoming Active Segment: SID-R Ingress Operation: NEXT Egress interface: NULL
传入活动段：SID-R入口操作：下一个出口接口：NULL
o A remote node M MUST maintain the following FIB entry for any learned Prefix-SID SID-R attached to prefix R:
o 远程节点M必须为附加到前缀R的任何读入前缀SID-R维护以下FIB条目：
Incoming Active Segment: SID-R Ingress Operation: If the next-hop of R is the originator of R and M has been instructed to remove the active segment: NEXT Else: CONTINUE Egress interface: the interface(s) towards the next-hop along the path computed using the algorithm advertised with the SID toward prefix R.
传入活动段：SID-R入口操作：如果R的下一个跃点是R的发起人，并且M已被指示删除活动段：下一个：继续出口接口：沿使用SID朝向前缀R播发的算法计算的路径，朝向下一个跃点的接口。
As Prefix-SIDs are specific to a given algorithm, if traffic associated with an algorithm arrives at a node that does not support that algorithm, the traffic will be dropped as there will be no forwarding entry matching the incoming label.
由于前缀SID特定于给定的算法，如果与算法关联的流量到达不支持该算法的节点，则该流量将被丢弃，因为没有与传入标签匹配的转发条目。
When SR is used over the IPv6 data plane:
在IPv6数据平面上使用SR时：
o A Prefix-SID is an IPv6 address.
o 前缀SID是IPv6地址。
o An operator MUST explicitly instantiate an SRv6 SID. IPv6 node addresses are not SRv6 SIDs by default.
o 操作员必须显式实例化SRv6 SID。默认情况下，IPv6节点地址不是SRv6 SID。
A node N advertising an IPv6 address R usable as a segment identifier MUST maintain the following FIB entry:
公布可用作段标识符的IPv6地址R的节点N必须维护以下FIB条目：
Incoming Active Segment: R Ingress Operation: NEXT Egress interface: NULL
传入活动段：R入口操作：下一个出口接口：NULL
Note that forwarding to R does not require an entry in the FIBs of all other routers for R. Forwarding can be, and most often will be, achieved by a shorter mask prefix that covers R.
请注意，转发到R不需要在所有其他路由器的FIB中输入R。转发可以并且通常将通过覆盖R的较短掩码前缀来实现。
Independent of SR support, any remote IPv6 node will maintain a plain IPv6 FIB entry for any prefix, no matter if the prefix represents a segment or not. This allows forwarding of packets to the node that owns the SID even by nodes that do not support SR.
独立于SR支持，任何远程IPv6节点都将为任何前缀维护一个简单的IPv6 FIB条目，无论该前缀是否表示一个段。这样，即使不支持SR的节点也可以将数据包转发到拥有SID的节点。
Support of multiple algorithms applies to SRv6. Since algorithm-specific SIDs are simply IPv6 addresses, algorithm-specific forwarding entries can be achieved by assigning algorithm-specific subnets to the (set of) algorithm specific SIDs that a node allocates.
对多种算法的支持适用于SRv6。由于特定于算法的SID只是IPv6地址，因此可以通过将特定于算法的子网分配给节点分配的（一组）特定于算法的SID来实现特定于算法的转发条目。
Nodes that do not support a given algorithm may still have a FIB entry covering an algorithm-specific address even though an algorithm-specific path has not been calculated by that node. This is mitigated by the fact that nodes that do not support a given algorithm will not be included in the topology associated with that algorithm-specific SPF; therefore, traffic using the algorithm-specific destination will normally not flow via the excluded node. If such traffic were to arrive and be forwarded by such a node, it will still progress towards the destination node. The next-hop will be either a node that supports the algorithm -- in which case, the packet will be forwarded along algorithm-specific paths (or be dropped if none are available) -- or a node that does NOT support the algorithm -- in which case, the packet will continue to be forwarded along Algorithm 0 paths towards the destination node.
不支持给定算法的节点可能仍然具有覆盖特定算法地址的FIB条目，即使该节点尚未计算特定算法的路径。不支持给定算法的节点将不包括在与该算法特定SPF相关联的拓扑中，这一事实缓解了这种情况；因此，使用算法特定目的地的流量通常不会通过排除的节点流动。如果这样的流量到达并由这样的节点转发，它仍将向目的地节点前进。下一个跃点将是支持算法的节点——在这种情况下，数据包将沿着算法特定路径转发（如果没有可用的路径，则丢弃）——或者是不支持算法的节点——在这种情况下，数据包将继续沿着算法0路径转发到目标节点。
An IGP Node-SID MUST NOT be associated with a prefix that is owned by more than one router within the same routing domain.
IGP节点SID不得与同一路由域内多个路由器拥有的前缀相关联。
An Anycast segment or Anycast-SID enforces the ECMP-aware shortest-path forwarding towards the closest node of the anycast set. This is useful to express macro-engineering policies or protection mechanisms.
选播段或选播SID向选播集最近的节点强制执行ECMP感知的最短路径转发。这有助于表达宏观工程政策或保护机制。
An IGP-Anycast segment MUST NOT reference a particular node.
IGP选播段不得引用特定节点。
Within an anycast group, all routers in an SR domain MUST advertise the same prefix with the same SID value.
在选播组中，SR域中的所有路由器必须使用相同的SID值播发相同的前缀。
+--------------+
| Group A |
|192.0.2.10/32 |
| SID:100 |
| |
+-----------A1---A3----------+
| | | \ / | | |
SID:10 | | | / | | | SID:30
203.0.113.1/32 | | | / \ | | | 203.0.113.3/32
PE1------R1----------A2---A4---------R3------PE3
\ /| | | |\ /
\ / | +--------------+ | \ /
\ / | | \ /
/ | | /
/ \ | | / \
/ \ | +--------------+ | / \
/ \| | | |/ \
PE2------R2----------B1---B3---------R4------PE4
203.0.113.2/32 | | | \ / | | | 203.0.113.4/32
SID:20 | | | / | | | SID:40
| | | / \ | | |
+-----------B2---B4----------+
| |
| Group B |
| 192.0.2.1/32 |
| SID:200 |
+--------------+
+--------------+
| Group A |
|192.0.2.10/32 |
| SID:100 |
| |
+-----------A1---A3----------+
| | | \ / | | |
SID:10 | | | / | | | SID:30
203.0.113.1/32 | | | / \ | | | 203.0.113.3/32
PE1------R1----------A2---A4---------R3------PE3
\ /| | | |\ /
\ / | +--------------+ | \ /
\ / | | \ /
/ | | /
/ \ | | / \
/ \ | +--------------+ | / \
/ \| | | |/ \
PE2------R2----------B1---B3---------R4------PE4
203.0.113.2/32 | | | \ / | | | 203.0.113.4/32
SID:20 | | | / | | | SID:40
| | | / \ | | |
+-----------B2---B4----------+
| |
| Group B |
| 192.0.2.1/32 |
| SID:200 |
+--------------+
Figure 1: Transit Device Groups
图1：运输设备组
The Figure 1 illustrates a network example with two groups of transit devices. Group A consists of devices {A1, A2, A3, and A4}. They are all provisioned with the anycast address 192.0.2.10/32 and the Anycast-SID 100.
图1显示了一个具有两组传输设备的网络示例。A组由装置{A1、A2、A3和A4}组成。它们都提供了选播地址192.0.2.10/32和选播SID 100。
Similarly, Group B consists of devices {B1, B2, B3, and B4}, and they are all provisioned with the anycast address 192.0.2.1/32 and the Anycast-SID 200. In the above network topology, each Provide Edge (PE) device has a path to each of the groups: A and B.
类似地，组B由设备{B1、B2、B3和B4}组成，并且它们都配备有选播地址192.0.2.1/32和选播SID 200。在上述网络拓扑中，每个提供边缘（PE）设备都有一条到每个组的路径：a和B。
PE1 can choose a particular transit device group when sending traffic to PE3 or PE4. This will be done by pushing the Anycast-SID of the group in the stack.
当向PE3或PE4发送通信量时，PE1可以选择特定的传输设备组。这将通过在堆栈中按下组的选播SID来完成。
Processing the anycast, and subsequent segments, requires special care.
处理选播和后续片段需要特别小心。
+-------------------------+
| Group A |
| 192.0.2.10/32 |
| SID:100 |
|-------------------------|
| |
| SRGB: SRGB: |
SID:10 |(1000-2000) (3000-4000)| SID:30
PE1---+ +-------A1-------------A3-------+ +---PE3
\ / | | \ / | | \ /
\ / | | +-----+ / | | \ /
SRGB: \ / | | \ / | | \ / SRGB:
(7000-8000) R1 | | \ | | R3 (6000-7000)
/ \ | | / \ | | / \
/ \ | | +-----+ \ | | / \
/ \ | | / \ | | / \
PE2---+ +-------A2-------------A4-------+ +---PE4
SID:20 | SRGB: SRGB: | SID:40
|(2000-3000) (4000-5000)|
| |
+-------------------------+
+-------------------------+
| Group A |
| 192.0.2.10/32 |
| SID:100 |
|-------------------------|
| |
| SRGB: SRGB: |
SID:10 |(1000-2000) (3000-4000)| SID:30
PE1---+ +-------A1-------------A3-------+ +---PE3
\ / | | \ / | | \ /
\ / | | +-----+ / | | \ /
SRGB: \ / | | \ / | | \ / SRGB:
(7000-8000) R1 | | \ | | R3 (6000-7000)
/ \ | | / \ | | / \
/ \ | | +-----+ \ | | / \
/ \ | | / \ | | / \
PE2---+ +-------A2-------------A4-------+ +---PE4
SID:20 | SRGB: SRGB: | SID:40
|(2000-3000) (4000-5000)|
| |
+-------------------------+
Figure 2: Transit Paths via Anycast Group A
图2：通过选播组A的传输路径
Considering an MPLS deployment, in the above topology, if device PE1 (or PE2) requires the sending of a packet to the device PE3 (or PE4), it needs to encapsulate the packet in an MPLS payload with the following stack of labels.
考虑MPLS部署，在上述拓扑中，如果设备PE1（或PE2）需要向设备PE3（或PE4）发送分组，则需要使用以下标签堆栈将分组封装在MPLS有效负载中。
o Label allocated by R1 for Anycast-SID 100 (outer label).
o R1为选播SID 100分配的标签（外部标签）。
o Label allocated by the nearest router in Group A for SID 30 (for destination PE3).
o A组中最近的路由器为SID 30（目的地PE3）分配的标签。
In this case, the first label is easy to compute. However, because there is more than one device that is topologically nearest (A1 and A2), determining the second label is impossible unless A1 and A2 allocated the same label value to the same prefix. Devices A1 and A2 may be devices from different hardware vendors. If both don't allocate the same label value for SID 30, it is impossible to use the anycast Group A as a transit anycast group towards PE3. Hence, PE1 (or PE2) cannot compute an appropriate label stack to steer the packet exclusively through the Group A devices. Same holds true for devices PE3 and PE4 when trying to send a packet to PE1 or PE2.
在这种情况下，第一个标签很容易计算。然而，由于存在多个拓扑上最近的设备（A1和A2），因此不可能确定第二标签，除非A1和A2将相同的标签值分配给相同的前缀。设备A1和A2可以是来自不同硬件供应商的设备。如果两者都没有为SID 30分配相同的标签值，则不可能将选播组A用作通向PE3的中转选播组。因此，PE1（或PE2）无法计算适当的标签堆栈来引导分组专门通过A组设备。当尝试向PE1或PE2发送数据包时，设备PE3和PE4也是如此。
To ease the use of an anycast segment, it is recommended to configure identical SRGBs on all nodes of a particular anycast group. Using this method, as mentioned above, computation of the label following the anycast segment is straightforward.
为了简化选播段的使用，建议在特定选播组的所有节点上配置相同的SRGB。如上所述，使用此方法，选播段后面的标签的计算非常简单。
Using an anycast segment without configuring identical SRGBs on all nodes belonging to the same anycast group may lead to misrouting (in an MPLS VPN deployment, some traffic may leak between VPNs).
使用选播段而不在属于同一选播组的所有节点上配置相同的SRGBs可能会导致路由错误（在MPLS VPN部署中，一些流量可能会在VPN之间泄漏）。
The adjacency is formed by the local node (i.e., the node advertising the adjacency in the IGP) and the remote node (i.e., the other end of the adjacency). The local node MUST be an IGP node. The remote node may be an adjacent IGP neighbor or a non-adjacent neighbor (e.g., a forwarding adjacency, [RFC4206]).
邻接由本地节点（即，在IGP中宣传邻接的节点）和远程节点（即，邻接的另一端）形成。本地节点必须是IGP节点。远程节点可以是相邻IGP邻居或非相邻邻居（例如，转发邻居[RFC4206]）。
A packet injected anywhere within the SR domain with a segment list {SN, SNL} where SN is the Node-SID of node N and SNL is an Adj-SID attached by node N to its adjacency over link L will be forwarded along the shortest path to N and then be switched by N, without any IP shortest-path consideration, towards link L. If the Adj-SID identifies a set of adjacencies, then the node N load-balances the traffic among the various members of the set.
在SR域内任何位置注入具有段列表{SN，SNL}的分组，其中SN是节点N的节点SID，SNL是节点N通过链路L连接到其邻接的邻接SID，该分组将沿着最短路径转发到N，然后由N切换，而不考虑任何IP最短路径，朝向链路L。如果Adj SID识别一组相邻，则节点N负载平衡该组的各个成员之间的通信量。
Similarly, when using a global Adj-SID, a packet injected anywhere within the SR domain with a segment list {SNL}, where SNL is a global Adj-SID attached by node N to its adjacency over link L, will be forwarded along the shortest path to N and then be switched by N, without any IP shortest-path consideration, towards link L. If the Adj-SID identifies a set of adjacencies, then the node N does load-balance the traffic among the various members of the set. The use of global Adj-SID allows to reduce the size of the segment list when expressing a path at the cost of additional state (i.e., the global Adj-SID will be inserted by all routers within the area in their forwarding table).
类似地，当使用全局邻接SID时，在SR域内的任何位置注入具有段列表{SNL}的分组（其中SNL是节点N通过链路L连接到其邻接的全局邻接SID）将沿着最短路径转发到N，然后由N切换，而不考虑任何IP最短路径，朝向链路L。如果Adj SID识别一组邻接，则节点N在该组的各个成员之间进行负载平衡。全局Adj SID的使用允许在以附加状态为代价表示路径时减小段列表的大小（即，全局Adj SID将由其转发表中区域内的所有路由器插入）。
An "IGP-Adjacency segment" or "Adj-SID" enforces the switching of the packet from a node towards a defined interface or set of interfaces. This is key to theoretically prove that any path can be expressed as a list of segments.
“IGP邻接段”或“Adj SID”强制将数据包从节点切换到定义的接口或接口集。这是从理论上证明任何路径都可以表示为段列表的关键。
The encodings of the Adj-SID include a set of flags supporting the following functionalities:
Adj SID的编码包括一组支持以下功能的标志：
o Eligible for Protection (e.g., using IPFRR or MPLS-FRR). Protection allows that in the event the interface(s) associated with the Adj-SID are down, that the packet can still be forwarded via an alternate path. The use of protection is clearly a policy-based decision; that is, for a given policy protection may or may not be desirable.
o 符合保护条件（例如，使用IPFRR或MPLS-FRR）。保护允许在与Adj SID关联的接口关闭的情况下，仍然可以通过备用路径转发数据包。使用保护显然是一项基于政策的决定；也就是说，对于给定的政策，保护可能是可取的，也可能不是可取的。
o Indication whether the Adj-SID has local or global scope. Default scope SHOULD be local.
o 指示Adj SID是具有本地作用域还是全局作用域。默认作用域应该是本地的。
o Indication whether the Adj-SID is persistent across control plane restarts. Persistence is a key attribute in ensuring that an SR Policy does not temporarily result in misforwarding due to reassignment of an Adj-SID.
o 指示Adj SID是否在控制平面上保持不变，然后重新启动。持久性是确保SR策略不会由于Adj SID的重新分配而暂时导致错误前进的关键属性。
A weight (as described below) is also associated with the Adj-SID advertisement.
权重（如下所述）也与Adj SID广告相关联。
A node SHOULD allocate one Adj-SID for each of its adjacencies.
一个节点应该为其每个邻接分配一个邻接SID。
A node MAY allocate multiple Adj-SIDs for the same adjacency. An example is to support an Adj-SID that is eligible for protection and an Adj-SID that is NOT eligible for protection.
一个节点可以为同一邻接分配多个邻接SID。例如，支持符合保护条件的Adj SID和不符合保护条件的Adj SID。
A node MAY associate the same Adj-SID to multiple adjacencies.
一个节点可以将同一个Adj SID与多个邻接相关联。
In order to be able to advertise in the IGP all the Adj-SIDs representing the IGP adjacencies between two nodes, parallel adjacency suppression MUST NOT be performed by the IGP.
为了能够在IGP中公布表示两个节点之间IGP邻接的所有邻接SID，IGP不得执行并行邻接抑制。
When a node binds an Adj-SID V to a local data-link L, the node MUST install the following FIB entry:
当节点将Adj SID V绑定到本地数据链路L时，该节点必须安装以下FIB条目：
Incoming Active Segment: V Ingress Operation: NEXT Egress Interface: L
输入活动段：V入口操作：下一出口接口：L
The Adj-SID implies, from the router advertising it, the forwarding of the packet through the adjacency or adjacencies identified by the Adj-SID, regardless of its IGP/SPF cost. In other words, the use of adjacency segments overrides the routing decision made by the SPF algorithm.
Adj-SID意味着，从公布它的路由器，通过Adj-SID标识的一个或多个邻接转发数据包，而不考虑其IGP/SPF成本。换句话说，邻接段的使用覆盖了SPF算法做出的路由决策。
Adj-SIDs can be used in order to represent a set of parallel interfaces between two adjacent routers.
Adj SID可用于表示两个相邻路由器之间的一组并行接口。
A node MUST install a FIB entry for any locally originated Adj-SID of value W attached to a set of links B with:
节点必须为连接到一组链接B的值为W的本地源Adj SID安装FIB条目，该链接B具有：
Incoming Active Segment: W Ingress Operation: NEXT Egress interfaces: load-balance between any data-link within set B
传入活动段：W入口操作：下一个出口接口：集合B内任何数据链路之间的负载平衡
When parallel adjacencies are used and associated with the same Adj-SID, and, in order to optimize the load-balancing function, a "weight" factor can be associated with the Adj-SID advertised with each adjacency. The weight tells the ingress (or an SDN/ orchestration system) about the load-balancing factor over the parallel adjacencies. As shown in Figure 3, A and B are connected through two parallel adjacencies
当使用并行邻接并与相同的邻接SID关联时，为了优化负载平衡功能，可以将“权重”因子与每个邻接公布的邻接SID关联。权重告诉入口（或SDN/编排系统）关于并行邻接上的负载平衡因子。如图3所示，A和B通过两个平行邻接连接
Link-1
+--------+
| |
S---A B---C
| |
+--------+
Link-2
Link-1
+--------+
| |
S---A B---C
| |
+--------+
Link-2
Figure 3: Parallel Links and Adj-SIDs
图3：平行链路和Adj小岛屿发展中国家
Node A advertises following Adj-SIDs and weights:
节点A公布以下Adj SID和权重：
o Link-1: Adj-SID 1000, weight: 1
o 链路1:Adj SID 1000，重量：1
o Link-2: Adj-SID 1000, weight: 2
o 链路2:Adj SID 1000，重量：2
Node S receives the advertisements of the parallel adjacencies and understands that by using Adj-SID 1000 node A will load-balance the traffic across the parallel links (Link-1 and Link-2) according to a 1:2 ratio i.e., twice as many packets will flow over Link-2 as compared to Link-1.
节点S接收并行邻接的播发，并理解通过使用Adj SID 1000，节点A将按照1:2的比率（即，将有两倍于链路1的数据包流过链路2）在并行链路（链路1和链路2）上进行负载平衡。
In LAN subnetworks, link-state protocols define the concept of Designated Router (DR, in OSPF) or Designated Intermediate System (DIS, in IS-IS) that conduct flooding in broadcast subnetworks and that describe the LAN topology in a special routing update (OSPF Type2 LSA or IS-IS Pseudonode LSP).
在LAN子网中，链路状态协议定义了指定路由器（DR，在OSPF中）或指定中间系统（DIS，在IS-IS中）的概念，它们在广播子网中进行泛洪，并在特殊路由更新（OSPF Type2 LSA或IS-IS伪节点LSP）中描述LAN拓扑。
The difficulty with LANs is that each router only advertises its connectivity to the DR/DIS and not to each of the individual nodes in the LAN. Therefore, additional protocol mechanisms (IS-IS and OSPF) are necessary in order for each router in the LAN to advertise an Adj-SID associated with each neighbor in the LAN.
局域网的困难在于，每个路由器只公布其与DR/DIS的连接，而不公布其与局域网中每个单独节点的连接。因此，需要附加的协议机制（IS-IS和OSPF），以便LAN中的每个路由器公布与LAN中每个邻居关联的Adj SID。
In the following example diagram, it is assumed that the all areas are part of a single SR domain.
在下面的示例图中，假设所有区域都是单个SR域的一部分。
The Figure 4 assumes the IPv6 control plane with the MPLS data plane.
图4假设IPv6控制平面具有MPLS数据平面。
! !
! !
B------C-----F----G-----K
/ | | |
S---A/ | | |
\ | | |
\D------I----------J-----L----Z (2001:DB8::2:1/128, Node-SID 150)
! !
Area 1 ! Backbone ! Area 2
! area !
! !
! !
B------C-----F----G-----K
/ | | |
S---A/ | | |
\ | | |
\D------I----------J-----L----Z (2001:DB8::2:1/128, Node-SID 150)
! !
Area 1 ! Backbone ! Area 2
! area !
Figure 4: Inter-Area Topology Example
图4：区域间拓扑示例
In Area 2, node Z allocates Node-SID 150 to his local IPv6 prefix 2001:DB8::2:1/128.
在区域2中，节点Z将节点SID 150分配给其本地IPv6前缀2001:DB8:：2:1/128。
Area Border Routers (ABRs) G and J will propagate the prefix and its SIDs into the backbone area by creating a new instance of the prefix according to normal inter-area/level IGP propagation rules.
区域边界路由器（ABR）G和J将根据正常的区域间/级别IGP传播规则创建前缀的新实例，从而将前缀及其SID传播到主干区域。
Nodes C and I will apply the same behavior when leaking prefixes from the backbone area down to area 1. Therefore, node S will see prefix 2001:DB8::2:1/128 with Prefix-SID 150 and advertised by nodes C and I.
当前缀从主干区域泄漏到区域1时，节点C和节点I将应用相同的行为。因此，节点S将看到前缀为2001:DB8:：2:1/128，前缀为SID 150，并由节点C和I播发。
Therefore, the result is that a Prefix-SID remains attached to its related IGP prefix through the inter-area process, which is the expected behavior in a single SR domain.
因此，结果是前缀SID通过区域间过程保持连接到其相关IGP前缀，这是单个SR域中的预期行为。
When node S sends traffic to 2001:DB8::2:1/128, it pushes Node-SID(150) as an active segment and forwards it to A.
当节点S向2001:DB8:：2:1/128发送通信量时，它将节点SID（150）推送为活动段，并将其转发给A。
When a packet arrives at ABR I (or C), the ABR forwards the packet according to the active segment (Node-SID(150)). Forwarding continues across area borders, using the same Node-SID(150) until the packet reaches its destination.
当分组到达ABR I（或C）时，ABR根据活动段（节点SID（150））转发分组。转发继续跨越区域边界，使用相同的节点SID（150），直到数据包到达其目的地。
BGP segments may be allocated and distributed by BGP.
BGP段可由BGP分配和分发。
A BGP-Prefix segment is a BGP segment attached to a BGP prefix.
BGP前缀段是附加到BGP前缀的BGP段。
A BGP-Prefix segment is global (unless explicitly advertised otherwise) within the SR domain.
BGP前缀段在SR域中是全局的（除非另有明确通告）。
The BGP-Prefix segment is the BGP equivalent to the IGP-Prefix segment.
BGP前缀段是等同于IGP前缀段的BGP。
A likely use case for the BGP-Prefix segment is an IGP-free hyper-scale spine-leaf topology where connectivity is learned solely via BGP [RFC7938]
BGP前缀段的一个可能使用案例是无IGP的超比例脊椎叶拓扑，其中连接仅通过BGP学习[RFC7938]
In the context of BGP Egress Peer Engineering (EPE), as described in [SR-CENTRAL-EPE], an EPE-enabled egress node MAY advertise segments corresponding to its attached peers. These segments are called BGP peering segments or BGP peering SIDs. They enable the expression of source-routed inter-domain paths.
在BGP出口对等工程（EPE）的上下文中，如[SR-CENTRAL-EPE]中所述，启用EPE的出口节点可以公布与其连接的对等节点相对应的段。这些段称为BGP对等段或BGP对等SID。它们支持源路由域间路径的表达式。
An ingress border router of an Autonomous System (AS) may compose a list of segments to steer a flow along a selected path within the AS towards a selected egress border router C of the AS and through a specific peer. At a minimum, a BGP peering engineering policy applied at an ingress node involves two segments: the Node-SID of the chosen egress node and the BGP peering segment for the chosen egress node peer or peering interface.
自治系统（AS）的入口边界路由器可以组成段列表，以引导流沿着AS内的选定路径流向AS的选定出口边界路由器C并通过特定对等方。至少，应用于入口节点的BGP对等工程策略涉及两个段：所选出口节点的节点SID和所选出口节点对等或对等接口的BGP对等段。
Three types of BGP peering segments/SIDs are defined: PeerNode SID, PeerAdj SID, and PeerSet SID.
定义了三种类型的BGP对等段/SID：对等节点SID、对等节点SID和对等集SID。
o PeerNode SID: a BGP PeerNode segment/SID is a local segment. At the BGP node advertising it, its semantics are:
o 对等节点SID:BGP对等节点段/SID是本地段。在为其发布广告的BGP节点上，其语义为：
* SR operation: NEXT.
* 高级操作：下一步。
* Next-Hop: the connected peering node to which the segment is related.
* 下一跳：与该段相关的已连接对等节点。
o PeerAdj SID: a BGP PeerAdj segment/SID is a local segment. At the BGP node advertising it, the semantics are:
o PeerAdj SID:BGP PeerAdj段/SID是本地段。在BGP节点上宣传它，语义是：
* SR operation: NEXT.
* 高级操作：下一步。
* Next-Hop: the peer connected through the interface to which the segment is related.
* 下一跳：通过与该段相关的接口连接的对等方。
o PeerSet SID: a BGP PeerSet segment/SID is a local segment. At the BGP node advertising it, the semantics are:
o PeerSet SID:BGP PeerSet段/SID是本地段。在BGP节点上宣传它，语义是：
* SR operation: NEXT.
* 高级操作：下一步。
* Next-Hop: load-balance across any connected interface to any peer in the related group.
* 下一跳：跨任何连接接口到相关组中任何对等方的负载平衡。
A peer set could be all the connected peers from the same AS or a subset of these. A group could also span across AS. The group definition is a policy set by the operator.
对等点集可以是来自同一个或其中一个子集的所有连接的对等点。一个团队也可以跨越AS。组定义是由操作员设置的策略。
The BGP extensions necessary in order to signal these BGP peering segments are defined in [BGPLS-SR-EPE].
[BGPLS-SR-EPE]中定义了向这些BGP对等段发送信号所需的BGP扩展。
In order to provide greater scalability, network opacity, and service independence, SR utilizes a Binding SID (BSID). The BSID is bound to an SR Policy, instantiation of which may involve a list of SIDs. Any packets received with an active segment equal to BSID are steered onto the bound SR Policy.
为了提供更大的可伸缩性、网络不透明度和服务独立性，SR使用绑定SID（BSID）。BSID绑定到SR策略，其实例化可能涉及SID列表。使用等于BSID的活动段接收的任何数据包都被引导到绑定的SR策略上。
A BSID may be either a local or a global SID. If local, a BSID SHOULD be allocated from the SRLB. If global, a BSID MUST be allocated from the SRGB.
BSID可以是本地或全局SID。如果是本地的，则应从SRLB分配BSID。如果是全局的，则必须从SRGB分配BSID。
Use of a BSID allows the instantiation of the policy (the SID list) to be stored only on the node or nodes that need to impose the policy. Direction of traffic to a node supporting the policy then only requires imposition of the BSID. If the policy changes, this also means that only the nodes imposing the policy need to be updated. Users of the policy are not impacted.
使用BSID允许仅在需要实施策略的节点上存储策略的实例化（SID列表）。然后，到支持策略的节点的流量方向只需要施加BSID。如果策略更改，这也意味着只需要更新实施策略的节点。策略的用户不受影响。
One use case for a Binding segment is to provide support for an IGP node to advertise its ability to process traffic originally destined to another IGP node, called the "mirrored node" and identified by an IP address or a Node-SID, provided that a Mirroring Context segment is inserted in the segment list prior to any service segment local to the mirrored node.
绑定段的一个用例是为IGP节点提供支持，以公布其处理最初发送到另一个IGP节点（称为“镜像节点”并由IP地址或节点SID标识）的流量的能力，前提是镜像上下文段插入到段列表中，位于镜像节点本地的任何服务段之前。
When a given node B wants to provide egress node A protection, it advertises a segment identifying node's A context. Such a segment is called "Mirroring Context segment" and is identified by the Mirror SID.
当给定节点B想要提供出口节点a保护时，它播发标识节点a上下文的段。这种段称为“镜像上下文段”，由镜像SID标识。
The Mirror SID is advertised using the Binding segment defined in SR IGP protocol extensions [ISIS-SR-EXT].
使用SR IGP协议扩展[ISIS-SR-EXT]中定义的绑定段公布镜像SID。
In the event of a failure, a Point of Local Repair (PLR) diverting traffic from A to B does a PUSH of the Mirror SID on the protected traffic. When receiving the traffic with the Mirror SID as the active segment, B uses that segment and processes underlying segments in the context of A.
发生故障时，将流量从a转移到B的本地维修点（PLR）会在受保护的流量上推送镜像SID。当以镜像SID作为活动段接收流量时，B使用该段并在A的上下文中处理底层段。
Segment Routing is defined for unicast. The application of the source-route concept to Multicast is not in the scope of this document.
为单播定义了段路由。源路由概念在多播中的应用不在本文档的范围内。
This document has no IANA actions.
本文档没有IANA操作。
Segment Routing is applicable to both MPLS and IPv6 data planes.
段路由适用于MPLS和IPv6数据平面。
SR adds some metadata (instructions) to the packet, with the list of forwarding path elements (e.g., nodes, links, services, etc.) that the packet must traverse. It has to be noted that the complete source-routed path may be represented by a single segment. This is the case of the Binding SID.
SR向数据包添加一些元数据（指令），以及数据包必须遍历的转发路径元素列表（例如，节点、链接、服务等）。必须注意的是，完整的源路由路径可以由单个段表示。绑定SID就是这种情况。
By default, SR operates within a trusted domain. Traffic MUST be filtered at the domain boundaries.
默认情况下，SR在受信任域内运行。必须在域边界处过滤流量。
The use of best practices to reduce the risk of tampering within the trusted domain is important. Such practices are discussed in [RFC4381] and are applicable to both SR-MPLS and SRv6.
使用最佳实践来降低受信任域内的篡改风险非常重要。此类实践在[RFC4381]中进行了讨论，适用于SR-MPLS和SRv6。
When applied to the MPLS data plane, SR does not introduce any new behavior or any change in the way the MPLS data plane works. Therefore, from a security standpoint, this document does not define any additional mechanism in the MPLS data plane.
当应用于MPLS数据平面时，SR不会在MPLS数据平面的工作方式中引入任何新的行为或任何更改。因此，从安全的角度来看，本文档没有在MPLS数据平面中定义任何附加机制。
SR allows the expression of a source-routed path using a single segment (the Binding SID). Compared to RSVP-TE, which also provides explicit routing capability, there are no fundamental differences in terms of information provided. Both RSVP-TE and Segment Routing may express a source-routed path using a single segment.
SR允许使用单个段（绑定SID）表示源路由路径。与同样提供显式路由功能的RSVP-TE相比，在提供的信息方面没有根本的区别。RSVP-TE和段路由都可以使用单个段表示源路由路径。
When a path is expressed using a single label, the syntax of the metadata is equivalent between RSVP-TE [RFC3209] and SR.
当使用单个标签表示路径时，RSVP-TE[RFC3209]和SR之间的元数据语法是等效的。
When a source-routed path is expressed with a list of segments, additional metadata is added to the packet consisting of the source-routed path the packet must follow expressed as a segment list.
当源路由路径用段列表表示时，额外的元数据将添加到包含源路由路径的数据包中，该数据包必须遵循表示为段列表的源路由路径。
When a path is expressed using a label stack, if one has access to the meaning (i.e., the Forwarding Equivalence Class) of the labels, one has the knowledge of the explicit path. For the MPLS data plane, as no data-plane modification is required, there is no fundamental change of capability. Yet, the occurrence of label stacking will increase.
当使用标签堆栈表示路径时，如果可以访问标签的含义（即，转发等价类），则可以知道显式路径。对于MPLS数据平面，由于不需要对数据平面进行修改，因此性能没有根本变化。然而，标签堆叠的发生将增加。
SR domain boundary routers MUST filter any external traffic destined to a label associated with a segment within the trusted domain. This includes labels within the SRGB of the trusted domain, labels within the SRLB of the specific boundary router, and labels outside either of these blocks. External traffic is any traffic received from an interface connected to a node outside the domain of trust.
SR域边界路由器必须过滤任何发送到与受信任域内的段相关联的标签的外部流量。这包括受信任域的SRGB内的标签、特定边界路由器的SRLB内的标签以及这些块之外的标签。外部通信量是从连接到信任域外节点的接口接收的任何通信量。
From a network protection standpoint, there is an assumed trust model such that any node imposing a label stack on a packet is assumed to be allowed to do so. This is a significant change compared to plain IP offering shortest path routing, but it is not fundamentally different compared to existing techniques providing explicit routing capability such as RSVP-TE. By default, the explicit routing information MUST NOT be leaked through the boundaries of the administered domain. Segment Routing extensions that have been defined in various protocols, leverage the security mechanisms of these protocols such as encryption, authentication, filtering, etc.
从网络保护的角度来看，存在一个假定的信任模型，即假定允许在数据包上施加标签堆栈的任何节点这样做。与提供最短路径路由的普通IP相比，这是一个重大的变化，但与提供显式路由功能的现有技术（如RSVP-TE）相比，这并没有本质上的区别。默认情况下，显式路由信息不得通过受管域的边界泄漏。在各种协议中定义的分段路由扩展，利用这些协议的安全机制，如加密、身份验证、过滤等。
In the general case, a segment-routing-capable router accepts and installs labels only if the labels have been previously advertised by a trusted source. The received information is validated using existing control-plane protocols providing authentication and security mechanisms. Segment Routing does not define any additional security mechanism in existing control-plane protocols.
在一般情况下，支持段路由的路由器仅在标签先前已由可信源播发的情况下才接受和安装标签。使用提供身份验证和安全机制的现有控制平面协议验证接收到的信息。在现有的控制平面协议中，段路由没有定义任何额外的安全机制。
SR does not introduce signaling between the source and the midpoints of a source-routed path. With SR, the source-routed path is computed using SIDs previously advertised in the IP control plane. Therefore, in addition to filtering and controlled advertisement of SIDs at the boundaries of the SR domain, filtering in the data plane is also required. Filtering MUST be performed on the forwarding plane at the boundaries of the SR domain and may require looking at multiple labels/instructions.
SR不会在源和源路由路径的中点之间引入信令。对于SR，源路由路径是使用先前在IP控制平面中公布的SID计算的。因此，除了在SR域的边界处过滤和控制SID的广告外，还需要在数据平面中过滤。必须在SR域边界的转发平面上执行过滤，可能需要查看多个标签/指令。
For the MPLS data plane, there are no new requirements as the existing MPLS architecture already allows such source routing by stacking multiple labels. And, for security protection, [RFC4381] and [RFC5920] already call for the filtering of MPLS packets on trust boundaries.
对于MPLS数据平面，没有新的要求，因为现有的MPLS体系结构已经允许通过堆叠多个标签进行此类源路由。而且，为了安全保护，[RFC4381]和[RFC5920]已经要求过滤信任边界上的MPLS数据包。
When applied to the IPv6 data plane, Segment Routing does introduce the Segment Routing Header (SRH, [IPv6-SRH]) which is a type of Routing Extension header as defined in [RFC8200].
当应用于IPv6数据平面时，段路由确实引入了段路由报头（SRH，[IPv6 SRH]），这是[RFC8200]中定义的一种路由扩展报头。
The SRH adds some metadata to the IPv6 packet, with the list of forwarding path elements (e.g., nodes, links, services, etc.) that the packet must traverse and that are represented by IPv6 addresses. A complete source-routed path may be encoded in the packet using a single segment (single IPv6 address).
SRH向IPv6数据包中添加了一些元数据，以及数据包必须穿过的、由IPv6地址表示的转发路径元素（例如节点、链路、服务等）的列表。完整的源路由路径可以使用单个段（单个IPv6地址）编码在分组中。
SR domain boundary routers MUST filter any external traffic destined to an address within the SRGB of the trusted domain or the SRLB of the specific boundary router. External traffic is any traffic received from an interface connected to a node outside the domain of trust.
SR域边界路由器必须过滤发送到受信任域的SRGB或特定边界路由器的SRLB内地址的任何外部流量。外部通信量是从连接到信任域外节点的接口接收的任何通信量。
From a network-protection standpoint, there is an assumed trust model such that any node adding an SRH to the packet is assumed to be allowed to do so. Therefore, by default, the explicit routing information MUST NOT be leaked through the boundaries of the administered domain. Segment Routing extensions that have been defined in various protocols, leverage the security mechanisms of these protocols such as encryption, authentication, filtering, etc.
从网络保护的角度来看，存在一个假定的信任模型，使得向分组添加SRH的任何节点都被假定为允许这样做。因此，默认情况下，显式路由信息不得通过受管域的边界泄漏。在各种协议中定义的分段路由扩展，利用这些协议的安全机制，如加密、身份验证、过滤等。
In the general case, an SRv6 router accepts and install segments identifiers (in the form of IPv6 addresses), only if these SIDs are advertised by a trusted source. The received information is validated using existing control-plane protocols providing authentication and security mechanisms. Segment Routing does not define any additional security mechanism in existing control-plane protocols.
在一般情况下，SRv6路由器仅在可信源播发这些SID时才接受并安装段标识符（以IPv6地址的形式）。使用提供身份验证和安全机制的现有控制平面协议验证接收到的信息。在现有的控制平面协议中，段路由没有定义任何额外的安全机制。
Problems that may arise when the above behaviors are not implemented or when the assumed trust model is violated (e.g., through a security breach) include:
未实施上述行为或违反假定的信任模型（例如，通过安全漏洞）时可能出现的问题包括：
o Malicious looping
o 恶意循环
o Evasion of access controls
o 逃避访问控制
o Hiding the source of DoS attacks
o 隐藏拒绝服务攻击的来源
Security concerns with SR at the IPv6 data plane are more completely discussed in [RFC5095]. The new IPv6-based Segment Routing Header is defined in [IPv6-SRH]. This document also discusses the above security concerns.
[RFC5095]中更全面地讨论了IPv6数据平面上SR的安全问题。新的基于IPv6的段路由标头在[IPv6 SRH]中定义。本文件还讨论了上述安全问题。
SR does not introduce new requirements for congestion control. By default, traffic delivery is assumed to be best effort. Congestion control may be implemented at endpoints. Where SR policies are in use, bandwidth allocation may be managed by monitoring incoming traffic associated with the binding SID identifying the SR Policy. Other solutions such as presented in [RFC8084] may be applicable.
SR没有对拥塞控制提出新的要求。默认情况下，流量交付被认为是最大努力。拥塞控制可以在端点处实现。在使用SR策略的情况下，可以通过监视与标识SR策略的绑定SID相关联的传入流量来管理带宽分配。[RFC8084]中提出的其他解决方案可能适用。
In SR-enabled networks, the path the packet takes is encoded in the header. As the path is not signaled through a protocol, OAM mechanisms are necessary in order for the network operator to validate the effectiveness of a path as well as to check and monitor its liveness and performance. However, it has to be noted that SR allows to reduce substantially the number of states in transit nodes; hence, the number of elements that a transit node has to manage is smaller.
在支持SR的网络中，数据包的路径在报头中进行编码。由于路径没有通过协议发出信号，因此OAM机制对于网络运营商验证路径的有效性以及检查和监控其活动性和性能是必要的。然而，必须注意的是，SR允许大幅减少传输节点中的状态数量；因此，中转节点必须管理的元素数量较少。
SR OAM use cases for the MPLS data plane are defined in [RFC8403]. SR OAM procedures for the MPLS data plane are defined in [RFC8287].
MPLS数据平面的SR OAM用例在[RFC8403]中定义。MPLS数据平面的SR OAM过程在[RFC8287]中定义。
SR routers receive advertisements of SIDs (index, label, or IPv6 address) from the different routing protocols being extended for SR. Each of these protocols have monitoring and troubleshooting mechanisms to provide operation and management functions for IP addresses that must be extended in order to include troubleshooting and monitoring functions of the SID.
SR路由器接收SID广告（索引、标签或IPv6地址）来自为SR扩展的不同路由协议。这些协议中的每一个都有监控和故障排除机制，为IP地址提供操作和管理功能，这些功能必须扩展，以便包括SID的故障排除和监控功能。
SR architecture introduces the usage of global segments. Each global segment MUST be bound to a unique index or address within an SR domain. The management of the allocation of such an index or address by the operator is critical for the network behavior to avoid situations like misrouting. In addition to the allocation policy/ tooling that the operator will have in place, an implementation SHOULD protect the network in case of conflict detection by providing a deterministic resolution approach.
SR架构介绍了全局段的使用。每个全局段必须绑定到SR域中的唯一索引或地址。运营商对此类索引或地址分配的管理对于网络行为至关重要，以避免出现错误路由等情况。除了运营商将拥有的分配策略/工具外，实施还应通过提供确定性解决方法在冲突检测时保护网络。
When a path is expressed using a label stack, the occurrence of label stacking will increase. A node may want to signal, in the control plane, its ability in terms of size of the label stack it can support.
使用标签堆栈表示路径时，标签堆栈的出现率将增加。节点可能希望在控制平面中根据其可支持的标签堆栈的大小来表示其能力。
A YANG data model [RFC6020] for SR configuration and operations has been defined in [SR-YANG].
[SR-YANG]中定义了SR配置和操作的YANG数据模型[RFC6020]。
When SR is applied to the IPv6 data plane, segments are identified through IPv6 addresses. The allocation, management, and troubleshooting of segment identifiers is no different than the existing mechanisms applied to the allocation and management of IPv6 addresses.
当SR应用于IPv6数据平面时，段通过IPv6地址标识。段标识符的分配、管理和故障排除与应用于IPv6地址分配和管理的现有机制没有什么不同。
The DA of the packet gives the active segment address. The segment list in the SRH gives the entire path of the packet. The validation of the source-routed path is done through inspection of DA and SRH present in the packet header matched to the equivalent routing table entries.
数据包的DA给出活动段地址。SRH中的段列表给出了数据包的整个路径。源路由路径的验证通过检查与等效路由表条目匹配的数据包报头中存在的DA和SRH来完成。
In the context of the SRv6 data plane, the source-routed path is encoded in the SRH as described in [IPv6-SRH]. The SRv6 source-routed path is instantiated into the SRH as a list of IPv6 addresses where the active segment is in the DA field of the IPv6 packet header. Typically, by inspecting, in any node, the packet header, it is possible to derive the source-routed path to which it belongs. Similar to the context of the SR-MPLS data plane, an implementation may originate path control and monitoring packets where the source-routed path is inserted in the SRH and where each segment of the path inserts in the packet the relevant data in order to measure the end-to-end path and performance.
在SRv6数据平面的上下文中，源路由路径在SRH中编码，如[IPv6 SRH]中所述。SRv6源路由路径作为IPv6地址列表实例化到SRH中，其中活动段位于IPv6数据包头的DA字段中。通常，通过在任何节点中检查分组报头，可以导出其所属的源路由路径。与SR-MPLS数据平面的上下文类似，实现可以发起路径控制和监视分组，其中源路由路径插入SRH中，并且路径的每个段在分组中插入相关数据，以便测量端到端路径和性能。
[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>.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, DOI 10.17487/RFC3031, January 2001, <https://www.rfc-editor.org/info/rfc3031>.
[RFC3031]Rosen，E.，Viswanathan，A.，和R.Callon，“多协议标签交换体系结构”，RFC 3031，DOI 10.17487/RFC3031，2001年1月<https://www.rfc-editor.org/info/rfc3031>.
[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>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, <https://www.rfc-editor.org/info/rfc8200>.
[RFC8200]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，STD 86，RFC 8200，DOI 10.17487/RFC8200，2017年7月<https://www.rfc-editor.org/info/rfc8200>.
[BGPLS-SR-EPE] Previdi, S., Filsfils, C., Patel, K., Ray, S., and J. Dong, "BGP-LS extensions for Segment Routing BGP Egress Peer Engineering", Work in Progress, draft-ietf-idr-bgpls-segment-routing-epe-15, March 2018.
[BGPLS-SR-EPE]Previdi，S.，Filsfils，C.，Patel，K.，Ray，S.，和J.Dong，“用于分段路由BGP出口对等工程的BGP-LS扩展”，正在进行的工作，草稿-ietf-idr-BGPLS-Segment-Routing-EPE-15，2018年3月。
[IPv6-SRH] Filsfils, C., Ed., Previdi, S., Leddy, J., Matsushima, S., and D. Voyer, Ed., "IPv6 Segment Routing Header (SRH)", Work in Progress, draft-ietf-6man-segment-routing-header-14, June 2018.
[IPv6 SRH]Filsfils，C.，Ed.，Previdi，S.，Leddy，J.，Matsushima，S.，和D.Voyer，Ed.，“IPv6段路由头（SRH）”，正在进行的工作，草稿-ietf-6man-Segment-Routing-Header-14，2018年6月。
[ISIS-SR-EXT] Previdi, S., Ed., Ginsberg, L., Ed., 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-19, July 2018.
[ISIS-SR-EXT]Previdi，S.，Ed.，Ginsberg，L.，Ed.，Filsfils，C.，Bashandy，A.，Gredler，H.，Litkowski，S.，Decarene，B.，和J.Tantsura，“分段布线的IS-IS扩展”，正在进行中，草案-ietf-ISIS-Segment-Routing-Extensions-2018年7月19日。
[OSPF-SR-EXT] 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-25, April 2018.
[OSPF-SR-EXT]Psenak，P.，Previdi，S.，Filsfils，C.，Gredler，H.，Shakir，R.，Henderickx，W.，和J.Tantsura，“用于段路由的OSPF扩展”，正在进行中，草案-ietf-OSPF-Segment-Routing-Extensions-252018年4月。
[OSPFv3-SR-EXT] Psenak, P., Ed., Filsfils, C., Previdi, S., Ed., Gredler, H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPFv3 Extensions for Segment Routing", Work in Progress, draft-ietf-ospf-ospfv3-segment-routing-extensions-13, May 2018.
[OSPFv3 SR EXT]Psenak，P.，Ed.，Filsfils，C.，Previdi，S.，Ed.，Gredler，H.，Shakir，R.，Henderickx，W.，和J.Tantsura，“用于段路由的OSPFv3扩展”，在建工程，草案-ietf-ospf-OSPFv3-段路由扩展-13，2018年5月。
[PCEP-SR-EXT] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., and J. Hardwick, "PCEP Extensions for Segment Routing", Work in Progress, draft-ietf-pce-segment-routing-12, June 2018.
[PCEP-SR-EXT]Sivabalan，S.，Filsfils，C.，Tantsura，J.，Henderickx，W.，和J.Hardwick，“分段布线的PCEP扩展”，在建工程，草案-ietf-pce-Segment-Routing-12，2018年6月。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, <https://www.rfc-editor.org/info/rfc3209>.
[RFC3209]Awduche，D.，Berger，L.，Gan，D.，Li，T.，Srinivasan，V.，和G.Swallow，“RSVP-TE：LSP隧道RSVP的扩展”，RFC 3209，DOI 10.17487/RFC3209，2001年12月<https://www.rfc-editor.org/info/rfc3209>.
[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)", RFC 4206, DOI 10.17487/RFC4206, October 2005, <https://www.rfc-editor.org/info/rfc4206>.
[RFC4206]Kompella，K.和Y.Rekhter，“具有通用多协议标签交换（GMPLS）流量工程（TE）的标签交换路径（LSP）层次结构”，RFC 4206，DOI 10.17487/RFC4206，2005年10月<https://www.rfc-editor.org/info/rfc4206>.
[RFC4381] Behringer, M., "Analysis of the Security of BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4381, DOI 10.17487/RFC4381, February 2006, <https://www.rfc-editor.org/info/rfc4381>.
[RFC4381]Behringer，M.，“BGP/MPLS IP虚拟专用网络（VPN）的安全性分析”，RFC 4381，DOI 10.17487/RFC4381，2006年2月<https://www.rfc-editor.org/info/rfc4381>.
[RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", RFC 4915, DOI 10.17487/RFC4915, June 2007, <https://www.rfc-editor.org/info/rfc4915>.
[RFC4915]Psenak，P.，Mirtorabi，S.，Roy，A.，Nguyen，L.，和P.Pillay Esnault，“OSPF中的多拓扑（MT）路由”，RFC 4915，DOI 10.17487/RFC4915，2007年6月<https://www.rfc-editor.org/info/rfc4915>.
[RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation of Type 0 Routing Headers in IPv6", RFC 5095, DOI 10.17487/RFC5095, December 2007, <https://www.rfc-editor.org/info/rfc5095>.
[RFC5095]Abley，J.，Savola，P.，和G.Neville Neil，“IPv6中0型路由头的弃用”，RFC 5095，DOI 10.17487/RFC5095，2007年12月<https://www.rfc-editor.org/info/rfc5095>.
[RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)", RFC 5120, DOI 10.17487/RFC5120, February 2008, <https://www.rfc-editor.org/info/rfc5120>.
[RFC5120]Przygienda，T.，Shen，N.，和N.Sheth，“M-ISIS：中间系统到中间系统（IS-ISs）的多拓扑（MT）路由”，RFC 5120，DOI 10.17487/RFC5120，2008年2月<https://www.rfc-editor.org/info/rfc5120>.
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, March 2009, <https://www.rfc-editor.org/info/rfc5440>.
[RFC5440]Vasseur，JP.，Ed.和JL。Le Roux主编，“路径计算元件（PCE）通信协议（PCEP）”，RFC 5440，DOI 10.17487/RFC5440，2009年3月<https://www.rfc-editor.org/info/rfc5440>.
[RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", RFC 5714, DOI 10.17487/RFC5714, January 2010, <https://www.rfc-editor.org/info/rfc5714>.
[RFC5714]Shand，M.和S.Bryant，“IP快速重路由框架”，RFC 5714，DOI 10.17487/RFC5714，2010年1月<https://www.rfc-editor.org/info/rfc5714>.
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, <https://www.rfc-editor.org/info/rfc5920>.
[RFC5920]方，L.，编辑，“MPLS和GMPLS网络的安全框架”，RFC 5920，DOI 10.17487/RFC5920，2010年7月<https://www.rfc-editor.org/info/rfc5920>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, <https://www.rfc-editor.org/info/rfc6020>.
[RFC6020]Bjorklund，M.，Ed.“YANG-网络配置协议的数据建模语言（NETCONF）”，RFC 6020，DOI 10.17487/RFC6020，2010年10月<https://www.rfc-editor.org/info/rfc6020>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, <https://www.rfc-editor.org/info/rfc6241>.
[RFC6241]Enns，R.，Ed.，Bjorklund，M.，Ed.，Schoenwaeld，J.，Ed.，和A.Bierman，Ed.，“网络配置协议（NETCONF）”，RFC 6241，DOI 10.17487/RFC6241，2011年6月<https://www.rfc-editor.org/info/rfc6241>.
[RFC6549] Lindem, A., Roy, A., and S. Mirtorabi, "OSPFv2 Multi-Instance Extensions", RFC 6549, DOI 10.17487/RFC6549, March 2012, <https://www.rfc-editor.org/info/rfc6549>.
[RFC6549]Lindem，A.，Roy，A.，和S.Mirtorabi，“OSPFv2多实例扩展”，RFC 6549，DOI 10.17487/RFC65492012年3月<https://www.rfc-editor.org/info/rfc6549>.
[RFC7938] Lapukhov, P., Premji, A., and J. Mitchell, Ed., "Use of BGP for Routing in Large-Scale Data Centers", RFC 7938, DOI 10.17487/RFC7938, August 2016, <https://www.rfc-editor.org/info/rfc7938>.
[RFC7938]Lapukhov，P.，Premji，A.，和J.Mitchell，Ed.，“BGP在大规模数据中心路由的使用”，RFC 7938，DOI 10.17487/RFC7938，2016年8月<https://www.rfc-editor.org/info/rfc7938>.
[RFC8084] Fairhurst, G., "Network Transport Circuit Breakers", BCP 208, RFC 8084, DOI 10.17487/RFC8084, March 2017, <https://www.rfc-editor.org/info/rfc8084>.
[RFC8084]Fairhurst，G.，“网络传输断路器”，BCP 208，RFC 8084，DOI 10.17487/RFC8084，2017年3月<https://www.rfc-editor.org/info/rfc8084>.
[RFC8202] Ginsberg, L., Previdi, S., and W. Henderickx, "IS-IS Multi-Instance", RFC 8202, DOI 10.17487/RFC8202, June 2017, <https://www.rfc-editor.org/info/rfc8202>.
[RFC8202]Ginsberg，L.，Previdi，S.，和W.Henderickx，“IS-IS多实例”，RFC 8202，DOI 10.17487/RFC8202，2017年6月<https://www.rfc-editor.org/info/rfc8202>.
[RFC8287] Kumar, N., Ed., Pignataro, C., Ed., Swallow, G., Akiya, N., Kini, S., and M. Chen, "Label Switched Path (LSP) Ping/Traceroute for Segment Routing (SR) IGP-Prefix and IGP-Adjacency Segment Identifiers (SIDs) with MPLS Data Planes", RFC 8287, DOI 10.17487/RFC8287, December 2017, <https://www.rfc-editor.org/info/rfc8287>.
[RFC8287]Kumar，N.，Ed.，Pignataro，C.，Ed.，Swallow，G.，Akiya，N.，Kini，S.，和M.Chen，“带MPLS数据平面的段路由（SR）IGP前缀和IGP邻接段标识符（SID）的标签交换路径（LSP）Ping/Traceroute”，RFC 8287，DOI 10.17487/RFC8287，2017年12月<https://www.rfc-editor.org/info/rfc8287>.
[RFC8355] Filsfils, C., Ed., Previdi, S., Ed., Decraene, B., and R. Shakir, "Resiliency Use Cases in Source Packet Routing in Networking (SPRING) Networks", RFC 8355, DOI 10.17487/RFC8355, March 2018, <https://www.rfc-editor.org/info/rfc8355>.
[RFC8355]Filsfils，C.，Ed.，Previdi，S.，Ed.，DeClaene，B.，和R.Shakir，“网络（SPRING）网络中源数据包路由的弹性用例”，RFC 8355，DOI 10.17487/RFC8355，2018年3月<https://www.rfc-editor.org/info/rfc8355>.
[RFC8403] Geib, R., Ed., Filsfils, C., Pignataro, C., Ed., and N. Kumar, "A Scalable and Topology-Aware MPLS Data-Plane Monitoring System", RFC 8403, DOI 10.17487/RFC8403, July 2018, <http://www.rfc-editor.org/info/rfc8403>.
[RFC8403]Geib，R.，Ed.，Filsfils，C.，Pignataro，C.，Ed.，和N.Kumar，“可扩展和拓扑感知MPLS数据平面监控系统”，RFC 8403，DOI 10.17487/RFC8403，2018年7月<http://www.rfc-editor.org/info/rfc8403>.
[SR-CENTRAL-EPE] Filsfils, C., Previdi, S., Dawra, G., Aries, E., and D. Afanasiev, "Segment Routing Centralized BGP Egress Peer Engineering", Work in Progress, draft-ietf-spring-segment-routing-central-epe-10, December 2017.
[SR-CENTRAL-EPE]Filsfils，C.，Previdi，S.，Dawra，G.，Aries，E.，和D.Afanasiev，“分段路由集中式BGP出口对等工程”，在建工程，草稿-ietf-spring-Segment-Routing-CENTRAL-EPE-10，2017年12月。
[SR-MPLS] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing with MPLS data plane", Work in Progress, draft-ietf-spring-segment-routing-mpls-14, June 2018.
[SR-MPLS]Bashandy，A.，Ed.，Filsfils，C.，Ed.，Previdi，S.，DeClaene，B.，Litkowski，S.，和R.Shakir，“使用MPLS数据平面的段路由”，正在进行的工作，草案-ietf-spring-Segment-Routing-MPLS-142018年6月。
[SR-YANG] Litkowski, S., Qu, Y., Sarkar, P., and J. Tantsura, "YANG Data Model for Segment Routing", Work in Progress, draft-ietf-spring-sr-yang-09, June 2018.
[SR-YANG]Litkowski，S.，Qu，Y.，Sarkar，P.，和J.Tantsura，“分段布线的YANG数据模型”，正在进行的工作，草稿-ietf-spring-SR-YANG-092018年6月。
Acknowledgements
致谢
We would like to thank Dave Ward, Peter Psenak, Dan Frost, Stewart Bryant, Pierre Francois, Thomas Telkamp, Ruediger Geib, Hannes Gredler, Pushpasis Sarkar, Eric Rosen, Chris Bowers, and Alvaro Retana for their comments and review of this document.
我们要感谢Dave Ward、Peter Psenak、Dan Frost、Stewart Bryant、Pierre Francois、Thomas Telkamp、Ruediger Geib、Hannes Gredler、Pushpasis Sarkar、Eric Rosen、Chris Bowers和Alvaro Retana对本文件的评论和评论。
Contributors
贡献者
The following people have substantially contributed to the definition of the Segment Routing architecture and to the editing of this document:
以下人员对段布线架构的定义和本文件的编辑做出了重大贡献：
Ahmed Bashandy Cisco Systems, Inc. Email: bashandy@cisco.com
Ahmed Bashandy Cisco Systems，Inc.电子邮件：bashandy@cisco.com
Martin Horneffer Deutsche Telekom Email: Martin.Horneffer@telekom.de
马丁·霍内弗德国电信电子邮件：马丁。Horneffer@telekom.de
Wim Henderickx Nokia Email: wim.henderickx@nokia.com
Wim Henderickx诺基亚电子邮件：Wim。henderickx@nokia.com
Jeff Tantsura Email: jefftant@gmail.com
Jeff Tantsura电子邮件：jefftant@gmail.com
Edward Crabbe Email: edward.crabbe@gmail.com
爱德华·克拉布电子邮件：爱德华。crabbe@gmail.com
Igor Milojevic Email: milojevicigor@gmail.com
Igor Milojevic电子邮件：milojevicigor@gmail.com
Saku Ytti TDC Email: saku@ytti.fi
Saku Ytti TDC电子邮件：saku@ytti.fi
Authors' Addresses
作者地址
Clarence Filsfils (editor) Cisco Systems, Inc. Brussels Belgium
Clarence Filsfils（编辑）思科系统公司比利时布鲁塞尔
Email: cfilsfil@cisco.com
Email: cfilsfil@cisco.com
Stefano Previdi (editor) Cisco Systems, Inc. Italy
Stefano Previdi（编辑）意大利思科系统公司
Email: stefano@previdi.net
Email: stefano@previdi.net
Les Ginsberg Cisco Systems, Inc.
莱斯金斯伯格思科系统公司。
Email: ginsberg@cisco.com
Email: ginsberg@cisco.com
Bruno Decraene Orange FR
布鲁诺橙
Email: bruno.decraene@orange.com
Email: bruno.decraene@orange.com
Stephane Litkowski Orange France
斯特凡利特科夫斯基橙法国
Email: stephane.litkowski@orange.com
Email: stephane.litkowski@orange.com
Rob Shakir Google, Inc. 1600 Amphitheatre Parkway Mountain View, CA 94043 United States of America
Rob Shakir Google，Inc.美国加利福尼亚州山景大道1600号圆形剧场，邮编94043
Email: robjs@google.com
Email: robjs@google.com