RFC8402 Segment Routing Architecture 翻译

 黑色为原文 紫色为翻译 红色为校注

 

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 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 headerThe 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）表示。下一个活动段则被新路由头中的指针表示。

rfc8754中指出 Routing headers are defined in RFC8200. The Segment Routing Header (SRH) has a new RoutingType (4).。

 

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.

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.

 

Copyright NoticeCopyright (c) 2018 IETF Trust and the persons identified as the document authors.All rights reserved.

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.

Table of Contentts
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

 

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支持逐流显式路由，同时仅在SR域的入口节点维护每流状态。

 

A segment is often referred to by its Segment Identifier (SID).

一个段经常被它的段ID所指代。

 

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).

一个段可以关联服务指令（例如，这个包应该被一个关联该段的容器或者虚拟机处理）。一个段可以关联一个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策略中（例如，pre-computed local protection [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架构允许控制器发现哪些SIDs在哪些节点上被实例化，哪些本地和全局标签在哪些节点上不可用。

 

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的数据平面实例：基于MPLS的SR（SR-MPLS）和基于IPv6的SR（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架构无需更改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通过新类型的路由头应用到IPv6架构，这个头被称为SR头（SRH）[IPv6-SRH].指令和段关联并编码为IPv6地址。SRv6段也被称为SRv6 SID。一个SR策略被实例化为路由头中的SRv6 SIDs列表。活动段被实例化为包的目的地址。下一个活动段由SRH中的SegmentsLeft（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.

注：本文件定义了段路由的体系结构，包括基本对象和功能的定义，以及总体设计的描述，但没有定义体系结构的实现方法，这在许多参考文件中都有，为了方便读者阅读，本文中提到了其中一些。

 

2 Terminology

术语

 

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 allcapitals, as shown here.

文中关键字 MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and"OPTIONAL"的解释在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通常用来代替术语“Segment”，尽管这在技术上并不精确，因为它忽略了任何必要的翻译。

 

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

一个和段明确关联的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.

Segment Routing domain (SR domain):  参与源路由模式的一组节点.这些节点可能连接在相同的物理架构上(例如一个服务提供商的网路).他们可能远距离相连(比如通过vpn或overlay封装). 如果多协议实例被部署,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].

 

Active Segment: 被接收的路由器用来处理包的段.在mpls数据平面,它就是顶层标签.在IPv6 数据平面,它就是目的地址.

 

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].

PUSH：插入一个段到段列表顶部. 在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.

NEXT:活动段被完成时，检查下一个段。下一个段编变为活动的。在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.

CONTINUE：活动段没有被完成，因此它仍然是活动的。在SR-MPLS域，CONTINUE被作为栈顶标签的swap动作执行[RFC3031]。在SRv6，这是一个根据规范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 Global Block (SRGB):在SR域中的一组全局段，如果一个节点在多个SR域中。每个SR域有一个SRGB。在SR-MPLS中，SRGB是一个节点的本地属性，它标识全局段保留的本地标签集。在一个SR-MPLS中强烈推荐所有节点使用相同的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 Local Block (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.

Global Segment:属于域SRGB的段。段所关联的指令是定义在域水平的。一个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之外的本地标签。在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-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 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段是一个代表IGP前缀的段。当一个IGP-Prefix段在SR IGP实例/拓扑中是全局的，它标示根据路径转发包的指令。这个路径是在IGP实例中通过其特定路由算法计算的。也被写为"prefix segment"。

 

Prefix-SID: the SID of the IGP-Prefix segment.

IGP-Prefix段的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-Anycast段是被一组路由器宣告的任意开销前缀的IGP-Prefix段

 

Anycast-SID: the SID of the IGP-Anycast segment.

IGP-Anycast段的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-Adjacency段是一个附属单向邻接或者一组单项邻接的IGP段。

 

Adj-SID: the SID of the IGP-Adjacency segment.

 

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-Node段是一个标示特定路由器的段（例如，一个换回）。也被称为"Node Segment"。

 

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策略上。段列表可以显示特例化为一个mpls标签栈或者一个SRV6 SID有序列表。二者选其一，段列表根据目的或者一组最优对象和限制条件（例如： latency, affinity, SRLG等）来计算。计算器可以使本地或者委托PCE服务器。一个SR策略能被操作者配置，根据NETCONF [RFC6241]或者PCEP [RFC5440]。一个策略可以被TE，OAM，FRR使用。

问题：latency, affinity, SRLG：这些的都是啥？

 

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.

一个路由策略中的段数量。在节点N实例化SR策略的实体应该能够发现节点N的深度插入能力。例如，[PCEP-SR-EXT]中描述的PCEP-SR能力广告就是发现这种能力的一种手段。

理解：深度插入能力即能支持多深。

 

Forwarding Information Base (FIB): the forwarding table of a node

节点的转发表

3. Link-State IGP Segments

 

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 SID”。它们作为路由表达式在整个域中起关键作用。这样的路径可以表示为单个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]中定义。

 

