边界网关协议 - 段路由的链路状态 (BGP-LS) 扩展

本文涉及的产品
全局流量管理 GTM,标准版 1个月
公共DNS(含HTTPDNS解析),每月1000万次HTTP解析
云解析 DNS,旗舰版 1个月
简介: 段路由 (Segment Routing,SR) 允许通过将路径编码为称为“段”的拓扑子路径序列来灵活定义端到端路径。这些段由路由协议通告,例如 IGP 拓扑中的链路状态路由协议(IS-IS、OSPFv2 和 OSPFv3)。

640.gif


RFC9085:Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Routing,August 2021


梗概


段路由 (Segment Routing,SR) 允许通过将路径编码为称为“段”的拓扑子路径序列来灵活定义端到端路径。这些段由路由协议通告,例如 IGP 拓扑中的链路状态路由协议(IS-IS、OSPFv2 和 OSPFv3)。


本文档定义了边界网关协议 - 链路状态 (Border Gateway Protocol - Link State,BGP-LS) 地址系列的扩展,以便通过 BGP 携带 SR 信息。


本备忘录的状态


这是一份 Internet 标准跟踪文档。


本文档是 Internet 工程任务组 (IETF) 的产品。它代表了 IETF 社区的共识。它已接受公众审查,并已获互联网工程指导小组 (IESG) 批准出版。有关 Internet 标准的更多信息,请参见 RFC 7841 的第 2 节。


有关本文档当前状态、任何勘误表以及如何提供反馈的信息,请访问 https://www.rfc-editor.org/info/rfc9085


版权声明


版权所有 (c) 2021 IETF Trust 和文件作者。版权所有。


