SRv6 RFC9252

1. 简介

SRv6是指在IPv6数据面上的分段路由实例。

用BGP通告两个Provider Edge(PE)之间的可达性。

基于SRv6的BGP服务是指：以BGP为控制平面、SRv6为数据平面的三层或者二层的overlay services。本文档定义了基于SRv6的BGP服务的过程与消息，包括L3VPN、EVPN等。它建立在”BGP/MPLS IP Virtual Private Networks (VPNs)” [RFC4364] 和 “BGP MPLS-Based Ethernet VPN” [RFC7432]。

SRv6 SID是指定义在[RFC8402]中的SRv6段标识符。

SRv6服务SID是指与advertising PE router特定SRv6端点行为之一相关联的SRv6 SID，例如（但不限于）在L3VPN服务的情况下定义在[RFC8986]中的End.DT（在虚拟路由和转发（VRF）表中查找）或End.DX（连接到下一跳）行为。本文档描述了PE之间的现有BGP消息如何携带SRv6服务SID并且互连PE形成VPN。

为了向SRv6服务提供尽力而为的连接，出口PE通过BGP overlay service route向SRv6 service SID发送信号。入口PE将有效载荷封装在外部IPv6报头中，其中目标地址是出口PE提供的SRv6服务SID。PE之间的网络设备只需要支持IPv6转发即可[RFC8200]。

为了结合从入口PE到出口PE的Service Level Agrssment(SLA)提供SRv6服务。出口PE使用color Extended Community[RFC9012]为途径的路由器着色，引导这些路由器的流量(例如第八章的SEGMENT-ROUTING-POLICY)。入口PE将有效载荷封装在外部IPv6报头中，其中包含与SLA相关联的SR策略段列表[RFC8754]。在SRH段列表中的底层网络节点必须支持SRv6。

1.1. Requirements Language

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.

2. SRv6 Service TLV

本文档扩展了BGP前缀SID属性[RFC8669]的使用。

SRv6服务TLV被定义为BGP前缀SID属性的两个新TLV，以实现L3和L2服务的SRv6 SID。

SRv6 L3 TLV

这种TLV基于SRv6 L3服务的SID信息进行编码。它对应于MPLS标签在通过[RFC4364]、[RFC4659]、[RFC8950]和[RFC9136]中定义的第3层服务路由接收时提供的等效功能。一些SRv6端点行为被编码为诸如：End.DX4, End.DT4, End.DX6, End.DT6, 和End.DT46等。

SRv6 L2 TLV

该TLV用于封装基于SRv6的L2层业务的服务SID信息。其功能等同于 [RFC7432] 中定义的以太网 VPN (EVPN) 二层业务路由类型所使用的 MPLS 标签。可封装的 SRv6 端点行为包括但不限于：End.DX2, End.DX2V, End.DT2U, 和 End.DT2M。

当出口PE启用基于SRv6数据平面的BGP业务时，会通过一个或多个SRv6业务TLV通告SRv6服务SID。这些TLV封装在BGP Prefix-SID属性中，并附加于 [RFC4760]、[RFC4659]、[RFC8950]、[RFC7432]、[RFC4364] 和 [RFC9136] 所定义的多协议BGP (MP-BGP)网络层可达性信息(NLRI)上（如第5节和第6节所述）。

本文档不涉及基于SRv6的BGP组播VPN (MVPN)业务[RFC6513]的支持方案。

下文是在BGP Prefix-SID属性中编码的SRv6服务TLV:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   TLV Type    |         TLV Length            |   RESERVED    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   SRv6 Service Sub-TLVs                                      //
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        Figure 1: SRv6 Service TLVs

TLV Type (1 octet):
    L3服务为5；L2服务为6。

TLV Length (2 octets):
    长度

RESERVED (1 octet):
    保留子段

SRv6 Service Sub-TLVs (variable):
    TLV无序列表格式的SRv6服务信息。格式如下：

当BGP发起者收到包含`BGP Prefix-SID`属性（含一个或多个 SRv6 业务 TLV）的路由时，其在向其他对等体通告该路由需遵循以下规则：

* 若 BGP 下一跳在通告过程中保持不变：

 SRv6 业务 TLV（包括所有无法识别的子 TLV 和子子 TLV 类型）应继续传播

 所有 TLV/子 TLV/子子 TLV 中的保留字段必须保持原值传播

* 若 BGP 下一跳发生变更：

 TLV/子 TLV/子子 TLV 应更新为本地分配的 SRv6 SID 信息

 必须移除所有接收到的无法识别的子 TLV 和子子 TLV

3. SRv6 Service Sub-TLVs

格式如下：

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRv6 Service  |    SRv6 Service               | SRv6 Service //
| Sub-TLV       |    Sub-TLV                    | Sub-TLV      //
| Type          |    Length                     | Value        //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 2: SRv6 Service Sub-TLVs

3.1. SRv6 SID Information Sub-TLV

SRv6 Service Sub-TLV类型1表示SRv6 SID信息。TLV包含一个SRv6 SID及其属性。

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRv6 Service  |    SRv6 Service               |               |
| Sub-TLV       |    Sub-TLV                    |               |
| Type=1        |    Length                     |  RESERVED1    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  SRv6 SID Value (16 octets)                                  //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Svc SID Flags |   SRv6 Endpoint Behavior      |   RESERVED2   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  SRv6 Service Data Sub-Sub-TLVs                              //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 3: SRv6 SID Information Sub-TLV

SRv6 Service Sub-TLV Type (1 octet):
   SRv6 SID Information Sub-TLV.

SRv6 SID Value (16 octets):
   SRv6 SID编码，定义于[RFC8986].

SRv6 Service SID Flags (1 octet):
   未定义