3.1. IGP-Prefix Segment (Prefix-SID)

 

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前缀段的上下文包括前缀、拓扑和算法。只要元组<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]中定义。

 

3.1.1. Prefix-SID Algorithm

Segment Routing supports the use of multiple routing algorithms, i.e, ifferent constraint-based shortest-path calculations can be upported. An algorithm identifier is included as part of a Prefix-ID advertisement. Specification of how an algorithm-specific path alculation is done is required in the document defining the agorithm.  

分段路由支持多种路由算法的使用，即支持基于不同约束的最短路径计算。算法标识符作为前缀ID宣告的一部分。对于本文中定义的算法，需说明如何进行特定于算法的路径计算。

 

This document defines two algorithms:

本文定义两种算法：

 

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.

最短路径优先：此算法是默认行为。数据包沿着IGPs采用的众所周知的ECMP-aware最短路径优先（SPF）算法转发。但是，它明确允许一个中点根据本地策略实现另一个转发。最短路径优先算法实际上是大多数网络的默认和当前行为，在这些网络中，本地策略可能会覆盖SPF决策。

 

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 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. 

严格最短路径优先（Strict SPF）：该算法要求根据ECMP感知的SPF算法转发数据包，并指示路径中的任何路由器忽略覆盖SPF决策的任何可能的本地策略。使用严格的SPF算法公布的SID确保了数据包要采用的路径是预期的，而不是改变的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的包应该沿着使用指定算法计算的路径转发。为了实现这一点，需要支持指定算法的路由器的全连接拓扑。

注意:全连接，两两互联。

3.1.2. SR-MPLS

 

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域中的所有节点上配置相同的SRGB。这简化了故障排除，因为相同的标签将与所有节点上的相同前缀相关联。此外，它简化了对anycast的支持，详见第3.3节。

 

The following behaviors are associated with SR operating over the MPLS data plane:

以下行为与在MPLS数据平面上操作的SR相关：

 

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.

IGP前缀段的IGP信令扩展包括一个标志，用于指示前缀所属于节点的直接连接的邻居在处理SID时是执行NEXT操作还是CONTINUE操作。这种行为相当于MPLS中的倒数第二跳弹出（NEXT）或最后一跳弹出（CONTINUE）。

 

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.

Prefix-SID是按照与IP地址分配类似的过程以MPLS标签（或SRGB中的索引）的形式分配的。通常，Prefix-SID由操作员（或网络管理系统（NMS））按策略分配，SID很少更改。

 

The allocation process MUST NOT allocate the same Prefix-SID to different prefixes.

分配程序不能将相同的Prefix-SID分配给不同的前缀。

 

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.

 如果节点得知前缀SID的值超出本地配置的SRGB范围，则该节点不得使用前缀SID，并应发出错误日志报告配置错误。 

 

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:

Incoming Active Segment: SID-R

Ingress Operation: NEXT

Egress interface: NULL

如果节点N为属于N的前缀R宣告一个Prefix-SID SID-R并将CONTINUE作为直连邻居执行的动作，那么N必需维护以下路由条目：

入活动段：SID-R

入动作：NEXT

出接口：NULL

 

A remote node M MUST maintain the following FIB entry for any learned Prefix-SID SID-R attached to prefix R:

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.

远端节点M必为学习的属于前缀R的Prefix-SID SID-R需维护以下路由条目：

活动段：SID-R

入操作：如果R的下一跳是R的源并且M被指示移除活动段：NEXT

否则： CONTINUE