本文件受 BCP 78 和 IETF 信托关于 IETF 文件的法律规定 (https://trustee.ietf.org/license-info) 的约束,该条款在本文件发布之日生效。请仔细阅读这些文件,因为它们描述了您对本文件的权利和限制。从本文档中提取的代码组件必须包含 Trust Legal Provisions 第 4.e 节中所述的简化 BSD 许可文本,并且按照简化 BSD 许可中的说明在不保证的情况下提供。


1、 简介


段路由 (SR) 允许通过组合称为“段”的子路径来灵活定义端到端路径。段可以表示任何指令:基于拓扑的或基于服务的。段可以具有对 SR 节点的局部语义或域内的全局语义。在 IGP 拓扑中,SR 路径被编码为一系列拓扑子路径,称为“IGP 段”。这些段由链路状态路由协议(IS-IS、OSPFv2 和 OSPFv3)通告。


[RFC8402-SR:Segment Routing Architecture] 定义了链路状态 IGP 段——前缀、节点、任播和邻接段。根据 IGP 拓扑的状态,默认情况下,前缀段表示前缀的 ECMP 感知最短路径。邻接段表示在 IGP 中两个节点之间的特定邻接上的跳跃。前缀段通常是多跳路径,而邻接段在大多数情况下是单跳路径。节点和任播段是具有特定特征的前缀段的变体。


在 IGP 域中启用 SR 时,段以段标识符 (Segment Identifiers,SID) 的形式发布。IGP 链路状态路由协议已扩展为通告 SID 和其他与 SR 相关的信息。IGP 扩展描述为:IS-IS [RFC8667]、OSPFv2 [RFC8665] 和 OSPFv3 [RFC8666]。使用这些扩展,可以在 IGP 域中启用 SR。


SR 允许通告单跳或多跳路径。SR 的 IGP 扩展的泛洪范围是 IGP 区域范围的。因此,链路状态数据库(Link-State Database,LSDB)流量工程数据库(Traffic Engineering Database,TED)的内容具有IGP区域的范围;因此,仅使用 IGP 来构建跨越多个 IGP 区域或自治系统 (Autonomous System,AS) 边界的段是不够的。


为了满足需要跨 IGP 区域甚至跨 AS 的拓扑可见性的应用程序的需求,已定义 BGP-LS 地址族/子地址族以允许 BGP 携带链路状态信息。BGP-LS 的 BGP 网络层可达性信息 (Network Layer Reachability Information,NLRI) 编码格式和称为“BGP-LS 属性”的新 BGP 路径属性在 [RFC7752] 中定义。每个链路状态对象的标识键,即节点、链路或前缀,编码在 NLRI 中,对象的属性编码在 BGP-LS 属性中。


640.png

图 1:链路状态信息收集


图 1 表示一个典型的部署场景。在每个 IGP 区域中,一个或多个节点都配置了 BGP-LS。这些 BGP 扬声器通过连接到一个或多个路由反射器形成内部 BGP (Internal BGP,IBGP) 网格。这样,所有 BGP 发言者(特别是路由反射器)从所有 IGP 区域(以及来自外部 BGP (External BGP,EBGP) 对等方的其他 AS)获取链路状态信息。如 [RFC7752] 中所述,外部组件连接到路由反射器以获取此信息(可能由有关向外部组件发布或不发布哪些信息的策略调节)。


本文档描述了对 BGP-LS 的扩展以通告 SR 信息。外部组件(例如,控制器)可以跨 SR 域收集 SR 信息(如 [RFC8402] 中所述)并构建需要应用于传入数据包的端到端路径(及其关联的 SID)以实现所需的端到端转发。SR 在由单个 AS 或由同一管理实体管理的多个 AS 组成的受信任域内运行,例如,在单个提供商网络内。


1.1、 需求语言


关键词“必须”、“不得”、“要求”、“应”、“不得”、“应该”、“不应”、“推荐”、“不推荐”、“可以”和“可选”当且仅当它们以全部大写字母出现时,本文档中的 " 将按照 BCP 14 [RFC2119] [RFC8174] 中的描述进行解释,如此处所示。


2、 用于段路由的 BGP-LS 扩展


本文档定义了 BGP-LS 的 SR 扩展,并指定了用于在 BGP-LS 属性中通告 SR 信息的 TLV 和子 TLV。2.4 和 2.5 节列出了 IS-IS、OSPFv2 和 OSPFv3 协议中的等效 TLV 和子 TLV。


BGP-LS [RFC7752] 定义了 BGP-LS NLRI,它可以是节点 NLRI、链路 NLRI 或前缀 NLRI,它定义了将链路状态信息映射到 BGP-LS 属性中的 BGP-LS NLRI 的 TLV .本文档添加了额外的 BGP-LS 属性 TLV,以便对 SR 信息进行编码。它不会对 BGP-LS NLRI 的编码进行任何更改。


2.1、 节点属性 TLV


定义了以下节点属性 TLV:


640.png

表 1:节点属性 TLV


这些 TLV 应该只添加到与节点 NLRI 关联的 BGP-LS 属性中,该节点描述了 IGP 节点,该 IGP 节点发起了下面描述的相应 IGP TLV/子 TLV。


2.1.1、 SID/标签 TLV


SID/标签 TLV 被 SR 能力(第 2.1.2 节)和段路由本地块(SRLB)(第 2.1.4 节)TLV 用作子 TLV。此信息来自协议特定的通告。


* IS-IS,由 [RFC8667] 的第 2.3 节中的 SID/标签子 TLV 定义。


* OSPFv2/OSPFv3,由 [RFC8665] 第 2.1 节和 [RFC8666] 第 3.1 节中的 SID/Label Sub-TLV 定义。


TLV 具有以下格式:


640.png

图 2:SID/标签 TLV 格式


在这里:


Type:类型,1161


Length:长度,可变。3 或 4 个八位字节,具体取决于值是编码为标签还是索引/SID。


SID/Label:如果长度设置为3,那么最右边20位代表一个标签(TLV总大小为7),最左边4位设置为0。如果长度设置为4,那么值表示一个 32 位的 SID(总 TLV 大小为 8)。


2.1.2、 SR 能力 TLV


SR Capabilities TLV 用于通告节点的 SR 能力,包括其段路由全局库 (Segment Routing Global Base,SRGB) 范围。对于 IS-IS,这些能力还包括对 SR-MPLS 转发平面的 IPv4 和 IPv6 支持。此信息来自协议特定的通告。


* IS-IS,由 [RFC8667] 第 3.1 节中的 SR-Capabilities Sub-TLV 定义。


* OSPFv2/OSPFv3,由 [RFC8665] 第 3.2 节中的 SID/标签范围 TLV 定义。OSPFv3 利用为 OSPFv2 定义的相同 TLV。


SR Capabilities TLV 具有以下格式:


640.png

图 3:SR 功能 TLV 格式


在这里:


Type:类型,1034


Length:长度,可变。最小长度为 12 个八位字节。


Flags:标志,1 个八位字节的标志,如 [RFC8667] 的第 3.1 节中为 IS-IS 定义的。目前没有为 OSPFv2 和 OSPFv3 定义标志,必须设置为 0 并在收到时忽略。


Reserved:保留,1 个八位字节,必须设置为 0 并在接收时忽略。


一个或多个条目,每个条目的格式如下:


Range Size:范围大小,3 个八位字节,非零值指示范围内的标签数量。


SID/Label TLV:(定义见第 2.1.1 节)用作子 TLV,对范围内的第一个标签进行编码。由于 SID/Label TLV 用于指示 SRGB 范围的第一个标签,因此在 SR Capabilities TLV 下只有标签编码有效。


2.1.3、 SR 算法 TLV


SR-Algorithm TLV 用于通告节点支持的 SR 算法。此信息来自协议特定的通告。


* IS-IS,由 [RFC8667] 第 3.2 节中的 SR-Algorithm Sub-TLV 定义。


* OSPFv2/OSPFv3,由 [RFC8665] 第 3.1 节中的 SR 算法 TLV 定义。OSPFv3 利用为 OSPFv2 定义的相同 TLV。


SR 算法 TLV 具有以下格式:


640.png

图 4:SR 算法 TLV 格式


在这里:


Type:类型,1035


Length:长度,可变。最小长度为 1 个八位字节,最大长度为 256。


Algorithm:算法,一个或多个字段,每个字段为 1 个八位字节,用于标识算法。


2.1.4、 SR 本地块 TLV


SRLB TLV 包含节点为本地 SID 保留的标签范围。本地 SID 用于,例如,在 IGP(IS-IS,OSPF)中用于邻接 SID,也可以由 IGP 协议以外的组件分配。例如,应用程序或控制器可以指示节点分配特定的本地 SID。因此,为了让此类应用程序或控制器知道可用的本地 SID 的范围,节点需要通告其 SRLB。


此信息来自协议特定的通告。


* IS-IS,由 [RFC8667] 第 3.3 节中的 SRLB Sub-TLV 定义。


* OSPFv2/OSPFv3,由 [RFC8665] 第 3.3 节中的 SR 本地块 TLV 定义。OSPFv3 利用为 OSPFv2 定义的相同 TLV。


SRLB TLV 具有以下格式:


640.png

图 5:SRLB TLV 格式


在这里:


Type:类型,1036


Length:长度,可变。最小长度为 12 个八位字节。


Flags:标志,1 个八位字节的标志。这些标志在 [RFC8667] 的第 3.3 节中为 IS-IS 定义。目前没有为 OSPFv2 和 OSPFv3 定义标志,必须设置为 0 并在收到时忽略。


Reserved:保留,1 个八位字节,必须设置为 0 并在接收时忽略。


对应于子范围的一个或多个条目,每个条目具有以下格式:


Range Size:范围大小,3 个八位字节的值,指示范围内的标签数量。


SID/Label TLV:(定义见第 2.1.1 节)用作子 TLV,对子范围中的第一个标签进行编码。由于 SID/Label TLV 用于指示 SRLB 子范围的第一个标签,因此在 SR Local Block TLV 下只有标签编码有效。


2.1.5、 SRMS 优先级 TLV


段路由映射服务器 (Segment Routing Mapping Server,SRMS) 优先级 TLV 用于将优先级与来自特定源的 SRMS 通告相关联。[RFC8661] 指定 SRMS 功能以及通告 SRMS 前缀到 SID 映射范围的节点的 SRMS 优先级。


此信息来自协议特定的通告。


* IS-IS,由 [RFC8667] 的第 3.4 节中的 SRMS Preference Sub-TLV 定义。


* OSPFv2/OSPFv3,由 [RFC8665] 第 3.4 节中的 SRMS Preference TLV 定义。OSPFv3 利用为 OSPFv2 定义的相同 TLV。


SRMS 优先级 TLV 具有以下格式:


640.png

图 6:SRMS 优先级 TLV 格式


在这里:


Type:类型,1037


Length:长度,1 个八位字节


Preference:优先级,1 个八位字节,携带无符号 8 位 SRMS 优先级。


2.2、 链路属性 TLV


定义了以下链路属性 TLV:


640.png

表 2:链路属性 TLV


这些 TLV 应该只添加到与 Link NLRI 关联的 BGP-LS 属性,该属性描述了 IGP 节点的链路,该 IGP 节点发起了下面描述的相应 IGP TLV/sub-TLV。


2.2.1、 邻接 SID TLV


邻接 SID TLV 用于通告与邻接 SID 相关的信息。该信息来源于 IS-IS 的 Adj-SID Sub-TLV([RFC8667] 的第 2.2.1 节)、OSPFv2([RFC8665] 的第 6.1 节)和 OSPFv3([RFC8666] 的第 7.1 节)。


邻接 SID TLV 具有以下格式:


640.png

图 7:邻接 SID TLV 格式


在这里:


Type:类型,1099


Length:长度,可变。7 或 8 个八位字节,具体取决于 SID 的标签或索引编码。


Flags:标志,应设置为 1 个八位字节的值:


* [RFC8667] 第 2.2.1 节中定义的 IS-IS Adj-SID 标志。


* [RFC8665] 第 6.1 节中定义的 OSPFv2 Adj-SID 标志。


* [RFC8666] 第 7.1 节中定义的 OSPFv3 Adj-SID 标志。


Weight:权重,1 个八位字节承载用于负载平衡目的的权重。[RFC8402] 的第 3.4 节描述了权重的使用。


Reserved:保留,必须设置为 0 并在接收时忽略的 2 个八位字节。


SID/索引/标签:


IS-IS:[RFC8667] 第 2.2.1 节中定义的标签或索引值。

OSPFv2:[RFC8665] 第 6.1 节中定义的标签或索引值。

OSPFv3:[RFC8666] 第 7.1 节中定义的标签或索引值。


该 TLV 的标志和作为扩展的 SID/索引/标签字段根据各自的底层 IS-IS、OSPFv2 或 OSPFv3 协议进行解释。BGP-LS Link NLRI 的 Protocol-ID 用于确定解析这些字段的底层协议规范。


2.2.2、 LAN 邻接 SID TLV


对于 LAN,节点通常只宣布与 IS-IS 伪节点(或等效的 OSPF 指定和备份指定路由器)的邻接关系。LAN 邻接 SID TLV 允许节点在 BGP-LS 链路 NLRI 的单个实例中向连接到 LAN 的所有其他节点宣布邻接关系。如果没有此 TLV,则需要为每个附加邻接创建相应的 BGP-LS 链路 NLRI,以便为这些邻接邻接通告 SR TLV。


该信息来源于 IS-IS 的 LAN-Adj-SID Sub-TLV([RFC8667] 的第 2.2.2 节)、OSPFv2 的 LAN Adj-SID Sub-TLV([RFC8665] 的第 6.2 节)和OSPFv3 的 LAN Adj-SID Sub-TLV([RFC8666] 的第 7.2 节)。


LAN 邻接 SID TLV 具有以下格式:


640.png

图 8:LAN 邻接 SID TLV 格式


在这里:


Type:类型,1100


Length:长度,可变。对于 IS-IS,它将是 13 或 14 个八位字节,具体取决于 SID 的标签或索引编码。对于 OSPF,它将是 11 或 12 个八位字节,具体取决于 SID 的标签或索引编码。


Flags:标志,应设置为 1 个八位字节的值:


* [RFC8667] 第 2.2.2 节中定义的 IS-IS LAN Adj-SID 标志。


* [RFC8665] 第 6.2 节中定义的 OSPFv2 LAN Adj-SID 标志。


* [RFC8666] 第 7.2 节中定义的 OSPFv3 LAN Adj-SID 标志。


Weight:权重,1 个八位字节承载用于负载平衡目的的权重。[RFC8402] 的第 3.4 节描述了权重的使用。


Reserved:保留,必须设置为 0 并在接收时忽略的 2 个八位字节。


Neighbor ID:邻居 ID,IS-IS 的 6 个八位字节用于系统 ID,OSPF 的 4 个八位字节用于邻居的 OSPF Router-ID。


SID/索引/标签:


IS-IS:[RFC8667] 第 2.2.2 节中定义的标签或索引值。

OSPFv2:[RFC8665] 第 6.2 节中定义的标签或索引值。

OSPFv3:[RFC8666] 第 7.2 节中定义的标签或索引值。


该 TLV 的邻居 ID、标志以及作为扩展的 SID/索引/标签字段根据各自的底层 IS-IS、OSPFv2 或 OSPFv3 协议进行解释。BGP-LS Link NLRI 的 Protocol-ID 用于确定解析这些字段的底层协议规范。


2.2.3、 L2 捆绑成员属性 TLV


L2 Bundle Member Attributes TLV 标识 L2 Bundle Member 链路,该链路又与父 L3 链路相关联。L3 链路由 [RFC7752] 中定义的 Link NLRI 描述,L2 Bundle Member Attributes TLV 与 Link NLRI 相关联。TLV 可以包括描述与捆绑成员相关的属性的子 TLV。标识的捆绑成员表示从始发路由器到父 L3 链路中指定的邻居的单向路径。多个 L2 捆绑成员属性 TLV 可以与一个链路 NLRI 相关联。


此信息源自 IS-IS 的 L2 捆绑成员属性 TLV([RFC8668] 的第 2 节)。尚未为 OSPF 指定等效功能。


L2 Bundle Member Attributes TLV 具有以下格式:


640.png

图 9:L2 捆绑成员属性 TLV 格式


在这里:


Type:类型,1172


Length:长度,可变。


L2 Bundle Member Descriptor:4 字节字段,携带 [RFC4202] 中定义的链路本地标识符。


L2 Bundle Member 链路的链路属性作为 L2 Bundle Member Attributes TLV 的子 TLV 进行通告。子 TLV 与下表中标识的现有 BGP-LS TLV 相同。


640.png

表 3:BGP-LS 属性 TLV 也用作 L2 Bundle Member Attributes TLV 的子 TLV


2.3、 前缀属性 TLV


定义了以下前缀属性 TLV:


640.png

表 4:前缀属性 TLV


这些 TLV 应该只添加到与前缀 NLRI 关联的 BGP-LS 属性,该前缀描述了 IGP 节点的前缀,该 IGP 节点发起了下面描述的相应 IGP TLV/子 TLV。


2.3.1、 前缀 SID TLV


Prefix-SID TLV 用于通告与 Prefix-SID 相关的信息。该信息来源于 IS-IS 的 Prefix-SID Sub-TLV([RFC8667] 第 2.1 节)、OSPFv2 的 Prefix-SID Sub-TLV([RFC8665] 第 5 节)和 Prefix-SID Sub-TLV。OSPFv3 的 TLV([RFC8666] 第 6 节)。


Prefix-SID TLV 具有以下格式:


640.png

图 10:前缀 SID TLV 格式


在这里:


Type:类型,1158


Length:长度,可变。7 或 8 个八位字节,具体取决于 SID 的标签或索引编码。


Flags:标志,应设置为 1 个八位字节的值:


* [RFC8667] 第 2.1.1 节中定义的 IS-IS Prefix-SID 标志。


* [RFC8665] 第 5 节中定义的 OSPFv2 Prefix-SID 标志。


* [RFC8665] 第 6 节中定义的 OSPFv3 Prefix-SID 标志。


Algorithm:算法,1 字节值标识算法。该算法的语义在 [RFC8402] 的第 3.1.1 节中描述。


Reserved:保留,必须设置为 0 并在接收时忽略的 2 个八位字节。


SID/索引/标签:


IS-IS:[RFC8667] 第 2.1 节中定义的标签或索引值。

OSPFv2:[RFC8665] 第 5 节中定义的标签或索引值。

OSPFv3:[RFC8666] 第 6 节中定义的标签或索引值。


该 TLV 的标志和作为扩展的 SID/索引/标签字段根据各自的底层 IS-IS、OSPFv2 或 OSPFv3 协议进行解释。BGP-LS Prefix NLRI 的 Protocol-ID 用于确定解析这些字段的底层协议规范。


2.3.2、 前缀属性标志 TLV


Prefix Attribute Flags TLV 携带 IPv4/IPv6 前缀属性标志信息。这些标志在 [RFC7684] 的第 2.1 节中为 OSPFv2、[RFC5340] 的附录 A.4.1.1 中的 OSPFv3 和 [RFC7794] 的第 2.1 节中的 IS-IS 定义。


前缀属性标志 TLV 具有以下格式:


640.png

图 11:前缀属性标志 TLV 格式


在这里:


Type:类型,1170


Length:长度,可变。


Flags:可变长度的Flag字段(根据Length字段)。标志是特定于路由协议的,设置如下:


* IS-IS 标志对应于 [RFC7794] 第 2.1 节中定义的 IPv4/IPv6 扩展可达性属性标志。在 X-flag 与 IPv6 前缀可达性相关联的情况下,该设置对应于 IS-IS TLV 236 [RFC5308] 和 237 [RFC5120] 的固定格式中的 X-flag 设置。


* OSPFv2 标志对应于 [RFC7684] 第 2.1 节中定义的 OSPFv2 扩展前缀 TLV 的标志字段。


* OSPFv3 标志映射到 [RFC5340] 的附录 A.4.1.1 中定义并在 [RFC8362] 的第 3.1 节中扩展的前缀选项字段。


此 TLV 的标志字段根据各自的底层 IS-IS、OSPFv2 或 OSPFv3 协议进行解释。BGP-LS Prefix NLRI 的 Protocol-ID 用于确定解析该字段的底层协议规范。


2.3.3、 源路由器标识符 TLV


源路由器标识符 TLV 包含前缀发起者的 IPv4 或 IPv6 路由器标识符。对于 IS-IS 协议,这是从 [RFC7794] 的第 2.2 节中定义的 IPv4/IPv6 源路由器 ID 子 TLV 派生的。对于 OSPF 协议,这是从 [RFC9084] 的第 2.2 节中定义的前缀源路由器地址子 TLV 派生的。


源路由器标识符 TLV 具有以下格式:


640.png

图 12:源路由器标识符 TLV 格式


在这里:


Type:类型,1171


Length:长度,可变。IPv4 或 IPv6 前缀分别为 4 或 16 个八位字节。


Router-ID:IS-IS 的 IPv4 或 IPv6 Router-ID,OSPF 的 IPv4 或 IPv6 Router Address。


2.3.4、 源 OSPF 路由器 ID TLV


Source OSPF Router-ID TLV 仅适用于 OSPF 协议,包含前缀发起者的 OSPF Router-ID。它源自 [RFC9084] 的第 2.1 节中定义的前缀源 OSPF 路由器 ID 子 TLV。


源 OSPF 路由器 ID TLV 具有以下格式:


640.png

图 13:源 OSPF 路由器 ID TLV 格式


在这里:


Type:类型,1174


Length:长度,4 个八位字节


OSPF Router-ID:产生前缀的节点的 OSPF Router-ID。


2.3.5、 范围 TLV


Range TLV 用于宣传一系列前缀到 SID 的映射,作为 SRMS 功能 [RFC8661] 的一部分,如相应的基础 IGP SR 扩展中所定义:[RFC8665] 第 4 节,[RFC8666] 第 5 节 ] 和 [RFC8667] 的第 2.4 节。Range TLV 中通告的信息在 IS-IS 的情况下来自 SID/标签绑定 TLV,在 OSPFv2/OSPFv3 的情况下来自 OSPFv2/OSPFv3 扩展前缀范围 TLV。