SRv6 Endpoint Behavior (2 octets):
   本字段编码与 SRv6 SID 关联的端点行为。所用值取自 IANA "Segment Routing" 注册表中的 "SRv6 Endpoint Behaviors" 子注册表（由 [RFC8986] 引入）。当通告路由器需隐藏其本地实例化 SRv6 SID 的实际行为时，可使用不透明 SRv6 端点行为（即值 0xFFFF）。

SRv6 Service Data Sub-Sub-TLV Value (variable):
   SID的属性

SRv6 SID 的端点行为选择完全由通告发起方决定。尽管第 5 节和第 6 节列出了特定路由通告通常应使用的 SRv6 端点行为，但接收其他 SRv6 端点行为（如未来可能引入的新行为）不视为错误。接收方不得将无法识别的 SRv6 端点行为视为无效（涉及参数使用的行为除外，参数验证详见第 3.2.1 节）。实现方案可在收到非预期行为时记录速率限制型告警。

当存在多个 SRv6 SID 信息子 TLV 时，入口 PE 应优先采用首个子 TLV 实例中的 SRv6 SID。实现方案可提供本地策略覆盖此选择机制。

3.2. SRv6 Service Data Sub-Sub-TLVs

格式如下：

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Data |  Sub-Sub-TLV Length               |Sub-Sub TLV //
| Sub-Sub-TLV  |                                   |  Value     //
| Type         |                                   |            //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 4: SRv6 Service Data Sub-Sub-TLVs

3.2.1. SRv6 SID Structure Sub-Sub-TLV

SRv6 业务数据子子TLV类型1被分配给SRv6 SID结构子子TLV。该SRv6 SID结构子子TLV用于通告SRv6 SID各组成部分的长度（定义见[RFC8986]）。术语”定位块(Locator Block)”和”定位节点(Locator Node)”分别对应[RFC8986]第3.1节定义的SRv6定位符中的B段与N段。此子子TLV作为SRv6 SID信息子TLV的组成部分承载。

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRv6 Service  |    SRv6 Service               | Locator Block |
| Data Sub-Sub  |    Data Sub-Sub-TLV           | Length        |
| -TLV Type=1   |    Length                     |               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator Node  | Function      | Argument      | Transposition |
| Length        | Length        | Length        | Length        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transposition |
| Offset        |
+-+-+-+-+-+-+-+-+

               Figure 5: SRv6 SID Structure Sub-Sub-TLV

SRv6 Service Data Sub-Sub-TLV Type (1 octet):
   SID的结构信息

Locator Block Length (1 octet):
   This field contains the length of the SRv6 SID Locator Block in bits.

Locator Node Length (1 octet):
   This field contains the length of the SRv6 SID Locator Node in bits.

Function Length (1 octet):
   This field contains the length of the SRv6 SID Function in bits.

Argument Length (1 octet):
   This field contains the length of the SRv6 SID Argument in bits.

Transposition Length (1 octet):
   This field is the size in bits for the part of the SID that has been transposed (or shifted) into an MPLS Label field.

Transposition Offset (1 octet):
   This field is the offset position in bits for the part of the SID that has been transposed (or shifted) into an MPLS Label field.

Section 4 describes mechanisms for the signaling of the SRv6 Service SID by transposing a variable part of the SRv6 SID value and carrying this variable part in existing MPLS Label fields to achieve more efficient packing of those service prefix NLRIs in BGP update messages. The SRv6 SID Structure Sub-Sub-TLV contains appropriate length fields when the SRv6 Service SID is signaled in split parts to enable the receiver to put together the SID accurately.

Transposition Offset indicates the bit position, and Transposition Length indicates the number of bits that are being taken out of the SRv6 SID value and encoded in the MPLS Label field. The bits that have been shifted out MUST be set to 0 in the SID value.

A Transposition Length of 0 indicates nothing is transposed and that the entire SRv6 SID value is encoded in the SID Information Sub-TLV. In this case, the Transposition Offset MUST be set to 0.

The size of the MPLS Label field limits the bits transposed from the SRv6 SID value into it. For example, the size of the MPLS Label field is 20 bits in [RFC4364] and [RFC8277], and the size is 24 bits in [RFC7432].

As defined in [RFC8986], the sum of the Locator Block Length (LBL), Locator Node Length (LNL), Function Length (FL), and Argument Length (AL) fields MUST be less than or equal to 128 and greater than the sum of Transposition Offset and Transposition Length.

As an example, consider that the sum of the Locator Block and the Locator Node parts is 64. For an SRv6 SID where the entire Function part of size 16 bits is transposed, the transposition offset is set to 64 and the transposition length is set to 16. While for an SRv6 SID for which the FL is 24 bits and only the lower order 20 bits are transposed (e.g., due to the limit of the MPLS Label field size), the transposition offset is set to 68 and the transposition length is set to 20.

BGP speakers that do not support this specification may misinterpret, on the reception of an SRv6-based BGP service route update, the part of the SRv6 SID encoded in an MPLS Label field(s) as MPLS label values for MPLS-based services. Implementations supporting this specification MUST provide a mechanism to control the advertisement of SRv6-based BGP service routes on a per-neighbor and per-service basis. The details of deployment designs and implementation options are outside the scope of this document.

Arguments may be generally applicable for SIDs of only specific SRv6 Endpoint Behaviors (e.g., End.DT2M); therefore, the AL MUST be set to 0 for SIDs where the Argument is not applicable. A receiver is unable to validate the applicability of arguments for SRv6 Endpoint Behaviors that are unknown to it and hence MUST ignore SRv6 SIDs with arguments (indicated by a non-zero AL) with unknown SRv6 Endpoint Behaviors. For SIDs corresponding to an SRv6 Endpoint Behavior that is known, a receiver MUST validate that the consistency of the AL with the specific SRv6 Endpoint Behavior definition.