出接口：沿着宣告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是特定于给定算法的，如果与算法相关联的流量到达不支持该算法的节点，则该流量将被丢弃，因为没有与传入标签匹配的转发条目。

 

3.1.3. SRv6

 

When SR is used over the IPv6 data plane:

 

A Prefix-SID is an IPv6 address.

 

An operator MUST explicitly instantiate an SRv6 SID. IPv6 node addresses are not SRv6 SIDs by default.

运算符必须显式实例化SRv6 SID。默认情况下，IPv6节点地址不是SRv6 SID。

A node N advertising an IPv6 address R usable as a segment identifier MUST maintain the following FIB entry:

Incoming Active Segment: R

Ingress Operation: NEXT

Egress interface: NULL

宣告一个Ipv6地址R可作为段鉴别值的节点必须维护以下路由条目：

入活动段：R

入动作：NEXT

出接口：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节点都将为任何前缀维护一个纯ipv6fib条目，而不管前缀是否代表一个段。这允许即使不支持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 algorithmspecific 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的路径转发到目标节点。

 

3.2. IGP-Node Segment (Node-SID)

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 Node-SID不能与同一路由域中由多个路由器拥有的前缀相关联。

 

3.3. IGP-Anycast Segment (Anycast-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. Within an anycast group, all routers in an SR domain MUST advertise the same prefix with the same SID value.

IGP选播段不能引用特定节点。在选播组中，SR域中的所有路由器必须用相同的SID值播发相同的前缀。

注：任播(Anycast)，又称为选播、泛播或任意播，是IPv6中定义的一种新型通信服务。

 

3.3.1. Anycast-SID in SR-MPLS

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.

图一给出一个两组转发设备的网络示例。组A包含{A1, A2, A3, and A4}。它们全被提供任播地址92.0.2.10/32和Anycast-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, and B4}，它们全被提供任播地址192.0.2.1/32和Anycast-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可以选择一个转发组。这样做会将组的Anycast-SID压入栈。

 

Processing the anycast, and subsequent segments, requires special care.

处理任播和后续段需要谨慎。

 

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有效负载中。

 

Label allocated by R1 for Anycast-SID 100 (outer label).

R1为Anycast-SID 100分配标签(出标签)

 

Label allocated by the nearest router in Group A for SID 30 (for destination PE3).

组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可能是不同硬件厂商的设备。如果两者不能为SID30分配相同的标签，就为无法使用任播组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).

使用一个任播段而不在所有属于同一任播组的节点配置相同的SRGB将引起路由失败（在mplsvpn部署中，VPN之间可能会泄漏一些流量）。

 

3.4.  IGP-Adjacency Segment (Adj-SID)

 

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的Node-SID，SNL是节点N通过链路L附加到其邻接处的Adj-SID，将沿着最短路径转发到N，然后由N切换到链路L，而不考虑任何IP最短路径。如果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 loadbalance 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).

类似地，当使用全局Adj-SID时，在SR域内任何位置注入具有段列表{SNL}（其中SNL是节点N通过链路L附加到其邻接处的全局Adj-SID）的包将沿着最短路径转发到N，然后由N交换，而不考虑任何IP最短路径，如果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的编码包括一组支持以下功能的标志：

 

 

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 policybased decision; that is, for a given policy protection may or may not be desirable.

符合保护条件（例如，使用IPFRR或MPLS-FRR）。保护允许在与Adj-SID相关联的接口down的情况下，包仍然可以通过备用路径转发。使用保护显然是基于政策的决定；也就是说，对于给定的策略，保护可能是可取的，也可能是不可取的。

 

Indication whether the Adj-SID has local or global scope. Default scope SHOULD be local.

Adj-SID是本地或者全局范围的指示。默认范围是本地的。

 

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.

控制平面重启时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.

节点应该为每个相邻节点分配一个Adj-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.

一个节点可以为同一邻接分配多个Adj-SIDs。例如，支持符合保护条件的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邻接的所有Adj-SIDs，IGP不能执行并行邻接抑制。

 

 

When a node binds an Adj-SID V to a local data-link L, the node MUST install the following FIB entry:

Incoming Active Segment: V

Ingress Operation: NEXT

Egress Interface: L