只有当还有一个 IGP 度量 TLV (TLV 1095) 关联时,前缀 NLRI 才被认为是一个正常的路由前缀(即前缀可达性)。否则,它仅被视为前缀到 SID 映射通告范围内的第一个前缀。


Range TLV 的格式如下:


640.png

图 14:范围 TLV 格式


在这里:


Type:类型,1159


Length:长度,可变。11 或 12 个八位字节,具体取决于 SID 的标签或索引编码。


Flags:标志,应设置为 1 个八位字节的值:


* [RFC8667] 第 2.4.1 节中定义的 IS-IS SID/标签绑定 TLV 标志。


* OSPFv2 OSPF 扩展前缀范围 TLV 标志如 [RFC8665] 第 4 节中定义。


* [RFC8666] 第 5 节中定义的 OSPFv3 扩展前缀范围 TLV 标志。


Reserved:保留,1 个八位字节,必须设置为 0 并在接收时忽略。


Range Size:范围大小,2 个八位字节,携带通告覆盖的前缀数量。


此 TLV 的标志字段根据各自的底层 IS-IS、OSPFv2 或 OSPFv3 协议进行解释。BGP-LS Prefix NLRI 的 Protocol-ID 用于确定解析该字段的底层协议规范。


前缀到 SID 的映射使用子 TLV 进行通告,如下所示:


