Internet Engineering Task Force (IETF) N. Bahadur, Ed.
Request for Comments: 8430 Uber
Category: Informational S. Kini, Ed.
ISSN: 2070-1721
J. Medved
Cisco
September 2018
Internet Engineering Task Force (IETF) N. Bahadur, Ed.
Request for Comments: 8430 Uber
Category: Informational S. Kini, Ed.
ISSN: 2070-1721
J. Medved
Cisco
September 2018
RIB Information Model
肋骨信息模型
Abstract
摘要
Routing and routing functions in enterprise and carrier networks are typically performed by network devices (routers and switches) using a Routing Information Base (RIB). Protocols and configurations push data into the RIB, and the RIB manager installs state into the hardware for packet forwarding. This document specifies an information model for the RIB to enable defining a standardized data model. The IETF's I2RS WG used this document to design the I2RS RIB data model. This document is being published to record the higher-level information model decisions for RIBs so that other developers of RIBs may benefit from the design concepts.
企业和运营商网络中的路由和路由功能通常由网络设备（路由器和交换机）使用路由信息库（RIB）执行。协议和配置将数据推送到RIB中，RIB管理器将状态安装到硬件中以进行数据包转发。本文件规定了肋骨的信息模型，以便能够定义标准化数据模型。IETF的I2RS工作组使用本文件设计I2RS肋骨数据模型。本文档的发布是为了记录肋骨的更高级别信息模型决策，以便肋骨的其他开发人员可以从设计概念中获益。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
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). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8430.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8430.
Copyright Notice
版权公告
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2018 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Conventions Used in This Document . . . . . . . . . . . . 6
2. RIB Data . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. RIB Definition . . . . . . . . . . . . . . . . . . . . . 7
2.2. Routing Instance . . . . . . . . . . . . . . . . . . . . 7
2.3. Route . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4. Nexthop . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.4.1. Base Nexthops . . . . . . . . . . . . . . . . . . . . 12
2.4.2. Derived Nexthops . . . . . . . . . . . . . . . . . . 14
2.4.3. Nexthop Indirection . . . . . . . . . . . . . . . . . 15
3. Reading from the RIB . . . . . . . . . . . . . . . . . . . . 16
4. Writing to the RIB . . . . . . . . . . . . . . . . . . . . . 16
5. Notifications . . . . . . . . . . . . . . . . . . . . . . . . 17
6. RIB Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.1. Nexthop Grammar Explained . . . . . . . . . . . . . . . . 20
7. Using the RIB Grammar . . . . . . . . . . . . . . . . . . . . 20
7.1. Using Route Preference . . . . . . . . . . . . . . . . . 20
7.2. Using Different Nexthop Types . . . . . . . . . . . . . . 20
7.2.1. Tunnel Nexthops . . . . . . . . . . . . . . . . . . . 21
7.2.2. Replication Lists . . . . . . . . . . . . . . . . . . 21
7.2.3. Weighted Lists . . . . . . . . . . . . . . . . . . . 21
7.2.4. Protection . . . . . . . . . . . . . . . . . . . . . 22
7.2.5. Nexthop Chains . . . . . . . . . . . . . . . . . . . 22
7.2.6. Lists of Lists . . . . . . . . . . . . . . . . . . . 23
7.3. Performing Multicast . . . . . . . . . . . . . . . . . . 24
8. RIB Operations at Scale . . . . . . . . . . . . . . . . . . . 25
8.1. RIB Reads . . . . . . . . . . . . . . . . . . . . . . . . 25
8.2. RIB Writes . . . . . . . . . . . . . . . . . . . . . . . 25
8.3. RIB Events and Notifications . . . . . . . . . . . . . . 25
9. Security Considerations . . . . . . . . . . . . . . . . . . . 25
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
11.1. Normative References . . . . . . . . . . . . . . . . . . 26
11.2. Informative References . . . . . . . . . . . . . . . . . 27
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Conventions Used in This Document . . . . . . . . . . . . 6
2. RIB Data . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. RIB Definition . . . . . . . . . . . . . . . . . . . . . 7
2.2. Routing Instance . . . . . . . . . . . . . . . . . . . . 7
2.3. Route . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4. Nexthop . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.4.1. Base Nexthops . . . . . . . . . . . . . . . . . . . . 12
2.4.2. Derived Nexthops . . . . . . . . . . . . . . . . . . 14
2.4.3. Nexthop Indirection . . . . . . . . . . . . . . . . . 15
3. Reading from the RIB . . . . . . . . . . . . . . . . . . . . 16
4. Writing to the RIB . . . . . . . . . . . . . . . . . . . . . 16
5. Notifications . . . . . . . . . . . . . . . . . . . . . . . . 17
6. RIB Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.1. Nexthop Grammar Explained . . . . . . . . . . . . . . . . 20
7. Using the RIB Grammar . . . . . . . . . . . . . . . . . . . . 20
7.1. Using Route Preference . . . . . . . . . . . . . . . . . 20
7.2. Using Different Nexthop Types . . . . . . . . . . . . . . 20
7.2.1. Tunnel Nexthops . . . . . . . . . . . . . . . . . . . 21
7.2.2. Replication Lists . . . . . . . . . . . . . . . . . . 21
7.2.3. Weighted Lists . . . . . . . . . . . . . . . . . . . 21
7.2.4. Protection . . . . . . . . . . . . . . . . . . . . . 22
7.2.5. Nexthop Chains . . . . . . . . . . . . . . . . . . . 22
7.2.6. Lists of Lists . . . . . . . . . . . . . . . . . . . 23
7.3. Performing Multicast . . . . . . . . . . . . . . . . . . 24
8. RIB Operations at Scale . . . . . . . . . . . . . . . . . . . 25
8.1. RIB Reads . . . . . . . . . . . . . . . . . . . . . . . . 25
8.2. RIB Writes . . . . . . . . . . . . . . . . . . . . . . . 25
8.3. RIB Events and Notifications . . . . . . . . . . . . . . 25
9. Security Considerations . . . . . . . . . . . . . . . . . . . 25
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
11.1. Normative References . . . . . . . . . . . . . . . . . . 26
11.2. Informative References . . . . . . . . . . . . . . . . . 27
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
Routing and routing functions in enterprise and carrier networks are traditionally performed in network devices. Customarily, routers run routing protocols, and the routing protocols (along with static configuration information) populate the Routing Information Base (RIB) of the router. The RIB is managed by the RIB manager, and the RIB manager provides a northbound interface to its clients (i.e., the routing protocols) to insert routes into the RIB. The RIB manager consults the RIB and decides how to program the Forwarding Information Base (FIB) of the hardware by interfacing with the FIB manager. The relationship between these entities is shown in Figure 1.
企业和运营商网络中的路由和路由功能传统上是在网络设备中执行的。通常，路由器运行路由协议，路由协议（以及静态配置信息）填充路由器的路由信息库（RIB）。RIB由RIB管理器管理，RIB管理器向其客户端（即路由协议）提供北行接口，以将路由插入RIB。RIB管理器咨询RIB，并决定如何通过与FIB管理器接口来编程硬件的转发信息库（FIB）。这些实体之间的关系如图1所示。
+-------------+ +-------------+
|RIB Client 1 | ...... |RIB Client N |
+-------------+ +-------------+
^ ^
| |
+----------------------+
|
V
+---------------------+
| RIB Manager |
| |
| +--------+ |
| | RIB(s) | |
| +--------+ |
+---------------------+
^
|
+---------------------------------+
| |
V V
+----------------+ +----------------+
| FIB Manager 1 | | FIB Manager M |
| +--------+ | .......... | +--------+ |
| | FIB(s) | | | | FIB(s) | |
| +--------+ | | +--------+ |
+----------------+ +----------------+
+-------------+ +-------------+
|RIB Client 1 | ...... |RIB Client N |
+-------------+ +-------------+
^ ^
| |
+----------------------+
|
V
+---------------------+
| RIB Manager |
| |
| +--------+ |
| | RIB(s) | |
| +--------+ |
+---------------------+
^
|
+---------------------------------+
| |
V V
+----------------+ +----------------+
| FIB Manager 1 | | FIB Manager M |
| +--------+ | .......... | +--------+ |
| | FIB(s) | | | | FIB(s) | |
| +--------+ | | +--------+ |
+----------------+ +----------------+
Figure 1: RIB Manager, RIB Clients, and FIB Managers
图1:RIB经理、RIB客户和FIB经理
Routing protocols are inherently distributed in nature, and each router makes an independent decision based on the routing data received from its peers. With the advent of newer deployment paradigms and the need for specialized applications, there is an emerging need to guide the router's routing function [RFC7920]. The
路由协议本质上是分布式的，每个路由器根据从其对等方接收的路由数据做出独立的决策。随着新的部署模式的出现和对专用应用程序的需求，对路由器路由功能的指导需求日益增加[RFC7920]。这个
traditional network-device RIB population that is protocol based suffices for most use cases where distributed network control is used. However, there are use cases that the network operators currently address by configuring static routes, policies, and RIB import/export rules on the routers. There is also a growing list of use cases in which a network operator might want to program the RIB based on data unrelated to just routing (within that network's domain). Programming the RIB could be based on other information (such as routing data in the adjacent domain or the load on storage and compute) in the given domain. Or, it could simply be a programmatic way of creating on-demand dynamic overlays (e.g., GRE tunnels) between compute hosts (without requiring the hosts to run traditional routing protocols). If there was a standardized, publicly documented programmatic interface to a RIB, it would enable further networking applications that address a variety of use cases [RFC7920].
基于协议的传统网络设备RIB填充足以满足使用分布式网络控制的大多数用例。但是，网络运营商目前通过在路由器上配置静态路由、策略和RIB导入/导出规则来解决一些用例。网络运营商可能希望基于与路由无关的数据（在该网络的域内）对RIB进行编程的用例也越来越多。RIB的编程可以基于给定域中的其他信息（如相邻域中的路由数据或存储和计算负载）。或者，它可以只是在计算主机之间创建按需动态覆盖（例如GRE隧道）的编程方式（无需主机运行传统路由协议）。如果RIB有一个标准化的、公开记录的编程接口，它将支持进一步的网络应用程序，以解决各种用例[RFC7920]。
A programmatic interface to the RIB involves two types of operations: reading from the RIB and writing (adding/modifying/deleting) to the RIB.
RIB的编程接口涉及两种类型的操作：读取RIB和写入（添加/修改/删除）RIB。
In order to understand what is in a router's RIB, methods like per-protocol SNMP MIBs and screen scraping are used. These methods are not scalable since they are client pull mechanisms and not proactive push (from the router) mechanisms. Screen scraping is error prone (since the output format can change) and is vendor dependent. Building a RIB from per-protocol MIBs is error prone since the MIB data represents protocol data and not the exact information that went into the RIB. Thus, just getting read-only RIB information from a router is a hard task.
为了了解路由器RIB中的内容，使用了诸如每协议SNMP MIB和屏幕抓取等方法。这些方法是不可伸缩的，因为它们是客户端拉机制，而不是主动推送（来自路由器）机制。屏幕抓取容易出错（因为输出格式可能会更改），并且取决于供应商。从每个协议MIB构建RIB容易出错，因为MIB数据表示协议数据，而不是进入RIB的确切信息。因此，仅从路由器获取只读RIB信息是一项艰巨的任务。
Adding content to the RIB from a RIB client can be done today using static configuration mechanisms provided by router vendors. However, the mix of what can be modified in the RIB varies from vendor to vendor, and the method of configuring it is also vendor dependent. This makes it hard for a RIB client to program a multi-vendor network in a consistent and vendor-independent way.
现在，可以使用路由器供应商提供的静态配置机制从RIB客户端向RIB添加内容。但是，RIB中可修改内容的组合因供应商而异，配置方法也取决于供应商。这使得RIB客户端很难以一致且独立于供应商的方式编程多供应商网络。
The purpose of this document is to specify an information model for the RIB. Using the information model, one can build a detailed data model for the RIB. That data model could then be used by a RIB client to program a network device. One data model that has been based on this document is the I2RS RIB data model [RFC8431].
本文件的目的是指定肋骨的信息模型。使用信息模型，可以为肋骨建立详细的数据模型。然后，RIB客户端可以使用该数据模型对网络设备进行编程。基于本文件的一个数据模型是I2RS RIB数据模型[RFC8431]。
The rest of this document is organized as follows. Section 2 goes into the details of what constitutes and can be programmed in a RIB. Guidelines for reading and writing the RIB are provided in Sections 3 and 4, respectively. Section 5 provides a high-level view of the
本文件其余部分的组织如下。第2节详细介绍了肋骨的组成和可编程部分。第3节和第4节分别提供了RIB的阅读和书写指南。第5节提供了系统的高级视图
events and notifications going from a network device to a RIB client to update the RIB client on asynchronous events. The RIB grammar is specified in Section 6. Examples of using the RIB grammar are shown in Section 7. Section 8 covers considerations for performing RIB operations at scale.
从网络设备发送到RIB客户端的事件和通知，以在异步事件中更新RIB客户端。第6节规定了肋骨语法。第7节给出了使用肋骨语法的示例。第8节涵盖了大规模实施肋骨手术的注意事项。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
This section describes the details of a RIB. It makes forward references to objects in the RIB grammar (see Section 6). A high-level description of the RIB contents is as shown in Figure 2. Please note that for ease of representation in ASCII art, this drawing shows a single routing instance, a single RIB, and a single route. Subsections of this section describe the logical data nodes that should be contained within a RIB. Sections 3 and 4 describe the high-level read and write operations.
本节介绍肋的详细信息。它正向引用RIB语法中的对象（参见第6节）。肋骨内容的高级描述如图2所示。请注意，为了便于ASCII艺术表达，本图显示了一个布线实例、一个肋骨和一个布线。本节的小节描述了应包含在RIB中的逻辑数据节点。第3节和第4节描述了高级读写操作。
network-device
|
| 0..N
|
routing instance(s)
| |
| |
0..N | | 0..N
| |
interface(s) RIB(s)
|
|
| 0..N
|
route(s)
network-device
|
| 0..N
|
routing instance(s)
| |
| |
0..N | | 0..N
| |
interface(s) RIB(s)
|
|
| 0..N
|
route(s)
Figure 2: RIB Information Model
图2：肋骨信息模型
A RIB, in the context of the RIB information model, is an entity that contains routes. It is identified by its name and is contained within a routing instance (see Section 2.2). A network device MAY contain routing instances, and each routing instance MAY contain RIBs. The name MUST be unique within a routing instance. All routes in a given RIB MUST be of the same address family (e.g., IPv4). Each RIB MUST belong to a routing instance.
在肋骨信息模型的上下文中，肋骨是包含管线的实体。它由其名称标识，并包含在路由实例中（参见第2.2节）。网络设备可以包含路由实例，并且每个路由实例可以包含肋骨。该名称在路由实例中必须是唯一的。给定RIB中的所有路由必须具有相同的地址系列（例如IPv4）。每个加强筋必须属于一个布管实例。
A routing instance may contain two or more RIBs of the same address family (e.g., IPv6). A typical case where this can be used is for multi-topology routing [RFC4915] [RFC5120].
路由实例可能包含同一地址族（例如IPv6）的两个或多个肋骨。可用于多拓扑路由[RFC4915][RFC5120]的典型情况。
Each RIB MAY be associated with an ENABLE_IP_RPF_CHECK attribute that enables Reverse Path Forwarding (RPF) checks on all IP routes in that RIB. The RPF check is used to prevent spoofing and limit malicious traffic. For IP packets, the IP source address is looked up and the RPF interface(s) associated with the route for that IP source address is found. If the incoming IP packet's interface matches one of the RPF interfaces, then the IP packet is forwarded based on its IP destination address; otherwise, the IP packet is discarded.
每个RIB都可能与ENABLE_IP_RPF_CHECK属性相关联，该属性在该RIB中的所有IP路由上启用反向路径转发（RPF）检查。RPF检查用于防止欺骗和限制恶意流量。对于IP数据包，将查找IP源地址，并找到与该IP源地址的路由关联的RPF接口。如果传入IP包的接口与RPF接口之一匹配，则IP包根据其IP目的地地址转发；否则，IP数据包将被丢弃。
A routing instance, in the context of the RIB information model, is a collection of RIBs, interfaces, and routing parameters. A routing instance creates a logical slice of the router. It allows different logical slices across a set of routers to communicate with each other. Layer 3 VPNs, Layer 2 VPNs (L2VPNs), and Virtual Private LAN Service (VPLS) can be modeled as routing instances. Note that modeling an L2VPN using a routing instance only models the Layer 3 (RIB) aspect and does not model any Layer 2 information (like ARP) that might be associated with the L2VPN.
在肋骨信息模型的上下文中，布线实例是肋骨、接口和布线参数的集合。路由实例创建路由器的逻辑片。它允许一组路由器上的不同逻辑片相互通信。第3层VPN、第2层VPN（L2VPN）和虚拟专用LAN服务（VPLS）可以建模为路由实例。请注意，使用路由实例对L2VPN进行建模仅对第3层（RIB）方面进行建模，而不对可能与L2VPN关联的任何第2层信息（如ARP）进行建模。
The set of interfaces indicates which interfaces are associated with this routing instance. The RIBs specify how incoming traffic is to be forwarded, and the routing parameters control the information in the RIBs. The intersection set of interfaces of two routing instances MUST be the null set. In other words, an interface MUST NOT be present in two routing instances. Thus, a routing instance describes the routing information and parameters across a set of interfaces.
接口集指示哪些接口与此路由实例关联。肋骨指定如何转发传入流量，路由参数控制肋骨中的信息。两个路由实例的接口交叉集必须为空集。换句话说，接口不能出现在两个路由实例中。因此，路由实例描述了一组接口上的路由信息和参数。
A routing instance MUST contain the following mandatory fields:
路由实例必须包含以下必填字段：
o INSTANCE_NAME: A routing instance is identified by its name, INSTANCE_NAME. This MUST be unique across all routing instances in a given network device.
o 实例\名称：路由实例由其名称、实例\名称标识。这在给定网络设备中的所有路由实例中都必须是唯一的。
o rib-list: This is the list of RIBs associated with this routing instance. Each routing instance can have multiple RIBs to represent routes of different types. For example, one would put IPv4 routes in one RIB and MPLS routes in another RIB. The list of RIBs can be an empty list.
o 加强筋列表：这是与此布线实例关联的加强筋列表。每个布线实例可以有多个加强筋来表示不同类型的布线。例如，可以将IPv4路由放在一个RIB中，将MPLS路由放在另一个RIB中。肋骨列表可以是空列表。
A routing instance MAY contain the following fields:
路由实例可能包含以下字段：
o interface-list: This represents the list of interfaces associated with this routing instance. The interface list helps constrain the boundaries of packet forwarding. Packets coming in on these interfaces are directly associated with the given routing instance. The interface list contains a list of identifiers, with each identifier uniquely identifying an interface.
o 接口列表：表示与此路由实例关联的接口列表。接口列表有助于限制数据包转发的边界。进入这些接口的数据包与给定的路由实例直接关联。接口列表包含标识符列表，每个标识符唯一地标识一个接口。
o ROUTER_ID: This field identifies the network device in control plane interactions with other network devices. This field is to be used if one wants to virtualize a physical router into multiple virtual routers. Each virtual router MUST have a unique ROUTER_ID. A ROUTER_ID MUST be unique across all network devices in a given domain.
o 路由器ID：此字段标识控制平面中与其他网络设备交互的网络设备。如果要将物理路由器虚拟化为多个虚拟路由器，则使用此字段。每个虚拟路由器必须具有唯一的路由器ID。路由器ID在给定域中的所有网络设备上必须是唯一的。
A routing instance may be created purely for the purposes of packet processing and may not have any interfaces associated with it. For example, an incoming packet in routing instance A might have a nexthop of routing instance B, and after packet processing in B, the nexthop might be routing instance C. Thus, routing instance B is not associated with any interface. And, given that this routing instance does not do any control-plane interaction with other network devices, a ROUTER_ID is also not needed.
路由实例可以纯粹为了分组处理的目的而创建，并且可能没有任何与之相关联的接口。例如，路由实例A中的传入数据包可能具有路由实例B的nexthop，并且在B中进行数据包处理后，nexthop可能是路由实例C。因此，路由实例B与任何接口都不关联。而且，鉴于此路由实例不与其他网络设备进行任何控制平面交互，因此也不需要路由器ID。
A route is essentially a match condition and an action following the match. The match condition specifies the kind of route (IPv4, MPLS, etc.) and the set of fields to match on. Figure 3 represents the overall contents of a route. Please note that for ease of depiction in ASCII art, only a single instance of the route-attribute, match flags, and nexthop is depicted.
路由本质上是匹配条件和匹配后的操作。匹配条件指定要匹配的路由类型（IPv4、MPLS等）和字段集。图3显示了路线的总体内容。请注意，为了便于ASCII艺术中的描述，只描述了路由属性、匹配标志和nexthop的一个实例。
route
| | |
+---------+ | +----------+
| | |
0..N | | |
route
| | |
+---------+ | +----------+
| | |
0..N | | |
route-attribute match nexthop
|
|
+-------+-------+-------+--------+
| | | | |
| | | | |
route-attribute match nexthop
|
|
+-------+-------+-------+--------+
| | | | |
| | | | |
IPv4 IPv6 MPLS MAC Interface
IPv4 IPv6 MPLS MAC接口
Figure 3: Route Model
图3：路线模型
This document specifies the following match types:
本文档指定了以下匹配类型：
o IPv4: Match on destination and/or source IP address in the IPv4 header
o IPv4:在IPv4标头中匹配目标和/或源IP地址
o IPv6: Match on destination and/or source IP address in the IPv6 header
o IPv6:在IPv6标头中匹配目标和/或源IP地址
o MPLS: Match on an MPLS label at the top of the MPLS label stack
o MPLS：匹配MPLS标签堆栈顶部的MPLS标签
o MAC: Match on Media Access Control (MAC) destination addresses in the Ethernet header
o MAC：匹配以太网报头中的媒体访问控制（MAC）目标地址
o Interface: Match on the incoming interface of the packet
o 接口：匹配数据包的传入接口
A route MAY be matched on one or more of these match types by policy as either an "AND" (to restrict the number of routes) or an "OR" (to combine two filters).
策略可以在一个或多个匹配类型上将路由匹配为“AND”（限制路由数量）或“or”（组合两个筛选器）。
Each route MUST have the following mandatory route-attributes associated with it:
每个路由必须具有以下与之关联的强制路由属性：
o ROUTE_PREFERENCE: This is a numerical value that allows for comparing routes from different protocols. Static configuration is also considered a protocol for the purpose of this field. It is also known as "administrative distance". The lower the value, the higher the preference. For example, there can be an OSPF route for 192.0.2.1/32 (or IPv6 2001:DB8::1/128) with a preference of 5. If a controller programs a route for 192.0.2.1/32 (or IPv6 2001:DB8::1/128) with a preference of 2, then the controller's route will be preferred by the RIB manager. Preference should be
o ROUTE_PREFERENCE：这是一个数值，允许比较来自不同协议的路由。在本领域中，静态配置也被视为一种协议。它也被称为“行政距离”。值越低，首选项越高。例如，192.0.2.1/32（或IPv6 2001:DB8:：1/128）可以有一个首选项为5的OSPF路由。如果控制器为192.0.2.1/32（或IPv6 2001:DB8:：1/128）编程一条首选项为2的路由，则RIB管理器将首选控制器的路由。偏好应该是
used to dictate behavior. For more examples of preference, see Section 7.1.
用来指示行为。更多偏好示例，请参见第7.1节。
Each route can have one or more optional route-attributes associated with it.
每个管线都可以有一个或多个与之关联的可选管线属性。
o route-vendor-attributes: Vendors can specify vendor-specific attributes using this. The details of this attribute are outside the scope of this document.
o 路由供应商属性：供应商可以使用此选项指定特定于供应商的属性。此属性的详细信息不在此文档范围内。
Each route has a nexthop associated with it. Nexthops are described in Section 2.4.
每条路线都有一个与之关联的nexthop。第2.4节描述了下一步。
Additional features to match multicast packets were considered (e.g., TTL of the packet to limit the range of a multicast group), but these were not added to this information model. Future RIB information models should investigate these multicast features.
考虑了匹配多播数据包的附加功能（例如，数据包的TTL限制多播组的范围），但这些功能没有添加到此信息模型中。未来的RIB信息模型应该研究这些多播特性。
A nexthop represents an object resulting from a route lookup. For example, if a route lookup results in sending the packet out of a given interface, then the nexthop represents that interface.
nexthop表示路由查找产生的对象。例如，如果路由查找导致从给定接口发送数据包，那么nexthop表示该接口。
Nexthops can be either fully resolved or unresolved. A resolved nexthop has adequate information to send the outgoing packet to the destination by forwarding it on an interface to a directly connected neighbor. For example, a nexthop to a point-to-point interface or a nexthop to an IP address on an Ethernet interface has the nexthop resolved. An unresolved nexthop is something that requires the RIB manager to determine the final resolved nexthop. For example, a nexthop could be an IP address. The RIB manager would resolve how to reach that IP address; for example, is the IP address reachable by regular IP forwarding, by an MPLS tunnel, or by both? If the RIB manager cannot resolve the nexthop, then the nexthop remains in an unresolved state and is NOT a candidate for installation in the FIB. Future RIB events can cause an unresolved nexthop to get resolved (e.g., an IP address being advertised by an IGP neighbor). Conversely, resolved nexthops can also become unresolved (e.g., in the case of a tunnel going down); hence, they would no longer be candidates to be installed in the FIB.
下一个问题可以完全解决，也可以不解决。解析的nexthop具有足够的信息，可以通过接口将传出数据包转发给直接连接的邻居，从而将其发送到目的地。例如，点到点接口的nexthop或以太网接口上IP地址的nexthop已解析nexthop。未解决的下一个问题需要RIB经理确定最终解决的下一个问题。例如，nexthop可以是IP地址。RIB经理将解决如何到达该IP地址；例如，通过常规IP转发、MPLS隧道或两者都可以访问IP地址吗？如果RIB管理器无法解析nexthop，则nexthop将保持未解析状态，并且不是FIB中安装的候选。未来的RIB事件可能导致未解析的下一个IP得到解析（例如，IGP邻居正在播发IP地址）。相反，已解决的下一个问题也可能无法解决（例如，在隧道下沉的情况下）；因此，它们将不再是安装在FIB中的候选设备。
When at least one of a route's nexthops is resolved, then the route can be used to forward packets. Such a route is considered eligible to be installed in the FIB and is henceforth referred to as a FIB-eligible route. Conversely, when all the nexthops of a route are unresolved, that route can no longer be used to forward packets. Such a route is considered ineligible to be installed in the FIB and
当至少一个路由的nexthop被解析时，该路由可用于转发数据包。这样的路线被认为有资格安装在FIB中，因此被称为FIB合格路线。相反，当一条路由的所有下一个路径都未解析时，该路由就不能再用于转发数据包。这种路线被认为不符合安装在FIB和
is henceforth referred to as a FIB-ineligible route. The RIB information model allows a RIB client to program routes whose nexthops may be unresolved initially. Whenever an unresolved nexthop gets resolved, the RIB manager will send a notification of the same (see Section 5).
从此被称为FIB不合格路线。RIB信息模型允许RIB客户端对其下一个路径最初可能无法解决的路径进行编程。每当未解决的下一个问题得到解决时，RIB经理将发送相同的通知（见第5节）。
The overall structure and usage of a nexthop is as shown in the figure below. For ease of description using ASCII art, only a single instance of any component of the nexthop is shown in Figure 4.
nexthop的总体结构和用法如下图所示。为了便于使用ASCII art进行描述，图4中只显示了nexthop任何组件的一个实例。
route
|
| 0..N
|
nexthop <-------------------------------+
| |
+-------+----------------------------+-------------+ |
| | | | | |
| | | | | |
base load-balance protection replicate chain |
| | | | | |
| |2..N |2..N |2..N |1..N |
| | | | | |
| | V | | |
| +------------->+<------------+-------------+ |
| | |
| +-------------------------------------+
|
+-------------------+
|
|
|
|
+---------------+--------+--------+--------------+----------+
| | | | |
| | | | |
nexthop-id egress-interface ip-address logical-tunnel |
|
|
+--------------------------------------+
|
+----------------------+------------------+-------------+
| | | |
| | | |
tunnel-encapsulation tunnel-decapsulation rib-name special-nexthop
route
|
| 0..N
|
nexthop <-------------------------------+
| |
+-------+----------------------------+-------------+ |
| | | | | |
| | | | | |
base load-balance protection replicate chain |
| | | | | |
| |2..N |2..N |2..N |1..N |
| | | | | |
| | V | | |
| +------------->+<------------+-------------+ |
| | |
| +-------------------------------------+
|
+-------------------+
|
|
|
|
+---------------+--------+--------+--------------+----------+
| | | | |
| | | | |
nexthop-id egress-interface ip-address logical-tunnel |
|
|
+--------------------------------------+
|
+----------------------+------------------+-------------+
| | | |
| | | |
tunnel-encapsulation tunnel-decapsulation rib-name special-nexthop
Figure 4: Nexthop Model
图4:Nexthop模型
This document specifies a very generic, extensible, and recursive grammar for nexthops. A nexthop can be a base nexthop or a derived nexthop. Section 2.4.1 details base nexthops, and Section 2.4.2 explains various kinds of derived nexthops. There are certain special nexthops, and those are described in Section 2.4.1.1. Lastly, Section 2.4.3 delves into nexthop indirection and its use. Examples of when and how to use tunnel nexthops and derived nexthops are shown in Section 7.2.
本文档为nexthops指定了一个非常通用、可扩展和递归的语法。nexthop可以是基本nexthop或派生nexthop。第2.4.1节详细说明了基本nexthops，第2.4.2节解释了各种衍生nexthops。存在某些特殊的NEXTHOP，这些在第2.4.1.1节中描述。最后，第2.4.3节深入探讨了nexthop间接寻址及其使用。第7.2节显示了何时以及如何使用隧道nexthops和派生nexthops的示例。
At the lowest level, a nexthop can be one of the following:
在最低级别，下一个选项可以是以下选项之一：
o Identifier: This is an identifier returned by the network device representing a nexthop. This can be used as a way of reusing a nexthop when programming derived nexthops.
o 标识符：这是网络设备返回的标识符，表示下一步操作。在对派生的nexthop进行编程时，这可以作为重用nexthop的一种方式。
o Interface nexthops: These are nexthops that are pointing to an interface. Various attributes associated with these nexthops are:
o 接口nexthops：这些是指向接口的nexthops。与这些nexthop相关的各种属性包括：
* Egress-interface: This represents a physical, logical, or virtual interface on the network device. Address resolution must not be required on this interface. This interface may belong to any routing instance.
* 出口接口：表示网络设备上的物理、逻辑或虚拟接口。此接口上不需要地址解析。此接口可能属于任何路由实例。
* IP address: A route lookup on this IP address is done to determine the egress-interface. Address resolution may be required depending on the interface.
* IP地址：对该IP地址进行路由查找以确定出口接口。根据接口的不同，可能需要地址解析。
+ An optional rib-name can also be specified to indicate the RIB in which the IP address is to be looked up. One can use the rib-name field to direct the packet from one domain into another domain. By default the RIB will be the same as the one that route belongs to.
+ 还可以指定可选rib名称，以指示要在其中查找IP地址的rib。可以使用rib名称字段将数据包从一个域定向到另一个域。默认情况下，加强筋将与管线所属的加强筋相同。
These attributes can be used in combination as follows:
这些属性可以组合使用，如下所示：
* Egress-interface and IP address: This can be used in cases where, e.g., the IP address is a link-local address.
* 出口接口和IP地址：可在IP地址为链路本地地址的情况下使用。
* Egress-interface and MAC address: The egress-interface must be an Ethernet interface. Address resolution is not required for this nexthop.
* 出口接口和MAC地址：出口接口必须是以太网接口。此下一步不需要地址解析。
o Tunnel nexthops: These are nexthops that are pointing to a tunnel. The types of tunnel nexthops are:
o 隧道nexthops：这些是指向隧道的nexthops。以下隧道类型包括：
* tunnel-encapsulation: This can be an encapsulation representing an IP tunnel, MPLS tunnel, or others as defined in this document. An optional egress-interface can be chained to the tunnel-encapsulation to indicate which interface to send the packet out on. The egress-interface is useful when the network device contains Ethernet interfaces and one needs to perform address resolution for the IP packet.
* 隧道封装：这可以是表示IP隧道、MPLS隧道或本文档中定义的其他隧道的封装。可选的出口接口可以链接到隧道封装，以指示在哪个接口上发送数据包。当网络设备包含以太网接口并且需要对IP数据包执行地址解析时，出口接口非常有用。
* tunnel-decapsulation: This is to specify decapsulating a tunnel header. After decapsulation, further lookup on the packet can be done via chaining it with another nexthop. The packet can also be sent out via an egress-interface directly.
* 隧道解除封装：用于指定解除隧道标头的封装。解除封装后，可以通过将数据包与另一个nexthop链接来进一步查找数据包。数据包也可以通过出口接口直接发送出去。
* logical-tunnel: This can be an MPLS Label Switched Path (LSP) or a GRE tunnel (or others as defined in this document) that is represented by a unique identifier (e.g., name).
* 逻辑隧道：这可以是由唯一标识符（例如名称）表示的MPLS标签交换路径（LSP）或GRE隧道（或本文档中定义的其他隧道）。
o rib-name: A nexthop pointing to a RIB. This indicates that the route lookup needs to continue in the specified RIB. This is a way to perform chained lookups.
o 肋骨名称：指向肋骨的下一个顶点。这表示管线查找需要在指定的加强筋中继续。这是一种执行链接查找的方法。
Tunnel nexthops allow a RIB client to program static tunnel headers. There can be cases where the remote tunnel endpoint does not support dynamic signaling (e.g., no LDP support on a host); in those cases, the RIB client might want to program the tunnel header on both ends of the tunnel. The tunnel nexthop is kept generic with specifications provided for some commonly used tunnels. It is expected that the data model will model these tunnel types with complete accuracy.
Tunnel nexthops允许RIB客户端对静态隧道头进行编程。可能存在远程隧道端点不支持动态信令的情况（例如，主机上不支持LDP）；在这些情况下，RIB客户端可能希望在隧道两端对隧道标头进行编程。nexthop隧道保持通用，为一些常用隧道提供了规范。预计数据模型将完全准确地模拟这些隧道类型。
Special nexthops are for performing specific well-defined functions (e.g., DISCARD). The purpose of each of them is explained below:
特殊的NEXTHOP用于执行特定的定义明确的功能（例如，丢弃）。以下解释了每种方法的目的：
o DISCARD: This indicates that the network device should drop the packet and increment a drop counter.
o 丢弃：这表示网络设备应该丢弃数据包并增加丢弃计数器。
o DISCARD_WITH_ERROR: This indicates that the network device should drop the packet, increment a drop counter, and send back an appropriate error message (like ICMP error).
o DISCARD_WITH_ERROR：这表示网络设备应丢弃数据包，增加丢弃计数器，并发回适当的错误消息（如ICMP ERROR）。
o RECEIVE: This indicates that the traffic is destined for the network device, for example, protocol packets or Operations, Administration, and Maintenance (OAM) packets. All locally destined traffic SHOULD be throttled to avoid a denial-of-service attack on the router's control plane. An optional rate limiter can be specified to indicate how to throttle traffic destined for the control plane. The description of the rate limiter is outside the scope of this document.
o 接收：这表示通信量的目的地是网络设备，例如，协议数据包或操作、管理和维护（OAM）数据包。应限制所有本地目的流量，以避免路由器控制平面上的拒绝服务攻击。可以指定一个可选的速率限制器，以指示如何限制发送到控制平面的流量。限速器的说明不在本文件范围内。
Derived nexthops can be:
派生的nexthop可以是：
o weighted lists, which are used for load-balancing;
o 加权列表，用于负载平衡；
o preference lists, which are used for protection using primary and backup;
o 首选项列表，用于使用主和备份进行保护；
o replication lists, which are lists of nexthops to which to replicate a packet;
o 复制列表，是要将数据包复制到的下一个端口的列表；
o nexthop chains, which are for chaining multiple operations or attaching multiple headers; or
o nexthop链，用于链接多个操作或附加多个标头；或
o lists of lists, which are a recursive application of the above.
o 列表的列表，这是上面的递归应用程序。
Nexthop chains (see Section 7.2.5 for usage) are a way to perform multiple operations on a packet by logically combining them. For example, one can chain together "decapsulate MPLS header" and "send it out a specific egress-interface". Chains can be used to specify multiple headers over a packet before a packet is forwarded. One simple example is that of MPLS over GRE, wherein the packet has an inner MPLS header followed by a GRE header followed by an IP header. The outermost IP header is decided by the network device, whereas the MPLS header or GRE header is specified by the controller. Not every network device will be able to support all kinds of nexthop chains and an arbitrary number of headers chained together. The RIB data model SHOULD provide a way to expose a nexthop chaining capability supported by a given network device.
Nexthop链（参见第7.2.5节了解用法）是一种通过逻辑组合对数据包执行多个操作的方法。例如，可以将“去封装MPLS头”和“将其发送到特定出口接口”链接在一起。链可用于在转发数据包之前指定数据包上的多个报头。一个简单的例子是基于GRE的MPLS，其中该分组具有一个内部MPLS报头，后跟一个GRE报头，后跟一个IP报头。最外层的IP报头由网络设备决定，而MPLS报头或GRE报头由控制器指定。并不是每个网络设备都能够支持所有类型的nexthop链和链接在一起的任意数量的头。RIB数据模型应提供一种方式，以公开给定网络设备支持的nexthop链接功能。
It is expected that all network devices will have a limit on how many levels of lookup can be performed, and not all hardware will be able to support all kinds of nexthops. RIB capability negotiation becomes very important for this reason, and a RIB data model MUST specify a way for a RIB client to learn about the network device's capabilities.
预计所有网络设备都将对可执行的查找级别有限制，并且并非所有硬件都能够支持所有类型的Nexthop。因此，RIB能力协商变得非常重要，RIB数据模型必须指定RIB客户端了解网络设备能力的方法。
For nexthops that are of the form of a list(s), attributes can be associated with each member of the list to indicate the role of an individual member of the list. Two attributes are specified:
对于列表形式的nexthop，属性可以与列表的每个成员关联，以指示列表中单个成员的角色。指定了两个属性：
o NEXTHOP_PREFERENCE: This is used for protection schemes. It is an integer value between 1 and 99. A lower value indicates higher preference. To download a primary/standby pair to the FIB, the nexthops that are resolved and have the two highest preferences are selected. Each <NEXTHOP_PREFERENCE> should have a unique value within a <nexthop-protection> (see Section 6).
o NEXTHOP_首选项：用于保护方案。它是一个介于1和99之间的整数值。值越低表示偏好越高。要将主/备用对下载到FIB，请选择已解析且具有两个最高首选项的下一个选项。每个<NEXTHOP_首选项>在<NEXTHOP protection>中都应该有一个唯一的值（参见第6节）。
o NEXTHOP_LB_WEIGHT: This is used for load-balancing. Each list member MUST be assigned a weight between 1 and 99. The weight determines the proportion of traffic to be sent over a nexthop used for forwarding as a ratio of the weight of this nexthop divided by the weights of all the nexthops of this route that are used for forwarding. To perform equal load-balancing, one MAY specify a weight of "0" for all the member nexthops. The value "0" is reserved for equal load-balancing and, if applied, MUST be applied to all member nexthops. Note that a weight of 0 is special because of historical reasons.
o NEXTHOP_LB_重量：用于负载平衡。必须为每个列表成员分配1到99之间的权重。权重决定了在用于转发的下一个路径上发送的流量的比例，即该下一个路径的权重除以该路由中用于转发的所有下一个路径的权重的比率。要执行相等的负载平衡，可以为所有成员nexthop指定权重“0”。值“0”保留用于相等的负载平衡，如果应用，则必须应用于所有成员nexthop。请注意，由于历史原因，权重0是特殊的。
Nexthops can be identified by an identifier to create a level of indirection. The identifier is set by the RIB manager and returned to the RIB client on request.
nexthop可以通过一个标识符来标识，以创建一个间接级别。标识由RIB管理器设置，并根据要求返回给RIB客户端。
One example of usage of indirection is a nexthop that points to another network device (e.g., a BGP peer). The returned nexthop identifier can then be used for programming routes to point to the this nexthop. Given that the RIB manager has created an indirection using the nexthop identifier, if the transport path to the network device (BGP peer) changes, that change in path will be seamless to the RIB client and all routes that point to that network device will automatically start going over the new transport path. Nexthop indirection using identifiers could be applied to not only unicast nexthops but also nexthops that contain chains and nested nexthops. See Section 2.4.2 for examples.
使用间接寻址的一个示例是指向另一个网络设备（例如，BGP对等机）的下一个IP。然后，返回的nexthop标识符可用于编程路由，以指向此nexthop。鉴于RIB管理器已使用nexthop标识符创建了一个间接寻址，如果到网络设备（BGP对等方）的传输路径发生变化，则该路径的变化将无缝连接到RIB客户端，并且指向该网络设备的所有路由将自动开始通过新的传输路径。使用标识符的Nexthop间接寻址不仅可以应用于单播Nexthop，还可以应用于包含链和嵌套Nexthop的Nexthop。示例见第2.4.2节。
A RIB data model MUST allow a RIB client to read entries for RIBs created by that entity. The network device administrator MAY allow reading of other RIBs by a RIB client through access lists on the network device. The details of access lists are outside the scope of this document.
肋骨数据模型必须允许肋骨客户端读取由该实体创建的肋骨的条目。网络设备管理员可允许RIB客户端通过网络设备上的访问列表读取其他RIB。访问列表的详细信息不在本文档的范围内。
The data model MUST support a full read of the RIB and subsequent incremental reads of changes to the RIB. When sending data to a RIB client, the RIB manager SHOULD try to send all dependencies of an object prior to sending that object.
数据模型必须支持RIB的完全读取和RIB更改的后续增量读取。向RIB客户端发送数据时，RIB管理器应在发送对象之前尝试发送对象的所有依赖项。
A RIB data model MUST allow a RIB client to write entries for RIBs created by that entity. The network device administrator MAY allow writes to other RIBs by a RIB client through access lists on the network device. The details of access lists are outside the scope of this document.
RIB数据模型必须允许RIB客户端为该实体创建的RIB写入条目。网络设备管理员可允许RIB客户端通过网络设备上的访问列表写入其他RIB。访问列表的详细信息不在本文档的范围内。
When writing an object to a RIB, the RIB client SHOULD try to write all dependencies of the object prior to sending that object. The data model SHOULD support requesting identifiers for nexthops and collecting the identifiers back in the response.
将对象写入RIB时，RIB客户端应在发送该对象之前尝试写入该对象的所有依赖项。数据模型应该支持为nexthop请求标识符，并在响应中收集标识符。
Route programming in the RIB MUST result in a return code that contains the following attributes:
RIB中的管线编程必须产生包含以下属性的返回代码：
o Installed: Yes/No (indicates whether the route got installed in the FIB)
o 已安装：是/否（指示路由是否已安装在FIB中）
o Active: Yes/No (indicates whether a route is fully resolved and is a candidate for selection)
o 活动：是/否（指示路由是否已完全解析，是否为候选路由）
o Reason: E.g., "Not authorized"
o 原因：例如，“未授权”
The data model MUST specify which objects can be modified. An object that can be modified is one whose contents can be changed without having to change objects that depend on it and without affecting any data forwarding. To change a non-modifiable object, one will need to create a new object and delete the old one. For example, routes that use a nexthop that is identified by a nexthop identifier should be unaffected when the contents of that nexthop changes.
数据模型必须指定可以修改的对象。可以修改的对象是其内容可以更改的对象，而不必更改依赖它的对象，也不影响任何数据转发。要更改不可修改的对象，需要创建新对象并删除旧对象。例如，使用由nexthop标识符标识的nexthop的路由在该nexthop的内容更改时不应受到影响。
Asynchronous notifications are sent by the network device's RIB manager to a RIB client when some event occurs on the network device. A RIB data model MUST support sending asynchronous notifications. A brief list of suggested notifications is as below:
当网络设备上发生某些事件时，网络设备的RIB管理器会向RIB客户端发送异步通知。RIB数据模型必须支持发送异步通知。建议通知的简要列表如下：
o Route change notification (with a return code as specified in Section 4)
o 路线变更通知（带有第4节规定的返回代码）
o Nexthop resolution status (resolved/unresolved) notification
o 下一步解决状态（已解决/未解决）通知
This section specifies the RIB information model in Routing Backus-Naur Form (rBNF) [RFC5511]. This grammar is intended to help the reader better understand Section 2 in order to derive a data model.
本节规定了路由巴科斯诺尔表（rBNF）[RFC5511]中的肋骨信息模型。本语法旨在帮助读者更好地理解第2节，以便导出数据模型。
<routing-instance> ::= <INSTANCE_NAME>
[<interface-list>] <rib-list>
[<ROUTER_ID>]
<routing-instance> ::= <INSTANCE_NAME>
[<interface-list>] <rib-list>
[<ROUTER_ID>]
<interface-list> ::= (<INTERFACE_IDENTIFIER> ...)
<interface-list> ::= (<INTERFACE_IDENTIFIER> ...)
<rib-list> ::= (<rib> ...)
<rib> ::= <rib-name> <address-family>
[<route> ... ]
[ENABLE_IP_RPF_CHECK]
<address-family> ::= <IPV4_ADDRESS_FAMILY> | <IPV6_ADDRESS_FAMILY> |
<MPLS_ADDRESS_FAMILY> | <IEEE_MAC_ADDRESS_FAMILY>
<rib-list> ::= (<rib> ...)
<rib> ::= <rib-name> <address-family>
[<route> ... ]
[ENABLE_IP_RPF_CHECK]
<address-family> ::= <IPV4_ADDRESS_FAMILY> | <IPV6_ADDRESS_FAMILY> |
<MPLS_ADDRESS_FAMILY> | <IEEE_MAC_ADDRESS_FAMILY>
<route> ::= <match> <nexthop>
[<route-attributes>]
[<route-vendor-attributes>]
<route> ::= <match> <nexthop>
[<route-attributes>]
[<route-vendor-attributes>]
<match> ::= <IPV4> <ipv4-route> | <IPV6> <ipv6-route> |
<MPLS> <MPLS_LABEL> | <IEEE_MAC> <MAC_ADDRESS> |
<INTERFACE> <INTERFACE_IDENTIFIER>
<route-type> ::= <IPV4> | <IPV6> | <MPLS> | <IEEE_MAC> | <INTERFACE>
<match> ::= <IPV4> <ipv4-route> | <IPV6> <ipv6-route> |
<MPLS> <MPLS_LABEL> | <IEEE_MAC> <MAC_ADDRESS> |
<INTERFACE> <INTERFACE_IDENTIFIER>
<route-type> ::= <IPV4> | <IPV6> | <MPLS> | <IEEE_MAC> | <INTERFACE>
<ipv4-route> ::= <ip-route-type>
(<destination-ipv4-address> | <source-ipv4-address> |
(<destination-ipv4-address> <source-ipv4-address>))
<destination-ipv4-address> ::= <ipv4-prefix>
<source-ipv4-address> ::= <ipv4-prefix>
<ipv4-prefix> ::= <IPV4_ADDRESS> <IPV4_PREFIX_LENGTH>
<ipv4-route> ::= <ip-route-type>
(<destination-ipv4-address> | <source-ipv4-address> |
(<destination-ipv4-address> <source-ipv4-address>))
<destination-ipv4-address> ::= <ipv4-prefix>
<source-ipv4-address> ::= <ipv4-prefix>
<ipv4-prefix> ::= <IPV4_ADDRESS> <IPV4_PREFIX_LENGTH>
<ipv6-route> ::= <ip-route-type>
(<destination-ipv6-address> | <source-ipv6-address> |
(<destination-ipv6-address> <source-ipv6-address>))
<destination-ipv6-address> ::= <ipv6-prefix>
<source-ipv6-address> ::= <ipv6-prefix>
<ipv6-prefix> ::= <IPV6_ADDRESS> <IPV6_PREFIX_LENGTH>
<ip-route-type> ::= <SRC> | <DEST> | <DEST_SRC>
<ipv6-route> ::= <ip-route-type>
(<destination-ipv6-address> | <source-ipv6-address> |
(<destination-ipv6-address> <source-ipv6-address>))
<destination-ipv6-address> ::= <ipv6-prefix>
<source-ipv6-address> ::= <ipv6-prefix>
<ipv6-prefix> ::= <IPV6_ADDRESS> <IPV6_PREFIX_LENGTH>
<ip-route-type> ::= <SRC> | <DEST> | <DEST_SRC>
<route-attributes> ::= <ROUTE_PREFERENCE> [<LOCAL_ONLY>]
[<address-family-route-attributes>]
<route-attributes> ::= <ROUTE_PREFERENCE> [<LOCAL_ONLY>]
[<address-family-route-attributes>]
<address-family-route-attributes> ::= <ip-route-attributes> |
<mpls-route-attributes> |
<ethernet-route-attributes>
<ip-route-attributes> ::= <>
<mpls-route-attributes> ::= <>
<ethernet-route-attributes> ::= <>
<route-vendor-attributes> ::= <>
<address-family-route-attributes> ::= <ip-route-attributes> |
<mpls-route-attributes> |
<ethernet-route-attributes>
<ip-route-attributes> ::= <>
<mpls-route-attributes> ::= <>
<ethernet-route-attributes> ::= <>
<route-vendor-attributes> ::= <>
<nexthop> ::= <nexthop-base> |
(<NEXTHOP_LOAD_BALANCE> <nexthop-lb>) |
(<NEXTHOP_PROTECTION> <nexthop-protection>) |
(<NEXTHOP_REPLICATE> <nexthop-replicate>) |
<nexthop-chain>
<nexthop> ::= <nexthop-base> |
(<NEXTHOP_LOAD_BALANCE> <nexthop-lb>) |
(<NEXTHOP_PROTECTION> <nexthop-protection>) |
(<NEXTHOP_REPLICATE> <nexthop-replicate>) |
<nexthop-chain>
<nexthop-base> ::= <NEXTHOP_ID> |
<nexthop-special> |
<egress-interface> |
<ipv4-address> | <ipv6-address> |
(<egress-interface>
(<ipv4-address> | <ipv6-address>)) |
(<egress-interface> <IEEE_MAC_ADDRESS>) |
<tunnel-encapsulation> | <tunnel-decapsulation> |
<logical-tunnel> |
<rib-name>
<nexthop-base> ::= <NEXTHOP_ID> |
<nexthop-special> |
<egress-interface> |
<ipv4-address> | <ipv6-address> |
(<egress-interface>
(<ipv4-address> | <ipv6-address>)) |
(<egress-interface> <IEEE_MAC_ADDRESS>) |
<tunnel-encapsulation> | <tunnel-decapsulation> |
<logical-tunnel> |
<rib-name>
<egress-interface> ::= <INTERFACE_IDENTIFIER>
<egress-interface> ::= <INTERFACE_IDENTIFIER>
<nexthop-special> ::= <DISCARD> | <DISCARD_WITH_ERROR> |
(<RECEIVE> [<COS_VALUE>])
<nexthop-special> ::= <DISCARD> | <DISCARD_WITH_ERROR> |
(<RECEIVE> [<COS_VALUE>])
<nexthop-lb> ::= <NEXTHOP_LB_WEIGHT> <nexthop>
(<NEXTHOP_LB_WEIGHT> <nexthop) ...
<nexthop-lb> ::= <NEXTHOP_LB_WEIGHT> <nexthop>
(<NEXTHOP_LB_WEIGHT> <nexthop) ...
<nexthop-protection> = <NEXTHOP_PREFERENCE> <nexthop>
(<NEXTHOP_PREFERENCE> <nexthop>)...
<nexthop-protection> = <NEXTHOP_PREFERENCE> <nexthop>
(<NEXTHOP_PREFERENCE> <nexthop>)...
<nexthop-replicate> ::= <nexthop> <nexthop> ...
<nexthop-replicate> ::= <nexthop> <nexthop> ...
<nexthop-chain> ::= <nexthop> ...
<nexthop-chain> ::= <nexthop> ...
<logical-tunnel> ::= <tunnel-type> <TUNNEL_NAME>
<tunnel-type> ::= <IPV4> | <IPV6> | <MPLS> | <GRE> | <VxLAN> | <NVGRE>
<logical-tunnel> ::= <tunnel-type> <TUNNEL_NAME>
<tunnel-type> ::= <IPV4> | <IPV6> | <MPLS> | <GRE> | <VxLAN> | <NVGRE>
<tunnel-encapsulation> ::= (<IPV4> <ipv4-header>) |
(<IPV6> <ipv6-header>) |
(<MPLS> <mpls-header>) |
(<GRE> <gre-header>) |
(<VXLAN> <vxlan-header>) |
(<NVGRE> <nvgre-header>)
<tunnel-encapsulation> ::= (<IPV4> <ipv4-header>) |
(<IPV6> <ipv6-header>) |
(<MPLS> <mpls-header>) |
(<GRE> <gre-header>) |
(<VXLAN> <vxlan-header>) |
(<NVGRE> <nvgre-header>)
<ipv4-header> ::= <SOURCE_IPv4_ADDRESS> <DESTINATION_IPv4_ADDRESS>
<PROTOCOL> [<TTL>] [<DSCP>]
<ipv4-header> ::= <SOURCE_IPv4_ADDRESS> <DESTINATION_IPv4_ADDRESS>
<PROTOCOL> [<TTL>] [<DSCP>]
<ipv6-header> ::= <SOURCE_IPV6_ADDRESS> <DESTINATION_IPV6_ADDRESS>
<NEXT_HEADER> [<TRAFFIC_CLASS>]
[<FLOW_LABEL>] [<HOP_LIMIT>]
<ipv6-header> ::= <SOURCE_IPV6_ADDRESS> <DESTINATION_IPV6_ADDRESS>
<NEXT_HEADER> [<TRAFFIC_CLASS>]
[<FLOW_LABEL>] [<HOP_LIMIT>]
<mpls-header> ::= (<mpls-label-operation> ...)
<mpls-label-operation> ::= (<MPLS_PUSH> <MPLS_LABEL> [<S_BIT>]
[<TOS_VALUE>] [<TTL_VALUE>]) |
(<MPLS_SWAP> <IN_LABEL> <OUT_LABEL>
[<TTL_ACTION>])
<mpls-header> ::= (<mpls-label-operation> ...)
<mpls-label-operation> ::= (<MPLS_PUSH> <MPLS_LABEL> [<S_BIT>]
[<TOS_VALUE>] [<TTL_VALUE>]) |
(<MPLS_SWAP> <IN_LABEL> <OUT_LABEL>
[<TTL_ACTION>])
<gre-header> ::= <GRE_IP_DESTINATION> <GRE_PROTOCOL_TYPE> [<GRE_KEY>]
<vxlan-header> ::= (<ipv4-header> | <ipv6-header>)
[<VXLAN_IDENTIFIER>]
<nvgre-header> ::= (<ipv4-header> | <ipv6-header>)
<VIRTUAL_SUBNET_ID>
[<FLOW_ID>]
<gre-header> ::= <GRE_IP_DESTINATION> <GRE_PROTOCOL_TYPE> [<GRE_KEY>]
<vxlan-header> ::= (<ipv4-header> | <ipv6-header>)
[<VXLAN_IDENTIFIER>]
<nvgre-header> ::= (<ipv4-header> | <ipv6-header>)
<VIRTUAL_SUBNET_ID>
[<FLOW_ID>]
<tunnel-decapsulation> ::= ((<IPV4> <IPV4_DECAP> [<TTL_ACTION>]) |
(<IPV6> <IPV6_DECAP> [<HOP_LIMIT_ACTION>]) |
(<MPLS> <MPLS_POP> [<TTL_ACTION>]))
<tunnel-decapsulation> ::= ((<IPV4> <IPV4_DECAP> [<TTL_ACTION>]) |
(<IPV6> <IPV6_DECAP> [<HOP_LIMIT_ACTION>]) |
(<MPLS> <MPLS_POP> [<TTL_ACTION>]))
Figure 5: RIB rBNF Grammar
图5：RIB rBNF语法
A nexthop is used to specify the next network element to forward the traffic to. It is also used to specify how the traffic should be load-balanced, protected using preference, or multicast using replication. This is explicitly specified in the grammar. The nexthop has recursion built in to address complex use cases like the one defined in Section 7.2.6.
nexthop用于指定要将流量转发到的下一个网元。它还用于指定流量应如何进行负载平衡、使用首选项进行保护或使用复制进行多播。语法中明确规定了这一点。nexthop内置了递归，用于处理复杂的用例，如第7.2.6节中定义的用例。
The RIB grammar is very generic and covers a variety of features. This section provides examples on using objects in the RIB grammar and examples to program certain use cases.
肋骨语法非常通用，涵盖了多种功能。本节提供了在RIB语法中使用对象的示例，以及编写特定用例的示例。
Using route preference, a client can preinstall alternate paths in the network. For example, if OSPF has a route preference of 10, then another client can install a route with a route preference of 20 to the same destination. The OSPF route will get precedence and will get installed in the FIB. When the OSPF route is withdrawn, the alternate path will get installed in the FIB.
使用路由首选项，客户端可以在网络中预安装备用路径。例如，如果OSPF的路由首选项为10，则另一个客户端可以将路由首选项为20的路由安装到同一目的地。OSPF路由将获得优先权，并将安装在FIB中。当OSPF路由退出时，备用路径将安装在FIB中。
Route preference can also be used to prevent denial-of-service attacks by installing routes with the best preference, which either drops the offending traffic or routes it to some monitoring/analysis station. Since the routes are installed with the best preference, they will supersede any route installed by any other protocol.
路由首选项还可用于通过安装具有最佳首选项的路由来防止拒绝服务攻击，这会丢弃违规流量或将其路由到某个监视/分析站。由于路由是以最佳首选项安装的，因此它们将取代任何其他协议安装的任何路由。
The RIB grammar allows one to create a variety of nexthops. This section describes uses for certain types of nexthops.
肋骨语法允许人们创建各种下一步。本节介绍某些类型的Nexthop的使用。
A tunnel nexthop points to a tunnel of some kind. Traffic that goes over the tunnel gets encapsulated with the tunnel-encapsulation. Tunnel nexthops are useful for abstracting out details of the network by having the traffic seamlessly route between network edges. At the end of a tunnel, the tunnel will get decapsulated. Thus, the grammar supports two kinds of operations: one for encapsulation and another for decapsulation.
下一个隧道指向某种类型的隧道。通过隧道的流量将通过隧道封装进行封装。Tunnel nexthops通过在网络边缘之间无缝路由流量，有助于提取网络细节。在隧道末端，隧道将被解封。因此，语法支持两种操作：一种用于封装，另一种用于去封装。
One can create a replication list for replicating traffic to multiple destinations. The destinations, in turn, could be derived nexthops in themselves (at a level supported by the network device); point to multipoint and broadcast are examples that involve replication.
可以创建一个复制列表，用于将流量复制到多个目标。反过来，目的地本身可以派生出下一个目的地（在网络设备支持的级别上）；点对多点和广播是涉及复制的示例。
A replication list (at the simplest level) can be represented as:
复制列表（最简单的级别）可以表示为：
<nexthop> ::= <NEXTHOP_REPLICATE> <nexthop> [ <nexthop> ... ]
<nexthop> ::= <NEXTHOP_REPLICATE> <nexthop> [ <nexthop> ... ]
The above can be derived from the grammar as follows:
上述内容可从以下语法中派生：
<nexthop> ::= <nexthop-replicate>
<nexthop> ::= <NEXTHOP_REPLICATE> <nexthop> <nexthop> ...
<nexthop> ::= <nexthop-replicate>
<nexthop> ::= <NEXTHOP_REPLICATE> <nexthop> <nexthop> ...
A weighted list is used to load-balance traffic among a set of nexthops. From a modeling perspective, a weighted list is very similar to a replication list, with the difference that each member nexthop MUST have a NEXTHOP_LB_WEIGHT associated with it.
加权列表用于负载平衡一组下一个端口之间的流量。从建模的角度来看，加权列表与复制列表非常相似，不同之处在于每个成员nexthop必须有一个与之关联的nexthop_LB_权重。
A weighted list (at the simplest level) can be represented as:
加权列表（在最简单的级别）可以表示为：
<nexthop> ::= <NEXTHOP_LOAD_BALANCE> (<nexthop> <NEXTHOP_LB_WEIGHT>)
[(<nexthop> <NEXTHOP_LB_WEIGHT>)... ]
<nexthop> ::= <NEXTHOP_LOAD_BALANCE> (<nexthop> <NEXTHOP_LB_WEIGHT>)
[(<nexthop> <NEXTHOP_LB_WEIGHT>)... ]
The above can be derived from the grammar as follows:
上述内容可从以下语法中派生：
<nexthop> ::= <nexthop-lb>
<nexthop> ::= <NEXTHOP_LOAD_BALANCE>
<NEXTHOP_LB_WEIGHT> <nexthop>
(<NEXTHOP_LB_WEIGHT> <nexthop>) ...
<nexthop> ::= <NEXTHOP_LOAD_BALANCE> (<NEXTHOP_LB_WEIGHT> <nexthop>)
(<NEXTHOP_LB_WEIGHT> <nexthop>) ...
<nexthop> ::= <nexthop-lb>
<nexthop> ::= <NEXTHOP_LOAD_BALANCE>
<NEXTHOP_LB_WEIGHT> <nexthop>
(<NEXTHOP_LB_WEIGHT> <nexthop>) ...
<nexthop> ::= <NEXTHOP_LOAD_BALANCE> (<NEXTHOP_LB_WEIGHT> <nexthop>)
(<NEXTHOP_LB_WEIGHT> <nexthop>) ...
A primary/backup protection can be represented as:
主/备份保护可以表示为：
<nexthop> ::= <NEXTHOP_PROTECTION> <1> <interface-primary>
<2> <interface-backup>)
<nexthop> ::= <NEXTHOP_PROTECTION> <1> <interface-primary>
<2> <interface-backup>)
The above can be derived from the grammar as follows:
上述内容可从以下语法中派生：
<nexthop> ::= <nexthop-protection>
<nexthop> ::= <NEXTHOP_PROTECTION> (<NEXTHOP_PREFERENCE> <nexthop>
(<NEXTHOP_PREFERENCE> <nexthop>)...)
<nexthop> ::= <NEXTHOP_PROTECTION> (<NEXTHOP_PREFERENCE> <nexthop>
(<NEXTHOP_PREFERENCE> <nexthop>))
<nexthop> ::= <NEXTHOP_PROTECTION> ((<NEXTHOP_PREFERENCE> <nexthop-base>
(<NEXTHOP_PREFERENCE> <nexthop-base>))
<nexthop> ::= <NEXTHOP_PROTECTION> (<1> <interface-primary>
(<2> <interface-backup>))
<nexthop> ::= <nexthop-protection>
<nexthop> ::= <NEXTHOP_PROTECTION> (<NEXTHOP_PREFERENCE> <nexthop>
(<NEXTHOP_PREFERENCE> <nexthop>)...)
<nexthop> ::= <NEXTHOP_PROTECTION> (<NEXTHOP_PREFERENCE> <nexthop>
(<NEXTHOP_PREFERENCE> <nexthop>))
<nexthop> ::= <NEXTHOP_PROTECTION> ((<NEXTHOP_PREFERENCE> <nexthop-base>
(<NEXTHOP_PREFERENCE> <nexthop-base>))
<nexthop> ::= <NEXTHOP_PROTECTION> (<1> <interface-primary>
(<2> <interface-backup>))
Traffic can be load-balanced among multiple primary nexthops and a single backup. In such a case, the nexthop will look like:
流量可以在多个主nexthop和单个备份之间进行负载平衡。在这种情况下，下一步将如下所示：
<nexthop> ::= <NEXTHOP_PROTECTION> (<1>
(<NEXTHOP_LOAD_BALANCE>
(<NEXTHOP_LB_WEIGHT> <nexthop-base>
(<NEXTHOP_LB_WEIGHT> <nexthop-base>) ...))
<2> <nexthop-base>)
<nexthop> ::= <NEXTHOP_PROTECTION> (<1>
(<NEXTHOP_LOAD_BALANCE>
(<NEXTHOP_LB_WEIGHT> <nexthop-base>
(<NEXTHOP_LB_WEIGHT> <nexthop-base>) ...))
<2> <nexthop-base>)
A backup can also have another backup. In such a case, the list will look like:
一个备份也可以有另一个备份。在这种情况下，列表如下所示：
<nexthop> ::= <NEXTHOP_PROTECTION> (<1> <nexthop>
<2> <NEXTHOP_PROTECTION>(<1> <nexthop> <2> <nexthop>))
<nexthop> ::= <NEXTHOP_PROTECTION> (<1> <nexthop>
<2> <NEXTHOP_PROTECTION>(<1> <nexthop> <2> <nexthop>))
A nexthop chain is a way to perform multiple operations on a packet by logically combining them. For example, when a VPN packet comes on the WAN interface and has to be forwarded to the correct VPN interface, one needs to pop the VPN label before sending the packet out. Using a nexthop chain, one can chain together "pop MPLS header" and "send it out a specific egress-interface".
nexthop链是通过逻辑组合对数据包执行多个操作的一种方法。例如，当VPN数据包出现在WAN接口上并且必须转发到正确的VPN接口时，需要在发送数据包之前弹出VPN标签。使用nexthop链，可以将“pop-MPLS头”和“发送到特定的出口接口”链接在一起。
The above example can be derived from the grammar as follows:
上述示例可以从语法中派生，如下所示：
<nexthop-chain> ::= <nexthop> <nexthop>
<nexthop-chain> ::= <nexthop-base> <nexthop-base>
<nexthop-chain> ::= <tunnel-decapsulation> <egress-interface>
<nexthop-chain> ::= (<MPLS> <MPLS_POP>) <interface-outgoing>
<nexthop-chain> ::= <nexthop> <nexthop>
<nexthop-chain> ::= <nexthop-base> <nexthop-base>
<nexthop-chain> ::= <tunnel-decapsulation> <egress-interface>
<nexthop-chain> ::= (<MPLS> <MPLS_POP>) <interface-outgoing>
Elements in a nexthop chain are evaluated left to right.
下一个THOP链中的元素从左到右求值。
A nexthop chain can also be used to put one or more headers on an outgoing packet. One example is a pseudowire, which is MPLS over some transport (MPLS or GRE, for instance). Another example is Virtual eXtensible Local Area Network (VXLAN) over IP. A nexthop chain thus allows a RIB client to break up the programming of the nexthop into independent pieces (one per encapsulation).
nexthop链也可用于将一个或多个头放在传出数据包上。一个例子是伪线，它是一些传输上的MPLS（例如MPLS或GRE）。另一个例子是IP上的虚拟可扩展局域网（VXLAN）。因此，nexthop链允许RIB客户端将nexthop的编程分解为独立的部分（每个封装一个）。
A simple example of MPLS over GRE can be represented as follows:
GRE上的MPLS的一个简单示例可以表示为：
<nexthop-chain> ::= (<MPLS> <mpls-header>) (<GRE> <gre-header>)
<interface-outgoing>
<nexthop-chain> ::= (<MPLS> <mpls-header>) (<GRE> <gre-header>)
<interface-outgoing>
The above can be derived from the grammar as follows:
上述内容可从以下语法中派生：
<nexthop-chain> ::= <nexthop> <nexthop> <nexthop>
<nexthop-chain> ::= <nexthop-base> <nexthop-base> <nexthop-base>
<nexthop-chain> ::= <tunnel-encapsulation> <tunnel-encapsulation>
<egress-interface>
<nexthop-chain> ::= (<MPLS> <mpls-header>) (<GRE> <gre-header>)
<interface-outgoing>
<nexthop-chain> ::= <nexthop> <nexthop> <nexthop>
<nexthop-chain> ::= <nexthop-base> <nexthop-base> <nexthop-base>
<nexthop-chain> ::= <tunnel-encapsulation> <tunnel-encapsulation>
<egress-interface>
<nexthop-chain> ::= (<MPLS> <mpls-header>) (<GRE> <gre-header>)
<interface-outgoing>
Lists of lists is a derived construct. One example of usage of such a construct is to replicate traffic to multiple destinations with load-balancing. In other words, for each branch of the replication tree, there are multiple interfaces on which traffic needs to be load-balanced. So, the outer list is a replication list for multicast and the inner lists are weighted lists for load-balancing. Let's take an example of a network element that has to replicate traffic to two other network elements. Traffic to the first network element should be load-balanced equally over two interfaces: outgoing-1-1 and outgoing-1-2. Traffic to the second network element should be load-balanced over three interfaces: outgoing-2-1, outgoing-2-2, and outgoing-2-3 (in the ratio 20:20:60).
列表列表是一个派生的构造。使用这种构造的一个示例是通过负载平衡将流量复制到多个目的地。换句话说，对于复制树的每个分支，都有多个接口，需要在这些接口上实现负载平衡。因此，外部列表是用于多播的复制列表，内部列表是用于负载平衡的加权列表。让我们以一个网元为例，该网元必须将流量复制到另外两个网元。第一个网元的流量应在两个接口上均衡负载：outing-1-1和outing-1-2。到第二个网元的流量应通过三个接口进行负载平衡：outgoing-2-1、outgoing-2-2和outgoing-2-3（比例为20:20:60）。
This can be derived from the grammar as follows:
这可以从语法中派生，如下所示：
<nexthop> ::= <nexthop-replicate>
<nexthop> ::= <NEXTHOP_REPLICATE> (<nexthop> <nexthop>...)
<nexthop> ::= <NEXTHOP_REPLICATE> (<nexthop> <nexthop>)
<nexthop> ::= <NEXTHOP_REPLICATE> ((<NEXTHOP_LOAD_BALANCE> <nexthop-lb>)
(<NEXTHOP_LOAD_BALANCE> <nexthop-lb>))
<nexthop> ::= <NEXTHOP_REPLICATE> ((<NEXTHOP_LOAD_BALANCE>
(<NEXTHOP_LB_WEIGHT> <nexthop>
(<NEXTHOP_LB_WEIGHT> <nexthop>) ...))
((<NEXTHOP_LOAD_BALANCE>
(<NEXTHOP_LB_WEIGHT> <nexthop>
(<NEXTHOP_LB_WEIGHT> <nexthop>) ...))
<nexthop> ::= <NEXTHOP_REPLICATE> ((<NEXTHOP_LOAD_BALANCE>
(<NEXTHOP_LB_WEIGHT> <nexthop>
(<NEXTHOP_LB_WEIGHT> <nexthop>)))
((<NEXTHOP_LOAD_BALANCE>
(<NEXTHOP_LB_WEIGHT> <nexthop>
(<NEXTHOP_LB_WEIGHT> <nexthop>)
(<NEXTHOP_LB_WEIGHT> <nexthop>)))
<nexthop> ::= <NEXTHOP_REPLICATE> ((<NEXTHOP_LOAD_BALANCE>
(<NEXTHOP_LB_WEIGHT> <nexthop>)
(<NEXTHOP_LB_WEIGHT> <nexthop>)))
((<NEXTHOP_LOAD_BALANCE>
(<NEXTHOP_LB_WEIGHT> <nexthop>)
(<NEXTHOP_LB_WEIGHT> <nexthop>)
(<NEXTHOP_LB_WEIGHT> <nexthop>)))
<nexthop> ::= <NEXTHOP_REPLICATE>
((<NEXTHOP_LOAD_BALANCE>
(50 <outgoing-1-1>)
(50 <outgoing-1-2>)))
((<NEXTHOP_LOAD_BALANCE>
(20 <outgoing-2-1>)
(20 <outgoing-2-2>)
(60 <outgoing-2-3>)))
<nexthop> ::= <nexthop-replicate>
<nexthop> ::= <NEXTHOP_REPLICATE> (<nexthop> <nexthop>...)
<nexthop> ::= <NEXTHOP_REPLICATE> (<nexthop> <nexthop>)
<nexthop> ::= <NEXTHOP_REPLICATE> ((<NEXTHOP_LOAD_BALANCE> <nexthop-lb>)
(<NEXTHOP_LOAD_BALANCE> <nexthop-lb>))
<nexthop> ::= <NEXTHOP_REPLICATE> ((<NEXTHOP_LOAD_BALANCE>
(<NEXTHOP_LB_WEIGHT> <nexthop>
(<NEXTHOP_LB_WEIGHT> <nexthop>) ...))
((<NEXTHOP_LOAD_BALANCE>
(<NEXTHOP_LB_WEIGHT> <nexthop>
(<NEXTHOP_LB_WEIGHT> <nexthop>) ...))
<nexthop> ::= <NEXTHOP_REPLICATE> ((<NEXTHOP_LOAD_BALANCE>
(<NEXTHOP_LB_WEIGHT> <nexthop>
(<NEXTHOP_LB_WEIGHT> <nexthop>)))
((<NEXTHOP_LOAD_BALANCE>
(<NEXTHOP_LB_WEIGHT> <nexthop>
(<NEXTHOP_LB_WEIGHT> <nexthop>)
(<NEXTHOP_LB_WEIGHT> <nexthop>)))
<nexthop> ::= <NEXTHOP_REPLICATE> ((<NEXTHOP_LOAD_BALANCE>
(<NEXTHOP_LB_WEIGHT> <nexthop>)
(<NEXTHOP_LB_WEIGHT> <nexthop>)))
((<NEXTHOP_LOAD_BALANCE>
(<NEXTHOP_LB_WEIGHT> <nexthop>)
(<NEXTHOP_LB_WEIGHT> <nexthop>)
(<NEXTHOP_LB_WEIGHT> <nexthop>)))
<nexthop> ::= <NEXTHOP_REPLICATE>
((<NEXTHOP_LOAD_BALANCE>
(50 <outgoing-1-1>)
(50 <outgoing-1-2>)))
((<NEXTHOP_LOAD_BALANCE>
(20 <outgoing-2-1>)
(20 <outgoing-2-2>)
(60 <outgoing-2-3>)))
IP multicast involves matching a packet on (S,G) or (*,G), where both S (Source) and G (Group) are IP prefixes. Following the match, the packet is replicated to one or more recipients. How the recipients subscribe to the multicast group is outside the scope of this document.
IP多播涉及匹配（S，G）或（*，G）上的数据包，其中S（源）和G（组）都是IP前缀。匹配后，数据包被复制到一个或多个收件人。收件人订阅多播组的方式超出了本文档的范围。
In PIM-based multicast, the packets are IP forwarded on an IP multicast tree. The downstream nodes on each point in the multicast tree are one or more IP addresses. These can be represented as a replication list (see Section 7.2.2).
在基于PIM的多播中，数据包在IP多播树上进行IP转发。多播树中每个点上的下游节点是一个或多个IP地址。这些可以表示为复制列表（参见第7.2.2节）。
In MPLS-based multicast, the packets are forwarded on a Point-to-Multipoint (P2MP) LSP. The nexthop for a P2MP LSP can be represented in the nexthop grammar as a <logical-tunnel> (P2MP LSP identifier) or a replication list (see Section 7.2.2) of <tunnel-encapsulation>, with each tunnel-encapsulation representing a single MPLS downstream nexthop.
在基于MPLS的多播中，数据包在点对多点（P2MP）LSP上转发。P2MP LSP的nexthop可以在nexthop语法中表示为<logical tunnel>（P2MP LSP标识符）或<tunnel enclosuration>的复制列表（参见第7.2.2节），每个隧道封装表示一个MPLS下游nexthop。
This section discusses the scale requirements for a RIB data model. The RIB data model should be able to handle a large scale of operations to enable deployment of RIB applications in large networks.
本节讨论了RIB数据模型的比例要求。RIB数据模型应能够处理大规模操作，以便在大型网络中部署RIB应用程序。
Bulking (grouping of multiple objects in a single message) MUST be supported when a network device sends RIB data to a RIB client. Similarly, the data model MUST enable a RIB client to request data in bulk from a network device.
当网络设备向RIB客户端发送RIB数据时，必须支持扩展（在单个消息中对多个对象进行分组）。类似地，数据模型必须使RIB客户端能够从网络设备批量请求数据。
Bulking (grouping of multiple write operations in a single message) MUST be supported when a RIB client wants to write to the RIB. The response from the network device MUST include a return-code for each write operation in the bulk message.
当RIB客户端希望写入RIB时，必须支持批量（在单个消息中对多个写入操作进行分组）。来自网络设备的响应必须包括批量消息中每个写入操作的返回码。
There can be cases where a single network event results in multiple events and/or notifications from the network device to a RIB client. On the other hand, due to timing of multiple things happening at the same time, a network device might have to send multiple events and/or notifications to a RIB client. The network-device-originated event/ notification message MUST support the bulking of multiple events and notifications in a single message.
在某些情况下，单个网络事件会导致从网络设备到RIB客户端的多个事件和/或通知。另一方面，由于同时发生多个事件的定时，网络设备可能必须向RIB客户端发送多个事件和/或通知。源自网络设备的事件/通知消息必须支持在单个消息中扩展多个事件和通知。
The information model specified in this document defines a schema for data models that are designed to be accessed via network management protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS [RFC8446].
本文档中指定的信息模型定义了数据模型的模式，这些数据模型设计为通过网络管理协议（如NETCONF[RFC6241]或RESTCONF[RFC8040]）访问。最低的NETCONF层是安全传输层，实现安全传输的强制要求是安全Shell（SSH）[RFC6242]。最低的RESTCONF层是HTTPS，实现安全传输的强制层是TLS[RFC8446]。
The NETCONF access control model [RFC8341] provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content.
NETCONF访问控制模型[RFC8341]提供了将特定NETCONF或RESTCONF用户的访问限制为所有可用NETCONF或RESTCONF协议操作和内容的预配置子集的方法。
The RIB information model specifies read and write operations to network devices. These network devices might be considered sensitive or vulnerable in some network environments. Write operations to these network devices without proper protection can have a negative effect on network operations. Due to this factor, it is recommended that data models also consider the following in their design:
RIB信息模型指定对网络设备的读写操作。在某些网络环境中，这些网络设备可能被视为敏感或易受攻击。在没有适当保护的情况下对这些网络设备执行写操作可能会对网络操作产生负面影响。由于这个因素，建议数据模型也考虑以下在他们的设计中：
o Require utilization of the authentication and authorization features of the NETCONF or RESTCONF suite of protocols.
o 需要利用NETCONF或RESTCONF协议套件的身份验证和授权功能。
o Augment the limits on how much data can be written or updated by a remote entity built to include enough protection for a RIB data model.
o 增加远程实体可以写入或更新的数据量限制，远程实体的构建为RIB数据模型提供足够的保护。
o Expose the specific RIB data model implemented via NETCONF/ RESTCONF data models.
o 公开通过NETCONF/RESTCONF数据模型实现的特定RIB数据模型。
This document has no IANA actions.
本文档没有IANA操作。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, <https://www.rfc-editor.org/info/rfc6241>.
[RFC6241]Enns，R.，Ed.，Bjorklund，M.，Ed.，Schoenwaeld，J.，Ed.，和A.Bierman，Ed.，“网络配置协议（NETCONF）”，RFC 6241，DOI 10.17487/RFC6241，2011年6月<https://www.rfc-editor.org/info/rfc6241>.
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, <https://www.rfc-editor.org/info/rfc6242>.
[RFC6242]Wasserman，M.“在安全外壳上使用NETCONF协议（SSH）”，RFC 6242，DOI 10.17487/RFC6242，2011年6月<https://www.rfc-editor.org/info/rfc6242>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, <https://www.rfc-editor.org/info/rfc8040>.
[RFC8040]Bierman，A.，Bjorklund，M.，和K.Watsen，“RESTCONF协议”，RFC 8040，DOI 10.17487/RFC8040，2017年1月<https://www.rfc-editor.org/info/rfc8040>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration Access Control Model", STD 91, RFC 8341, DOI 10.17487/RFC8341, March 2018, <https://www.rfc-editor.org/info/rfc8341>.
[RFC8341]Bierman，A.和M.Bjorklund，“网络配置访问控制模型”，STD 91，RFC 8341，DOI 10.17487/RFC8341，2018年3月<https://www.rfc-editor.org/info/rfc8341>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.
[RFC8446]Rescorla，E.“传输层安全（TLS）协议版本1.3”，RFC 8446，DOI 10.17487/RFC8446，2018年8月<https://www.rfc-editor.org/info/rfc8446>.
[RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", RFC 4915, DOI 10.17487/RFC4915, June 2007, <https://www.rfc-editor.org/info/rfc4915>.
[RFC4915]Psenak，P.，Mirtorabi，S.，Roy，A.，Nguyen，L.，和P.Pillay Esnault，“OSPF中的多拓扑（MT）路由”，RFC 4915，DOI 10.17487/RFC4915，2007年6月<https://www.rfc-editor.org/info/rfc4915>.
[RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)", RFC 5120, DOI 10.17487/RFC5120, February 2008, <https://www.rfc-editor.org/info/rfc5120>.
[RFC5120]Przygienda，T.，Shen，N.，和N.Sheth，“M-ISIS：中间系统到中间系统（IS-ISs）的多拓扑（MT）路由”，RFC 5120，DOI 10.17487/RFC5120，2008年2月<https://www.rfc-editor.org/info/rfc5120>.
[RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax Used to Form Encoding Rules in Various Routing Protocol Specifications", RFC 5511, DOI 10.17487/RFC5511, April 2009, <https://www.rfc-editor.org/info/rfc5511>.
[RFC5511]Farrel，A.，“路由Backus-Naur形式（RBNF）：用于在各种路由协议规范中形成编码规则的语法”，RFC 5511，DOI 10.17487/RFC5511，2009年4月<https://www.rfc-editor.org/info/rfc5511>.
[RFC7920] Atlas, A., Ed., Nadeau, T., Ed., and D. Ward, "Problem Statement for the Interface to the Routing System", RFC 7920, DOI 10.17487/RFC7920, June 2016, <https://www.rfc-editor.org/info/rfc7920>.
[RFC7920]Atlas，A.，Ed.，Nadeau，T.，Ed.，和D.Ward，“路由系统接口问题声明”，RFC 7920，DOI 10.17487/RFC7920，2016年6月<https://www.rfc-editor.org/info/rfc7920>.
[RFC8431] Wang, L., Chen, M., Dass, A., Ananthakrishnan, H., Kini, S., and N. Bahadur, "A YANG Data Model for the Routing Information Base (RIB)", RFC 8431, DOI 10.17487/RFC8431, September 2018, <http://www.rfc-editor.org/info/rfc8431>.
[RFC8431]Wang，L.，Chen，M.，Dass，A.，Ananthakrishnan，H.，Kini，S.，和N.Bahadur，“路由信息库（RIB）的杨数据模型”，RFC 8431，DOI 10.17487/RFC8431，2018年9月<http://www.rfc-editor.org/info/rfc8431>.
Acknowledgements
致谢
The authors would like to thank Ron Folkes, Jeffrey Zhang, the WG co-Chairs, and reviewers for their comments and suggestions on this document. The following people contributed to the design of the RIB information model as part of the I2RS Interim meeting in April 2013:
作者要感谢Ron Folkes、Jeffrey Zhang、工作组联合主席和评审员对本文件的评论和建议。作为2013年4月I2RS临时会议的一部分，以下人员参与了RIB信息模型的设计：
Wes George, Chris Liljenstolpe, Jeff Tantsura, Susan Hares, and Fabian Schneider.
韦斯·乔治、克里斯·利延斯托尔佩、杰夫·坦特拉、苏珊·哈尔斯和费边·施耐德。
Authors' Addresses
作者地址
Nitin Bahadur (editor) Uber 900 Arastradero Rd Palo Alto, CA 94304 United States of America
Nitin Bahadur（编辑）Uber美国加利福尼亚州帕洛阿尔托市阿拉斯塔德罗路900号，邮编94304
Email: nitin_bahadur@yahoo.com
Email: nitin_bahadur@yahoo.com
Sriganesh Kini (editor)
斯里加内什·基尼（编辑）
Email: sriganeshkini@gmail.com
Email: sriganeshkini@gmail.com
Jan Medved Cisco
简·梅德维德·思科
Email: jmedved@cisco.com
Email: jmedved@cisco.com