当一个节点绑定一个到本地链路L的Adj-SID V，节点必需安装以下转发条目：

Incoming Active Segment: V

Ingress Operation: NEXT

Egress Interface: 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算法所做的路由决策。

 

3.4.1. Parallel Adjacencies

 

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:

Incoming Active Segment: W

Ingress Operation: NEXT

Egress interfaces: load-balance between any data-link within set B

节点必须为附加到一组链路B的值为W的任何本地源Adj-SID安装FIB条目：

Incoming Active Segment: W

Ingress Operation: NEXT

Egress interfaces: load-balance between any data-link within set 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

当使用并行相邻并与相同的Adj-SID关联时，为了优化负载平衡功能，可以将“权重”因子与每个相邻的Adj SID关联起来。权重告诉入口（或SDN/编排系统）关于并行邻接的负载平衡因子。如图3所示，A和B通过两个平行的邻接连接起来

 

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）上的流量，即在链路2上传输的数据包是链路1的两倍

 

3.4.2. LAN Adjacency Segments

 

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).

在局域网子网中，链路状态协议定义了指定路由器（OSPF中的DR）或指定中间系统（DIS，IS-IS）的概念，它们在广播子网中进行泛洪，并在一个特殊的路由更新（OSPF Type2 LSA或IS-IS伪节点LSP）中描述局域网的拓扑结构。

 

 

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中每个邻居相关联的Adj SID。

 

3.5. Inter-Area Considerations

 

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数据平面。

In Area 2, node Z allocates Node-SID 150 to his local IPv6 prefix 2001:DB8::2:1/128.

在区域2中，节点Z将Node-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。

区域边界路由器（ABRs）G和J通过根据正常的区域间/级别IGP传播规则创建前缀的新实例，将前缀及其SIDs传播到主干区域。

 

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，前缀为sid150，并由节点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.

因此，结果是Prefix-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.

当node S向2001:DB8:：2:1/128发送流量时，它将Node-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根据活动段（Node-SID（150））转发分组。转发继续跨越区域边界，使用相同的Node-SID（150），直到数据包到达目的地。

4. BGP Segments

BGP segments may be allocated and distributed by BGP.

BGP段可以由BGP分配和分发

 

4.1. BGP-Prefix Segment

 

A BGP-Prefix segment is a BGP segment attached to a BGP prefix.

BGP-Prefix段是一个附属于BGP prefix的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 hyperscale spine-leaf topology where connectivity is learned solely via BGP [RFC7938]

BGP前缀段的一个可能的用例是一个无IGP的超尺度spine-leaf拓扑，其中连通性仅通过BGP学习[RFC7938]

 

4.2. BGP Peering Segments

 

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对等SIDs。它们支持源路由域间路径的表达式。

 

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对等工程策略至少包括两个部分：所选出口节点的Node-SID和所选出口节点对等或对等接口的BGP对等段。

 

Three types of BGP peering segments/SIDs are defined: PeerNode SID, PeerAdj SID, and PeerSet SID.

三种类型的BGP对等段/SIDS 被定义: PeerNode SID, PeerAdj SID, and PeerSet SID.

 

o PeerNode SID: a BGP PeerNode segment/SID is a local segment. At the BGP node advertising it, its semantics are:

PeerNode SID： 是一个本地段。BGP节点宣告它，它有如下语义：

 

* SR operation: NEXT.

SR动作：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:

PeerAdj SID: 是一个本地段。 对等节点宣告它，语义如下：

 

* SR operation: NEXT.

SR动作：NEXT

* Next-Hop: the peer connected through the interface to which the segment is related.

下一跳：通过与段相关的接口连接的对等体。

 

* PeerSet SID: a BGP PeerSet segment/SID is a local segment. At the BGP node advertising it, the semantics are:

PeerSet SID:　本地段。　对等节点宣告它，语义如下：

 

* SR operation: NEXT.

SR动作：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中的所有相连对等或者一部分对等。一个组可以跨越AS。组时操作者设置的一个策略。

 

The BGP extensions necessary in order to signal these BGP peering segments are defined in [BGPLS-SR-EPE].

为通知BGP对等必需的BGP扩展定义在[BGPLS-SR-EPE]。

 

5. Binding Segment