IS-IS:

SID/标签范围 TLV
前缀 SID 子 TLV


OSPFv2/OSPFv3:

OSPFv2/OSPFv3 扩展前缀范围 TLV
前缀 SID 子 TLV


BGP-LS:

范围 TLV
Prefix-SID TLV(在此上下文中用作子 TLV)


BGP-LS Prefix-SID TLV(在此上下文中用作子 TLV)的前缀到 SID 映射信息按照第 2.3.1 节中的描述进行编码。


2.4、 等效 IS-IS 段路由 TLV/子 TLV


本节说明映射到本文档中定义的 IS-IS 段路由扩展 TLV 和子 TLV。


对于每个 BGP-LS TLV,下表说明了它在 IS-IS 中的等效性。


640.png

表 5:IS-IS 段路由扩展 TLV/子 TLV


2.5、 等效 OSPFv2/OSPFv3 段路由 TLV/子 TLV


本节说明 OSPFv2 和 OSPFv3 段路由扩展 TLV 和子 TLV 映射到本文档中定义的 TLV。


对于每个 BGP-LS TLV,下表说明了它在 OSPFv2 和 OSPFv3 中的等效性。


640.png

表 6:OSPFv2 段路由扩展 TLV/子 TLV


640.png

表 7:OSPFv3 段路由扩展 TLV/子 TLV


3、 IANA 考虑事项


IANA 已根据表 8 在“边界网关协议 - 链路状态 (BGP-LS) 参数”注册表下的“BGP-LS 节点描述符、链路描述符、前缀描述符和属性 TLV”注册表中注册了以下代码点。注册表中定义的“IS-IS TLV/Sub-TLV”列不需要任何值,应留空。


3.1、 TLV/Sub-TLV 代码点汇总


本节包含本文档中定义的所有 TLV/子 TLV 的全局表。


640.png

表 8:TLV/Sub-TLV 代码点汇总


4、 可管理性考虑


本节的结构按照 [RFC5706] 中的建议进行。


本文档中引入的新协议扩展扩充了通过 [RFC7752] 分发的现有 IGP 拓扑信息。本文档中定义的程序和协议扩展不影响 BGP 协议的操作和管理,除非在 [RFC7752] 的可管理性考虑部分中讨论。具体来说,[RFC7752] 的故障管理部分中用于语法检查的格式错误的属性测试现在包含本文档中定义的新 BGP-LS 属性 TLV。本文档中指定的 TLV 的语义或内容检查以及它们与 BGP-LS NLRI 类型或其 BGP-LS 属性的关联留给 BGP-LS 信息的消费者(例如,应用程序或控制器),而不是BGP协议。