绑定段

 

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. 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或全局SID。 如果是本地的，应该从SRLB中分配一个BSID。 如果是全局的，则必须从SRGB分配BSID。 BSID的使用允许仅将实例化策略（SID列表）存储在需要实施该策略的一个或多个节点上。 然后，将流量定向到支持该策略的节点仅需要施加BSID。 如果策略更改，这还意味着仅需要强制实施该策略的节点。 该策略的用户不受影响。

 

 

5.1. IGP Mirroring Context Segment

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地址或Node-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的上下文中处理底层段。

 

6. Multicast

Segment Routing is defined for unicast. The application of the source-route concept to Multicast is not in the scope of this document.

源路由为单播定义。组播的源路由能力不再本文范围内。

 

7. IANA Considerations

This document has no IANA actions.

本文没有IANA动作。

8. Security Considerations

 

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。

 

8.1. SR-MPLS

 

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数据包。

 

8.2. SRv6

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.

域边界路由器必须过滤发往受信任域的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 Evasion of access controls

逃避访问控制

 

o Hiding the source of DoS attacks

隐藏DoS攻击源

 

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-SRH]中定义了新的基于IPv6的分段路由报头。 本文档也讨论了以上安全问题。

 

8.3. Congestion Control

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]中提出的其他解决方案也可能适用。

 

9. Manageability Considerations

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].

MPLS数据平面的SR OAM用例在[RFC 8403]中定义。

 

SR OAM procedures for the MPLS data plane are defined in [RFC8287].

MPLS数据平面的SR OAM程序在[RFC 8287]中定义。

 

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路由器从为SR扩展的不同路由协议接收SID的通告（索引，标签或IPv6地址）。 这些协议中的每一个都有监视和故障排除机制，以提供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 sourcerouted 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 endto-end path and performance.

在SRv6数据平面的上下文中，如[IPv6-SRH]中所述，源路由路径在SRH中编码。SRv6源路由路径作为IPv6地址列表实例化到SRH中，其中活动段位于IPv6数据包头的DA字段中。通常，通过在任何节点中检查数据包头，可以得出其所属的源路由路径。类似于SR-MPLS数据平面的上下文，一种实现可以发起路径控制和监视数据包，其中将源路由路径插入SRH中，并且路径的每个段在数据包中插入相关数据，以便测量端到端路径和性能。

 

10. References

10.1. Normative References

[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>.

[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>.

[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>.

[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>. Filsfils, et al. Standards Track [Page 26]
RFC 8402 Segment Routing July 2018

10.2. Informative References

[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-bgplssegment-routing-epe-15, March 2018.
 

[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-routingheader-14, June 2018.
 

[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-routingextensions-19, July 2018.
 

[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.
 

[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.
 

[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, June2018.
[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>.Filsfils, et al. Standards Track [Page 27] RFC 8402 Segment Routing July 2018
 

[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>.
 

[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>.
 

[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>.
 

[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>.
 

[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>.
 

[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>.
 

[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>.
[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>.
 

[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>.Filsfils, et al. Standards Track [Page 28]
RFC 8402 Segment Routing July 2018

[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>.
[RFC6549] Lindem, A., Roy, A., and S. Mirtorabi, "OSPFv2 MultiInstance Extensions", RFC 6549, DOI 10.17487/RFC6549, March 2012, <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>.
 

[RFC8084] Fairhurst, G., "Network Transport Circuit Breakers",BCP 208, RFC 8084, DOI 10.17487/RFC8084, March 2017,<https://www.rfc-editor.org/info/rfc8084>.
[RFC8202] Ginsberg, L., Previdi, S., and W. Henderickx, "IS-ISMulti-Instance", RFC 8202, DOI 10.17487/RFC8202, June 2017, <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>.
 

[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>.
 

[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>.
 

[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-segmentrouting-central-epe-10, December 2017. Filsfils, et al. Standards Track [Page 29]
RFC 8402 Segment Routing July 2018 

[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-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. 

Acknowledgements
We would like to thank Dave Ward, Peter Psenak, Dan Frost, StewartBryant, Pierre Francois, Thomas Telkamp, Ruediger Geib, HannesGredler, Pushpasis Sarkar, Eric Rosen, Chris Bowers, and AlvaroRetana for their comments and review of this document.