BGP-LS 信息的消费者通过 BGP-LS 会话检索此信息(请参阅 [RFC7752] 的第 1 节和第 2 节)。消费者对语义或内容错误的处理将取决于其应用程序使用的性质,因此超出了本文档的范围。


本文档仅介绍了新的属性 TLV,其中的任何语法错误都会导致 BGP-LS 属性被丢弃并显示错误日志。本规范在 BGP-LS 中引入的 SR 信息可以被 BGP-LS 消费者应用程序使用,例如 SR 路径计算引擎 (Path Computation Engine,PCE),以了解拓扑中节点的 SR 能力以及 SR 段到这些节点的映射。这可以使 SR PCE 能够针对流量工程用例执行基于 SR 的路径计算,并将流量引导到与基于 IGP 的底层分布式最佳路径计算不同的路径上。SR 信息的编码或解码错误可能会导致此类信息对 SR PCE 不可用或向其提供不正确的信息。这可能导致 SR PCE 无法执行所需的基于 SR 的优化功能或以意外或不一致的方式执行它。SR PCE 等应用程序对此类错误的处理可能是特定于实现的,超出了本文档的范围。


除了在 [RFC7752] 中讨论的内容外,本文档中指定的扩展不会在 BGP 或 BGP-LS 中引入任何新的配置或监控方面。[RFC9020]、[ISIS-SR-YANG] 和 [OSPF-SR-YANG] 涵盖了底层 SR 功能的可管理性方面。


5、 安全考虑


本文档中引入的新协议扩展扩充了通过 [RFC7752] 分发的现有 IGP 拓扑信息。本文档中定义的 SR 链路属性信息的通告存在与 [RFC7752] 中描述的现有链路属性信息集相关的类似风险。[RFC7752] 的安全考虑部分也适用于这些扩展。本文档中定义的过程和新 TLV 本身不影响 [RFC7752] 中讨论的 BGP-LS 安全模型。


本文档中介绍的 TLV 用于传播 IGP 定义的信息(参见 [RFC8665]、[RFC8666] 和 [RFC8667])。这些 TLV 代表与 IGP 节点、链路和前缀关联的 SR 信息。假设生成这些 TLV 的 IGP 实例支持所有必需的安全和认证机制(如 [RFC8665]、[RFC8666] 和 [RFC8667] 中所述),以防止在将 TLV 传播到 BGP-LS 时出现任何安全问题。


BGP-LS SR 扩展支持 SR 域内的流量工程用例。SR 在可信域 [RFC8402] 内运行,其安全考虑也适用于携带 SR 信息时的 BGP-LS 会话。使用通过 BGP-LS 通告的 SID 的 SR 流量工程策略预计将完全在此受信任的 SR 域内使用(例如,在单个提供商网络内的多个 AS/域之间)。因此,有必要采取预防措施,以确保通过 BGP-LS 会话通告的链路状态信息(包括 SR 信息)以安全的方式在此受信任的 SR 域内仅限于消费者。可以为 SR 域外的路由器设置除链路状态以外的地址族的 BGP 对等会话。建议隔离 BGP-LS 对等会话,以确保 BGP-LS 拓扑信息(包括新添加的 SR 信息)不会发布到 SR 域之外的外部 BGP 对等会话。


6、 参考文献


6.1、 规范性参考


[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>.
[RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4202, DOI 10.17487/RFC4202, October 2005, <https://www.rfc-editor.org/info/rfc4202>.
[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>.
[RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, DOI 10.17487/RFC5308, October 2008, <https://www.rfc-editor.org/info/rfc5308>.
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, <https://www.rfc-editor.org/info/rfc5340>.
[RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 2015, <https://www.rfc-editor.org/info/rfc7684>.
[RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and S. Ray, "North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP", RFC 7752, DOI 10.17487/RFC7752, March 2016, <https://www.rfc-editor.org/info/rfc7752>.
[RFC7794] Ginsberg, L., Ed., Decraene, B., Previdi, S., Xu, X., and U. Chunduri, "IS-IS Prefix Attributes for Extended IPv4 and IPv6 Reachability", RFC 7794, DOI 10.17487/RFC7794, March 2016, <https://www.rfc-editor.org/info/rfc7794>.
[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>.
[RFC8362] Lindem, A., Roy, A., Goethals, D., Reddy Vallem, V., and F. Baker, "OSPFv3 Link State Advertisement (LSA) Extensibility", RFC 8362, DOI 10.17487/RFC8362, April 2018, <https://www.rfc-editor.org/info/rfc8362>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[RFC8571] Ginsberg, L., Ed., Previdi, S., Wu, Q., Tantsura, J., and C. Filsfils, "BGP - Link State (BGP-LS) Advertisement of IGP Traffic Engineering Performance Metric Extensions", RFC 8571, DOI 10.17487/RFC8571, March 2019, <https://www.rfc-editor.org/info/rfc8571>.
[RFC8665] Psenak, P., Ed., Previdi, S., Ed., Filsfils, C., Gredler, H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF Extensions for Segment Routing", RFC 8665, DOI 10.17487/RFC8665, December 2019, <https://www.rfc-editor.org/info/rfc8665>.
[RFC8666] Psenak, P., Ed. and S. Previdi, Ed., "OSPFv3 Extensions for Segment Routing", RFC 8666, DOI 10.17487/RFC8666, December 2019, <https://www.rfc-editor.org/info/rfc8666>.
[RFC8667] Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C., Bashandy, A., Gredler, H., and B. Decraene, "IS-IS Extensions for Segment Routing", RFC 8667, DOI 10.17487/RFC8667, December 2019, <https://www.rfc-editor.org/info/rfc8667>.
[RFC8668] Ginsberg, L., Ed., Bashandy, A., Filsfils, C., Nanduri, M., and E. Aries, "Advertising Layer 2 Bundle Member Link Attributes in IS-IS", RFC 8668, DOI 10.17487/RFC8668, December 2019, <https://www.rfc-editor.org/info/rfc8668>.
[RFC9084] Wang, A., Lindem, A., Dong, J., Psenak, P., and K. Talaulikar, Ed., "OSPF Prefix Originator Extensions", RFC 9084, DOI 10.17487/RFC9084, August 2021, <https://www.rfc-editor.org/info/rfc9084>.


6.2、 参考资料


[ISIS-SR-YANG] Litkowski, S., Qu, Y., Sarkar, P., Chen, I., and J.Tantsura, "YANG Data Model for IS-IS Segment Routing", Work in Progress, Internet-Draft, draft-ietf-isis-sr-yang-10, 21 February 2021, <https://datatracker.ietf.org/doc/html/draft-ietf-isis-sr-yang-10>.
[OSPF-SR-YANG] Yeung, D., Qu, Y., Zhang, J., Chen, I., and A. Lindem, "YANG Data Model for OSPF SR (Segment Routing) Protocol", Work in Progress, Internet-Draft, draft-ietf-ospf-sr-yang-15, 2 July 2021, <https://datatracker.ietf.org/doc/html/draft-ietf-ospf-sr-yang-15>.
[RFC5706] Harrington, D., "Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions", RFC 5706, DOI 10.17487/RFC5706, November 2009, <https://www.rfc-editor.org/info/rfc5706>.
[RFC8661] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., Decraene, B., and S. Litkowski, "Segment Routing MPLS Interworking with LDP", RFC 8661, DOI 10.17487/RFC8661, December 2019, <https://www.rfc-editor.org/info/rfc8661>.
[RFC9020] Litkowski, S., Qu, Y., Lindem, A., Sarkar, P., and J. Tantsura, "YANG Data Model for Segment Routing", RFC 9020, DOI 10.17487/RFC9020, May 2021, <https://www.rfc-editor.org/info/rfc9020>.


致谢


作者要感谢 Jeffrey Haas、Aijun Wang、Robert Raszuk 和 Susan Hares 对本文档的审阅和评论。作者还要感谢 Alvaro Retana 的广泛审查和评论,这有助于纠正问题和改进文档。

相关文章
|
4月前
|
运维 Kubernetes 安全
利用服务网格实现全链路mTLS(一):在入口网关上提供mTLS服务
阿里云服务网格(Service Mesh,简称ASM)提供了一个全托管式的服务网格平台,兼容Istio开源服务网格,用于简化服务治理,包括流量管理和拆分、安全认证及网格可观测性,有效减轻开发运维负担。ASM支持通过mTLS提供服务,要求客户端提供证书以增强安全性。本文介绍如何在ASM入口网关上配置mTLS服务并通过授权策略实现特定用户的访问限制。首先需部署ASM实例和ACK集群,并开启sidecar自动注入。接着,在集群中部署入口网关和httpbin应用,并生成mTLS通信所需的根证书、服务器证书及客户端证书。最后,配置网关上的mTLS监听并设置授权策略,以限制特定客户端对特定路径的访问。
147 2
|
15天前
|
数据采集 传感器 监控
多协议网关BL110钡铼6路RS485转MQTT协议云网关
BL110钡铼6路RS485转MQTT协议云网关是一款高性能、易配置的工业级设备,适用于各种需要远程监控和数据采集的物联网应用场景。通过将传统RS485设备的数据转换为MQTT协议并上传至云平台,实现了设备的远程管理和智能控制,极大地提升了系统的管理效率和响应速度。
24 2
|
2月前
|
前端开发 Java API
vertx学习总结5之回调函数及其限制,如网关/边缘服务示例所示未来和承诺——链接异步操作的简单模型响应式扩展——一个更强大的模型,特别适合组合异步事件流Kotlin协程
本文是Vert.x学习系列的第五部分,讨论了回调函数的限制、Future和Promise在异步操作中的应用、响应式扩展以及Kotlin协程,并通过示例代码展示了如何在Vert.x中使用这些异步编程模式。
51 5
vertx学习总结5之回调函数及其限制,如网关/边缘服务示例所示未来和承诺——链接异步操作的简单模型响应式扩展——一个更强大的模型,特别适合组合异步事件流Kotlin协程
|
2月前
|
网络协议 网络虚拟化 网络架构
【网络实验】/主机/路由器/交换机/网关/路由协议/RIP+OSPF/DHCP(上)
【网络实验】/主机/路由器/交换机/网关/路由协议/RIP+OSPF/DHCP(上)
81 1
|
2月前
|
网络协议 数据安全/隐私保护 网络虚拟化
【网络实验】/主机/路由器/交换机/网关/路由协议/RIP+OSPF/DHCP(下)
【网络实验】/主机/路由器/交换机/网关/路由协议/RIP+OSPF/DHCP(下)
68 0
|
4月前
|
Kubernetes 安全 Cloud Native
解锁安全新纪元:利用服务网格Istio,打造全链路mTLS加密隧道,从入口网关到出口网关,守护数据安全的每一步
【8月更文挑战第2天】随着云原生技术的发展,服务网格(Service Mesh)如Istio已成为微服务架构的核心,通过双向TLS(mTLS)确保通信安全。首先,在Kubernetes部署Istio以管理服务通信。接着,配置入口网关实现所有入向流量的加密处理,防止数据泄露。最后,通过配置Sidecar代理如Envoy,确保服务网格安全访问外部mTLS服务,从而构建起全链路的数据安全防护。
88 11
|
4月前
|
Kubernetes 安全 数据安全/隐私保护
利用服务网格实现全链路mTLS(二):通过出口网关访问外部mTLS服务
阿里云服务网格(Service Mesh,简称ASM)提供了一个全托管式的服务网格平台,兼容Istio开源服务网格,简化服务治理,包括流量管理、服务间通信安全及网格可观测性。ASM出口网关统一管理网格内的出口流量,实现全链路加密通信与精细访问控制。本文介绍如何配置ASM出口网关以管理出口流量并发起mTLS通信,涉及配置ServiceEntry、创建出口网关、设置虚拟服务及目标规则等步骤,最终实现安全可控的mTLS服务访问。
169 3
|
4月前
|
负载均衡 网络架构
|
7月前
|
负载均衡 网络协议 安全
【计网·湖科大·思科】实验七 路由信息协议RIP、开放最短路径优先协议OSPF、边界网关协议BGP
【计网·湖科大·思科】实验七 路由信息协议RIP、开放最短路径优先协议OSPF、边界网关协议BGP
293 2
|
7月前
|
网络协议 算法 安全
【专栏】RIP是一种古老的内部网关协议,使用距离矢量算法,基于跳数更新路由表,最古老的距离矢量协议
【4月更文挑战第28天】RIP是一种古老的内部网关协议,使用距离矢量算法,基于跳数更新路由表。其工作原理包括周期性更新、度量标准、路由表更新和防止计数到无穷问题的技术。RIP简单易用,适合小规模网络,但在大规模网络中效率低且有限制。随着OSPF和EIGRP等协议的发展,RIP在大型网络中的应用减少,但在中小型网络和遗留系统中仍有其地位。RIPv2的改进提高了安全性与灵活性。尽管逐渐被替代,RIP在理解路由协议基本概念和历史中仍具价值。
211 1