Internet Engineering Task Force (IETF) L. Berger
Request for Comments: 8529 C. Hopps
Category: Standards Track LabN Consulting, L.L.C.
ISSN: 2070-1721 A. Lindem
Cisco Systems
D. Bogdanovic
X. Liu
Volta Networks
March 2019
Internet Engineering Task Force (IETF) L. Berger
Request for Comments: 8529 C. Hopps
Category: Standards Track LabN Consulting, L.L.C.
ISSN: 2070-1721 A. Lindem
Cisco Systems
D. Bogdanovic
X. Liu
Volta Networks
March 2019
YANG Data Model for Network Instances
网络实例的YANG数据模型
Abstract
摘要
This document defines a network instance module. This module can be used to manage the virtual resource partitioning that may be present on a network device. Examples of common industry terms for virtual resource partitioning are VPN Routing and Forwarding (VRF) instances and Virtual Switch Instances (VSIs).
本文档定义了一个网络实例模块。此模块可用于管理网络设备上可能存在的虚拟资源分区。虚拟资源分区的常见行业术语示例有VPN路由和转发（VRF）实例和虚拟交换机实例（VSI）。
The YANG data model in this document conforms to the Network Management Datastore Architecture (NMDA) defined in RFC 8342.
本文件中的YANG数据模型符合RFC 8342中定义的网络管理数据存储体系结构（NMDA）。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8529.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8529.
Copyright Notice
版权公告
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
版权（c）2019 IETF信托基金和被确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Network Instances . . . . . . . . . . . . . . . . . . . . . . 6
3.1. NI Types and Mount Points . . . . . . . . . . . . . . . . 7
3.1.1. Well-Known Mount Points . . . . . . . . . . . . . . . 8
3.1.2. NI Type Example . . . . . . . . . . . . . . . . . . . 9
3.2. NIs and Interfaces . . . . . . . . . . . . . . . . . . . 9
3.3. Network Instance Management . . . . . . . . . . . . . . . 11
3.4. Network Instance Instantiation . . . . . . . . . . . . . 14
4. Security Considerations . . . . . . . . . . . . . . . . . . . 14
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
6. Network Instance Model . . . . . . . . . . . . . . . . . . . 16
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
7.1. Normative References . . . . . . . . . . . . . . . . . . 22
7.2. Informative References . . . . . . . . . . . . . . . . . 23
Appendix A. Example NI Usage . . . . . . . . . . . . . . . . . . 25
A.1. Configuration Data . . . . . . . . . . . . . . . . . . . 25
A.2. State Data - Non-NMDA Version . . . . . . . . . . . . . . 28
A.3. State Data - NMDA Version . . . . . . . . . . . . . . . . 35
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 44
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Network Instances . . . . . . . . . . . . . . . . . . . . . . 6
3.1. NI Types and Mount Points . . . . . . . . . . . . . . . . 7
3.1.1. Well-Known Mount Points . . . . . . . . . . . . . . . 8
3.1.2. NI Type Example . . . . . . . . . . . . . . . . . . . 9
3.2. NIs and Interfaces . . . . . . . . . . . . . . . . . . . 9
3.3. Network Instance Management . . . . . . . . . . . . . . . 11
3.4. Network Instance Instantiation . . . . . . . . . . . . . 14
4. Security Considerations . . . . . . . . . . . . . . . . . . . 14
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
6. Network Instance Model . . . . . . . . . . . . . . . . . . . 16
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
7.1. Normative References . . . . . . . . . . . . . . . . . . 22
7.2. Informative References . . . . . . . . . . . . . . . . . 23
Appendix A. Example NI Usage . . . . . . . . . . . . . . . . . . 25
A.1. Configuration Data . . . . . . . . . . . . . . . . . . . 25
A.2. State Data - Non-NMDA Version . . . . . . . . . . . . . . 28
A.3. State Data - NMDA Version . . . . . . . . . . . . . . . . 35
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 44
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44
This document defines the second of two new modules that are defined to support the configuration and operation of network devices that allow for the partitioning of resources from both, or either, management and networking perspectives. Both leverage the YANG functionality enabled by YANG Schema Mount [RFC8528].
本文档定义了两个新模块中的第二个模块，它们被定义为支持网络设备的配置和操作，允许从管理和网络两个或其中一个角度对资源进行分区。两者都利用了YANG模式挂载[RFC8528]所启用的YANG功能。
The YANG data model in this document conforms to the Network Management Datastore Architecture defined in [RFC8342].
本文件中的YANG数据模型符合[RFC8342]中定义的网络管理数据存储体系结构。
The first form of resource partitioning provides a logical partitioning of a network device where each partition is separately managed as essentially an independent network element that is "hosted" by the base network device. These hosted network elements are referred to as logical network elements, or LNEs, and are supported by the logical-network-element module defined in [RFC8530]. That module is used to identify LNEs and associate resources from the network device with each LNE. LNEs themselves are represented in YANG as independent network devices; each is accessed independently. Examples of vendor terminology for an LNE include logical system or logical router and virtual switch, chassis, or fabric.
第一种形式的资源分区提供网络设备的逻辑分区，其中每个分区基本上作为独立的网元单独管理，该网元由基本网络设备“托管”。这些承载的网元称为逻辑网元或LNE，并由[RFC8530]中定义的逻辑网元模块支持。该模块用于识别LNE，并将来自网络设备的资源与每个LNE相关联。LNE本身在YANG中表示为独立的网络设备；每个都是独立访问的。LNE的供应商术语示例包括逻辑系统或逻辑路由器以及虚拟交换机、机箱或结构。
The second form, which is defined in this document, provides support for what are commonly referred to as VPN Routing and Forwarding (VRF) instances as well as Virtual Switch Instances (VSI); see [RFC4026] and [RFC4664]. In this form of resource partitioning, multiple control-plane and forwarding/bridging instances are provided by and managed through a single (physical or logical) network device. This form of resource partitioning is referred to as a Network Instance (NI) and is supported by the network instance module defined below. Configuration and operation of each network instance is always via the network device and the network instance module.
第二种形式（在本文档中定义）提供对通常称为VPN路由和转发（VRF）实例以及虚拟交换机实例（VSI）的支持；参见[RFC4026]和[RFC4664]。在这种形式的资源分区中，多个控制平面和转发/桥接实例由单个（物理或逻辑）网络设备提供和管理。这种形式的资源分区称为网络实例（NI），由下面定义的网络实例模块支持。每个网络实例的配置和操作始终通过网络设备和网络实例模块进行。
One notable difference between the LNE model and the NI model is that the NI model provides a framework for VRF and VSI management. This document envisions the separate definition of models specific to VRF and VSI -- i.e., L3 and L2 VPN -- technology. An example of such can be found in the emerging L3VPN model defined in [YANG-L3VPN] and the examples discussed below.
LNE模型和NI模型之间的一个显著区别是，NI模型为VRF和VSI管理提供了一个框架。本文档设想了特定于VRF和VSI（即L3和L2 VPN）技术的模型的单独定义。在[YANG-L3VPN]中定义的新兴L3VPN模型和下面讨论的示例中可以找到此类示例。
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]所述进行解释。
Readers are expected to be familiar with terms and concepts of YANG [RFC7950] and YANG Schema Mount [RFC8528].
读者应熟悉YANG[RFC7950]和YANG Schema Mount[RFC8528]的术语和概念。
This document uses the graphical representation of data models defined in [RFC8340].
本文件使用[RFC8340]中定义的数据模型的图形表示。
In this document, we consider network devices that support protocols and functions defined within the IETF -- e.g., routers, firewalls, and hosts. Such devices may be physical or virtual, e.g., a classic router with custom hardware or one residing within a server-based virtual machine implementing a virtual network function (VNF). Each device may subdivide their resources into logical network elements (LNEs), each of which provides a managed logical device. Examples of vendor terminology for an LNE include logical system or logical router and virtual switch, chassis, or fabric. Each LNE may also support VRF and VSI functions, which are referred to below as network instances (NIs). This breakdown is represented in Figure 1.
在本文中，我们考虑支持IETF内定义的协议和功能的网络设备，例如路由器、防火墙和主机。此类设备可以是物理的或虚拟的，例如，具有定制硬件的经典路由器或驻留在实现虚拟网络功能（VNF）的基于服务器的虚拟机内的路由器。每个设备可以将其资源细分为逻辑网元（LNE），每个逻辑网元提供一个受管逻辑设备。LNE的供应商术语示例包括逻辑系统或逻辑路由器以及虚拟交换机、机箱或结构。每个LNE还可以支持VRF和VSI功能，以下称为网络实例（NIs）。这一细分如图1所示。
,''''''''''''''''''''''''''''''''''''''''''''''`.
| Network Device (Physical or Virtual) |
| ..................... ..................... |
| : Logical Network : : Logical Network : |
| : Element : : Element : |
| :+-----+-----+-----+: :+-----+-----+-----+: |
| :| Net | Net | Net |: :| Net | Net | Net |: |
| :|Inst.|Inst.|Inst.|: :|Inst.|Inst.|Inst.|: |
| :+-----+-----+-----+: :+-----+-----+-----+: |
| : | | | | | | : : | | | | | | : |
| :..|.|...|.|...|.|..: :..|.|...|.|...|.|..: |
| | | | | | | | | | | | | |
`'''|'|'''|'|'''|'|'''''''''|'|'''|'|'''|'|'''''
| | | | | | | | | | | |
Interfaces Interfaces
,''''''''''''''''''''''''''''''''''''''''''''''`.
| Network Device (Physical or Virtual) |
| ..................... ..................... |
| : Logical Network : : Logical Network : |
| : Element : : Element : |
| :+-----+-----+-----+: :+-----+-----+-----+: |
| :| Net | Net | Net |: :| Net | Net | Net |: |
| :|Inst.|Inst.|Inst.|: :|Inst.|Inst.|Inst.|: |
| :+-----+-----+-----+: :+-----+-----+-----+: |
| : | | | | | | : : | | | | | | : |
| :..|.|...|.|...|.|..: :..|.|...|.|...|.|..: |
| | | | | | | | | | | | | |
`'''|'|'''|'|'''|'|'''''''''|'|'''|'|'''|'|'''''
| | | | | | | | | | | |
Interfaces Interfaces
Figure 1: Module Element Relationships
图1：模块元素关系
A model for LNEs is described in [RFC8530], and the model for NIs is covered in Section 3 of this document.
[RFC8530]中描述了LNE的模型，本文件第3节介绍了NIs的模型。
The current interface management model [RFC8343] is impacted by the definition of LNEs and NIs. This document and [RFC8530] define augmentations to the interface module to support LNEs and NIs.
当前接口管理模型[RFC8343]受LNE和NIs定义的影响。本文档和[RFC8530]定义了接口模块的扩充，以支持LNE和NIs。
The network instance model supports the configuration of VRFs and VSIs. Each instance is supported by information that relates to the device -- for example, the route target used when advertising VRF routes via the mechanisms defined in [RFC4364], and information that relates to the internal operation of the NI, such as for routing protocols [RFC8349] and OSPF [YANG-OSPF]. This document defines the network instance module that provides a basis for the management of both types of information.
网络实例模型支持VRFs和VSIs的配置。每个实例都由与设备相关的信息支持——例如，通过[RFC4364]中定义的机制宣传VRF路由时使用的路由目标，以及与NI内部操作相关的信息，例如路由协议[RFC8349]和OSPF[YANG-OSPF]。本文档定义了网络实例模块，该模块为管理这两种类型的信息提供了基础。
NI information that relates to the device, including the assignment of interfaces to NIs, is defined as part of this document. The defined module also provides a placeholder for the definition of NI-technology-specific information both at the device level and for NI internal operation. Information related to NI internal operation is supported via schema mount [RFC8528] and mounting appropriate modules under the mount point. Well-known mount points are defined for L3VPN, L2VPN, and L2+L3VPN NI types.
与设备相关的NI信息（包括NIs接口分配）定义为本文件的一部分。定义的模块还提供了一个占位符，用于在设备级别和NI内部操作中定义NI技术特定信息。通过模式装载[RFC8528]和在装载点下装载适当的模块，支持与NI内部操作相关的信息。为L3VPN、L2VPN和L2+L3VPN NI类型定义了众所周知的装载点。
The network instance container is used to represent VRFs and VSIs. VRFs and VSIs are commonly used to isolate routing and switching domains -- for example, to create virtual private networks, each with their own active protocols and routing/switching policies. The model supports both core/provider and virtual instances. Core/provider instance information is accessible at the top level of the server, while virtual instance information is accessible under the root schema mount points.
网络实例容器用于表示VRF和VSI。VRFs和VSI通常用于隔离路由和交换域——例如，创建虚拟专用网络，每个网络都有自己的活动协议和路由/交换策略。该模型支持核心/提供程序和虚拟实例。核心/提供程序实例信息可在服务器的顶层访问，而虚拟实例信息可在根架构装载点下访问。
module: ietf-network-instance
+--rw network-instances
+--rw network-instance* [name]
+--rw name string
+--rw enabled? boolean
+--rw description? string
+--rw (ni-type)?
+--rw (root-type)
+--:(vrf-root)
| +--mp vrf-root
+--:(vsi-root)
| +--mp vsi-root
+--:(vv-root)
+--mp vv-root
augment /if:interfaces/if:interface:
+--rw bind-ni-name? -> /network-instances/network-instance/name
augment /if:interfaces/if:interface/ip:ipv4:
+--rw bind-ni-name? -> /network-instances/network-instance/name
augment /if:interfaces/if:interface/ip:ipv6:
+--rw bind-ni-name? -> /network-instances/network-instance/name
module: ietf-network-instance
+--rw network-instances
+--rw network-instance* [name]
+--rw name string
+--rw enabled? boolean
+--rw description? string
+--rw (ni-type)?
+--rw (root-type)
+--:(vrf-root)
| +--mp vrf-root
+--:(vsi-root)
| +--mp vsi-root
+--:(vv-root)
+--mp vv-root
augment /if:interfaces/if:interface:
+--rw bind-ni-name? -> /network-instances/network-instance/name
augment /if:interfaces/if:interface/ip:ipv4:
+--rw bind-ni-name? -> /network-instances/network-instance/name
augment /if:interfaces/if:interface/ip:ipv6:
+--rw bind-ni-name? -> /network-instances/network-instance/name
notifications:
+---n bind-ni-name-failed
+--ro name -> /if:interfaces/interface/name
+--ro interface
| +--ro bind-ni-name?
| -> /if:interfaces/interface/ni:bind-ni-name
+--ro ipv4
| +--ro bind-ni-name?
| -> /if:interfaces/interface/ip:ipv4/ni:bind-ni-name
+--ro ipv6
| +--ro bind-ni-name?
| -> /if:interfaces/interface/ip:ipv6/ni:bind-ni-name
+--ro error-info? string
notifications:
+---n bind-ni-name-failed
+--ro name -> /if:interfaces/interface/name
+--ro interface
| +--ro bind-ni-name?
| -> /if:interfaces/interface/ni:bind-ni-name
+--ro ipv4
| +--ro bind-ni-name?
| -> /if:interfaces/interface/ip:ipv4/ni:bind-ni-name
+--ro ipv6
| +--ro bind-ni-name?
| -> /if:interfaces/interface/ip:ipv6/ni:bind-ni-name
+--ro error-info? string
A network instance is identified by a "name" string. This string is used both as an index within the network instance module and to associate resources with a network instance, as shown above in the interface augmentation. The ni-type and root-type choice statements are used to support different types of L2 and L3 VPN technologies. The bind-ni-name-failed notification is used in certain failure cases.
网络实例由“名称”字符串标识。此字符串既用作网络实例模块内的索引，又用于将资源与网络实例关联，如上面的接口扩充中所示。ni类型和根类型选择语句用于支持不同类型的L2和L3 VPN技术。bind ni name failed通知用于某些故障情况。
The network instance module is structured to facilitate the definition of information models for specific types of VRFs and VSIs using augmentations. For example, the information needed to support L2VPN, such as VPLS and EVPN, are likely to be quite different. Example models under development that could be restructured to take advantage on NIs include models for L3VPNs [YANG-L3VPN] and L2VPNs [YANG-L2VPN].
网络实例模块的结构便于使用扩展为特定类型的VRF和VSI定义信息模型。例如，支持L2VPN所需的信息，如VPLS和EVPN，可能会有很大不同。开发中的示例模型可以进行重组以利用NIs，包括L3VPN[YANG-L3VPN]和L2VPN[YANG-L2VPN]的模型。
Documents defining new YANG data models for the support of specific types of network instances should augment the network instance module. The basic structure that should be used for such augmentations includes a case statement with containers for configuration and state data and, when needed, a type-specific mount point. Generally, NI types are expected to not need to define type-specific mount points but rather reuse one of the well-known mount points, as defined in the next section. The following is an example type-specific augmentation:
为支持特定类型的网络实例而定义新数据模型的文档应扩展网络实例模块。这种扩充应该使用的基本结构包括一个case语句，其中包含用于配置和状态数据的容器，必要时还包括一个特定于类型的装入点。通常，NI类型不需要定义特定于类型的装入点，而是重用一个众所周知的装入点，如下一节中所定义。以下是特定于类型的扩充示例：
augment "/ni:network-instances/ni:network-instance/ni:ni-type" {
case l3vpn {
container l3vpn {
...
}
container l3vpn-state {
...
}
}
}
augment "/ni:network-instances/ni:network-instance/ni:ni-type" {
case l3vpn {
container l3vpn {
...
}
container l3vpn-state {
...
}
}
}
YANG Schema Mount [RFC8528] identifies mount points by name within a module. This definition allows for the definition of mount points whose schema can be shared across NI types. As discussed above, ni-types largely differ in the configuration information needed in the core/top-level instance to support the NI, rather than in the information represented within an NI. This allows the use of shared mount points across certain NI types.
模式装载[RFC8528]通过模块内的名称标识装载点。此定义允许定义其架构可以跨NI类型共享的装载点。如上所述，ni类型在支持ni所需的核心/顶级实例中的配置信息，而不是在ni中表示的信息方面，有很大的不同。这允许跨某些NI类型使用共享装载点。
The expectation is that there are actually very few different schemas that need to be defined to support NIs for an implementation. In particular, it is expected that the following three forms of NI schema are needed, and each can be defined with a well-known mount point that can be reused by future modules defining NI types.
我们的期望是，实际上很少有不同的模式需要定义来支持NIs的实现。特别是，预计需要以下三种形式的NI模式，并且每种形式都可以使用一个众所周知的挂载点来定义，该挂载点可以被定义NI类型的未来模块重用。
The three well-known mount points are:
三个著名的安装点是：
vrf-root vrf-root is intended for use with L3VPN-type NI types.
vrf根vrf根用于L3VPN类型NI类型。
vsi-root vsi-root is intended for use with L2VPN-type Ni types.
vsi根vsi根用于L2VPN类型Ni类型。
vv-root vv-root is intended for use with NI types that simultaneously support L2VPN bridging and L3VPN routing capabilities.
vv根vv根用于同时支持L2VPN桥接和L3VPN路由功能的NI类型。
Future model definitions should use the above mount points whenever possible. When a well-known mount point isn't appropriate, a model may define a type-specific mount point via augmentation.
未来的模型定义应尽可能使用上述装载点。当一个众所周知的挂载点不合适时，一个模型可以通过扩充定义一个特定于类型的挂载点。
The following is an example of an L3VPN VRF using a hypothetical augmentation to the network instance schema defined in [YANG-L3VPN]. More detailed examples can be found in Appendix A.
以下是L3VPN VRF的示例，该VRF使用[YANG-L3VPN]中定义的网络实例模式的假设扩充。更多详细示例见附录A。
module: ietf-network-instance
+--rw network-instances
+--rw network-instance* [name]
+--rw name string
+--rw enabled? boolean
+--rw description? string
+--rw (ni-type)?
| +--:(l3vpn)
| +--rw l3vpn:l3vpn
| | ... // config data
| +--ro l3vpn:l3vpn-state
| | ... // state data
+--rw (root-type)
+--:(vrf-root)
+--mp vrf-root
+--rw rt:routing/
| +--rw router-id? yang:dotted-quad
| +--rw control-plane-protocols
| +--rw control-plane-protocol* [type name]
| +--rw ospf:ospf
| +--rw area* [area-id]
| +--rw interfaces
| +--rw interface* [name]
| +--rw name if:interface-ref
| +--rw cost? uint16
+--ro if:interfaces@
| ...
module: ietf-network-instance
+--rw network-instances
+--rw network-instance* [name]
+--rw name string
+--rw enabled? boolean
+--rw description? string
+--rw (ni-type)?
| +--:(l3vpn)
| +--rw l3vpn:l3vpn
| | ... // config data
| +--ro l3vpn:l3vpn-state
| | ... // state data
+--rw (root-type)
+--:(vrf-root)
+--mp vrf-root
+--rw rt:routing/
| +--rw router-id? yang:dotted-quad
| +--rw control-plane-protocols
| +--rw control-plane-protocol* [type name]
| +--rw ospf:ospf
| +--rw area* [area-id]
| +--rw interfaces
| +--rw interface* [name]
| +--rw name if:interface-ref
| +--rw cost? uint16
+--ro if:interfaces@
| ...
This shows YANG Routing Management [RFC8349] and YANG OSPF [YANG-OSPF] as mounted modules. The mounted modules can reference interface information via a parent-reference to the containers defined in [RFC8343].
这将YANG路由管理[RFC8349]和YANG OSPF[YANG-OSPF]显示为安装的模块。安装的模块可以通过[RFC8343]中定义的容器的父引用来引用接口信息。
Interfaces are a crucial part of any network device's configuration and operational state. They generally include a combination of raw physical interfaces, link-layer interfaces, addressing configuration, and logical interfaces that may not be tied to any physical interface. Several system services and Layer 2 and Layer 3 protocols
接口是任何网络设备配置和操作状态的关键部分。它们通常包括原始物理接口、链路层接口、寻址配置和可能不绑定到任何物理接口的逻辑接口的组合。多个系统服务和第2层和第3层协议
may also associate configuration or operational state data with different types of interfaces (these relationships are not shown for simplicity). The interface management model is defined by [RFC8343].
还可以将配置或操作状态数据与不同类型的接口相关联（为简单起见，未显示这些关系）。接口管理模型由[RFC8343]定义。
As shown below, the network instance module augments the existing interface management model by adding a name that is used on interface or sub-interface types to identify an associated network instance. Similarly, this name is also added for IPv4 and IPv6 types, as defined in [RFC8344].
如下图所示，网络实例模块通过添加用于接口或子接口类型以标识关联网络实例的名称来扩充现有接口管理模型。类似地，此名称也为IPv4和IPv6类型添加，如[RFC8344]中所定义。
The following is an example of envisioned usage. The interfaces container includes a number of commonly used components as examples:
以下是预期用途的示例。接口容器包括许多常用组件，例如：
module: ietf-interfaces
+--rw interfaces
| +--rw interface* [name]
| +--rw name string
| +--rw ip:ipv4!
| | +--rw ip:enabled? boolean
| | +--rw ip:forwarding? boolean
| | +--rw ip:mtu? uint16
| | +--rw ip:address* [ip]
| | | +--rw ip:ip inet:ipv4-address-no-zone
| | | +--rw (ip:subnet)
| | | +--:(ip:prefix-length)
| | | | +--rw ip:prefix-length? uint8
| | | +--:(ip:netmask)
| | | +--rw ip:netmask? yang:dotted-quad
| | +--rw ip:neighbor* [ip]
| | | +--rw ip:ip inet:ipv4-address-no-zone
| | | +--rw ip:link-layer-address yang:phys-address
| | +--rw ni:bind-network-instance-name? string
| +--rw ni:bind-network-instance-name? string
module: ietf-interfaces
+--rw interfaces
| +--rw interface* [name]
| +--rw name string
| +--rw ip:ipv4!
| | +--rw ip:enabled? boolean
| | +--rw ip:forwarding? boolean
| | +--rw ip:mtu? uint16
| | +--rw ip:address* [ip]
| | | +--rw ip:ip inet:ipv4-address-no-zone
| | | +--rw (ip:subnet)
| | | +--:(ip:prefix-length)
| | | | +--rw ip:prefix-length? uint8
| | | +--:(ip:netmask)
| | | +--rw ip:netmask? yang:dotted-quad
| | +--rw ip:neighbor* [ip]
| | | +--rw ip:ip inet:ipv4-address-no-zone
| | | +--rw ip:link-layer-address yang:phys-address
| | +--rw ni:bind-network-instance-name? string
| +--rw ni:bind-network-instance-name? string
The "ietf-interfaces" module [RFC8343] is structured to include all interfaces in a flat list, without regard to virtual instances (e.g., VRFs) supported on the device. The bind-network-instance-name leaf provides the association between an interface and its associated NI (e.g., VRF or VSI). Note that as currently defined, to assign an interface to both an LNE and an NI, the interface would first be assigned to the LNE using the mechanisms defined in [RFC8530] and then, within that LNE's interface module, the LNE's representation of that interface would be assigned to an NI.
“ietf接口”模块[RFC8343]的结构包括平面列表中的所有接口，而不考虑设备上支持的虚拟实例（如VRF）。绑定网络实例名称叶提供接口与其关联NI（例如，VRF或VSI）之间的关联。注意，按照目前的定义，要将接口分配给LNE和NI，首先使用[RFC8530]中定义的机制将接口分配给LNE，然后在该LNE的接口模块内，将该接口的LNE表示分配给NI。
Modules that may be used to represent network instance information will be available under the "root" mount point specific to the ni-type. The "shared-schema" method defined in the "ietf-yang-schema-mount" module [RFC8528] MUST be used to identify accessible modules. A future version of this document could relax this requirement. Mounted modules SHOULD be defined with access, via the appropriate schema mount parent-references [RFC8528], to device resources such as interfaces. An implementation MAY choose to restrict parent-referenced information to information related to a specific instance. For example, it might only allow references to interfaces that have a "bind-network-instance-name" that is identical to the instance's "name".
可用于表示网络实例信息的模块将在ni类型特定的“根”装入点下可用。必须使用“ietf模式装载”模块[RFC8528]中定义的“共享模式”方法来识别可访问的模块。本文件的未来版本可以放宽这一要求。应通过适当的模式装入父引用[RFC8528]来定义装入的模块，以访问接口等设备资源。实现可以选择将父引用的信息限制为与特定实例相关的信息。例如，它可能只允许引用具有与实例“名称”相同的“绑定网络实例名称”的接口。
All modules that represent control-plane and data-plane information may be present at the "root" mount point and accessible via paths modified per [RFC8528]. The list of available modules is expected to be implementation dependent, as is the method used by an implementation to support NIs.
代表控制平面和数据平面信息的所有模块可能位于“根”安装点，并可通过根据[RFC8528]修改的路径访问。可用模块的列表预计将取决于实现，实现用于支持NIs的方法也是如此。
For example, the following could be used to define the data organization of the example NI shown in Section 3.1.2:
例如，以下可用于定义第3.1.2节所示示例NI的数据组织：
"ietf-yang-schema-mount:schema-mounts": {
"mount-point": [
{
"module": "ietf-network-instance",
"label": "vrf-root",
"shared-schema": {
"parent-reference": [
"/*[namespace-uri() = 'urn:ietf:...:ietf-interfaces']"
]
}
}
]
}
"ietf-yang-schema-mount:schema-mounts": {
"mount-point": [
{
"module": "ietf-network-instance",
"label": "vrf-root",
"shared-schema": {
"parent-reference": [
"/*[namespace-uri() = 'urn:ietf:...:ietf-interfaces']"
]
}
}
]
}
Module data identified according to the ietf-yang-schema-mount module will be instantiated under the mount point identified under "mount-point". These modules will be able to reference information for nodes belonging to top-level modules that are identified under "parent-reference". Parent-referenced information is available to clients via their top-level paths only and not under the associated mount point.
根据ietf杨模式安装模块识别的模块数据将在“安装点”下识别的安装点下实例化。这些模块将能够参考属于“父参考”下标识的顶级模块的节点的信息。父级引用的信息仅通过客户端的顶级路径提供给客户端，而不在关联的装入点下提供。
To allow a client to understand the previously mentioned instance restrictions on parent-referenced information, an implementation MAY represent such restrictions in the "parent-reference" leaf-list. For example:
为了允许客户端理解前面提到的对父引用信息的实例限制，实现可以在“父引用”叶列表中表示此类限制。例如：
"namespace": [
{
"prefix": "if",
"uri": "urn:ietf:params:xml:ns:yang:ietf-interfaces"
},
{
"prefix": "ni",
"uri": "urn:ietf:params:xml:ns:yang:ietf-network-instance"
}
],
"mount-point": [
{
"module": "ietf-network-instance",
"label": "vrf-root",
"shared-schema": {
"parent-reference": [
"/if:interfaces/if:interface
[ni:bind-network-instance-name = current()/../ni:name]",
"/if:interfaces/if:interface/ip:ipv4
[ni:bind-network-instance-name = current()/../ni:name]",
"/if:interfaces/if:interface/ip:ipv6
[ni:bind-network-instance-name = current()/../ni:name]"
]
}
}
],
"namespace": [
{
"prefix": "if",
"uri": "urn:ietf:params:xml:ns:yang:ietf-interfaces"
},
{
"prefix": "ni",
"uri": "urn:ietf:params:xml:ns:yang:ietf-network-instance"
}
],
"mount-point": [
{
"module": "ietf-network-instance",
"label": "vrf-root",
"shared-schema": {
"parent-reference": [
"/if:interfaces/if:interface
[ni:bind-network-instance-name = current()/../ni:name]",
"/if:interfaces/if:interface/ip:ipv4
[ni:bind-network-instance-name = current()/../ni:name]",
"/if:interfaces/if:interface/ip:ipv6
[ni:bind-network-instance-name = current()/../ni:name]"
]
}
}
],
The same such "parent-reference" restrictions for non-NMDA implementations can be represented based on [RFC8343] and [RFC8344] as:
基于[RFC8343]和[RFC8344]，非NMDA实施的相同“父参考”限制可以表示为：
"namespace": [
{
"prefix": "if",
"uri": "urn:ietf:params:xml:ns:yang:ietf-interfaces"
},
{
"prefix": "ni",
"uri": "urn:ietf:params:xml:ns:yang:ietf-network-instance"
}
],
"mount-point": [
{
"module": "ietf-network-instance",
"label": "vrf-root",
"shared-schema": {
"parent-reference": [
"/if:interfaces/if:interface
[ni:bind-network-instance-name = current()/../ni:name]",
"/if:interfaces-state/if:interface
[if:name = /if:interfaces/if:interface
[ni:bind-ni-name = current()/../ni:name]/if:name]",
"/if:interfaces/if:interface/ip:ipv4
[ni:bind-network-instance-name = current()/../ni:name]",
"/if:interfaces-state/if:interface/ip:ipv4
[if:name = /if:interfaces/if:interface/ip:ipv4
[ni:bind-ni-name = current()/../ni:name]/if:name]",
"/if:interfaces/if:interface/ip:ipv6
[ni:bind-network-instance-name = current()/../ni:name]",
"/if:interfaces-state/if:interface/ip:ipv6
[if:name = /if:interfaces/if:interface/ip:ipv6
[ni:bind-ni-name = current()/../ni:name]/if:name]"
]
}
}
],
"namespace": [
{
"prefix": "if",
"uri": "urn:ietf:params:xml:ns:yang:ietf-interfaces"
},
{
"prefix": "ni",
"uri": "urn:ietf:params:xml:ns:yang:ietf-network-instance"
}
],
"mount-point": [
{
"module": "ietf-network-instance",
"label": "vrf-root",
"shared-schema": {
"parent-reference": [
"/if:interfaces/if:interface
[ni:bind-network-instance-name = current()/../ni:name]",
"/if:interfaces-state/if:interface
[if:name = /if:interfaces/if:interface
[ni:bind-ni-name = current()/../ni:name]/if:name]",
"/if:interfaces/if:interface/ip:ipv4
[ni:bind-network-instance-name = current()/../ni:name]",
"/if:interfaces-state/if:interface/ip:ipv4
[if:name = /if:interfaces/if:interface/ip:ipv4
[ni:bind-ni-name = current()/../ni:name]/if:name]",
"/if:interfaces/if:interface/ip:ipv6
[ni:bind-network-instance-name = current()/../ni:name]",
"/if:interfaces-state/if:interface/ip:ipv6
[if:name = /if:interfaces/if:interface/ip:ipv6
[ni:bind-ni-name = current()/../ni:name]/if:name]"
]
}
}
],
Network instances may be controlled by clients using existing list operations. When a list entry is created, a new instance is instantiated. The models mounted under an NI root are expected to be dependent on the server implementation. When a list entry is deleted, an existing network instance is destroyed. For more information, see Section 7.8.6 of [RFC7950].
网络实例可以由使用现有列表操作的客户端控制。创建列表条目时，将实例化一个新实例。安装在NI根目录下的模型预计将取决于服务器实现。删除列表条目时，现有网络实例将被销毁。有关更多信息，请参见[RFC7950]第7.8.6节。
Once instantiated, host network device resources can be associated with the new NI. As previously mentioned, this document augments ietf-interfaces with the bind-ni-name leaf to support such associations for interfaces. When a bind-ni-name is set to a valid NI name, an implementation MUST take whatever steps are internally necessary to assign the interface to the NI or provide an error message (defined below) with an indication of why the assignment failed. It is possible for the assignment to fail while processing the set operation or after asynchronous processing. Error notification in the latter case is supported via a notification.
一旦实例化，主机网络设备资源就可以与新NI关联。如前所述，本文档使用bind ni名称叶来扩充ietf接口，以支持接口的此类关联。当bind ni名称被设置为有效的ni名称时，实现必须采取任何内部必要的步骤将接口分配给ni，或提供一条错误消息（定义如下），指明分配失败的原因。在处理集合操作时或异步处理后，分配可能会失败。在后一种情况下，通过通知支持错误通知。
The YANG modules specified in this document define a schema for data that is 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]或restcconf[RFC8040]）进行访问。最低的NETCONF层是安全传输层，实现安全传输的强制要求是安全Shell（SSH）[RFC6242]。最低的RESTCONF层是HTTPS，实现安全传输的强制层是TLS[RFC8446]。
The Network Configuration Access Control Model (NACM) [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.
网络配置访问控制模型（NACM）[RFC8341]提供了将特定NETCONF或RESTCONF用户的访问限制为所有可用NETCONF或RESTCONF协议操作和内容的预配置子集的方法。
There are two different sets of security considerations to consider in the context of this document. One set is security related to information contained within mounted modules. The security considerations for mounted modules are not substantively changed based on the information being accessible within the context of an NI. For example, when considering the modules defined in [RFC8349], the security considerations identified in that document are equally applicable, whether those modules are accessed at a server's root or under an NI instance's root node.
在本文档的上下文中有两组不同的安全考虑事项要考虑。一组是与安装模块中包含的信息相关的安全性。基于NI上下文中可访问的信息，安装模块的安全注意事项没有实质性改变。例如，在考虑[RFC8349]中定义的模块时，该文档中确定的安全注意事项同样适用，无论这些模块是在服务器的根节点上访问还是在NI实例的根节点下访问。
The second area for consideration is information contained in the NI module itself. NI information represents network configuration and route distribution policy information. As such, the security of this information is important, but it is fundamentally no different than any other interface or routing configuration information that has already been covered in [RFC8343] and [RFC8349].
第二个需要考虑的领域是NI模块本身包含的信息。NI信息表示网络配置和路由分发策略信息。因此，该信息的安全性很重要，但它与[RFC8343]和[RFC8349]中已经介绍的任何其他接口或路由配置信息基本相同。
The vulnerable "config true" parameters and subtrees are the following:
易受攻击的“config true”参数和子树如下：
/network-instances/network-instance: This list specifies the network instances and the related control plane protocols configured on a device.
/网络实例/网络实例：此列表指定设备上配置的网络实例和相关控制平面协议。
/if:interfaces/if:interface/*/bind-network-instance-name: This leaf indicates the NI instance to which an interface is assigned.
/if:interfaces/if:interface/*/bind网络实例名称：此叶表示接口分配到的NI实例。
Unauthorized access to any of these lists can adversely affect the routing subsystem of both the local device and the network. This may lead to network malfunctions, delivery of packets to inappropriate destinations, and other problems.
未经授权访问这些列表可能会对本地设备和网络的路由子系统产生不利影响。这可能导致网络故障、将数据包传送到不适当的目的地以及其他问题。
This document registers a URI in the "IETF XML Registry" [RFC3688].
本文档在“IETF XML注册表”[RFC3688]中注册URI。
URI: urn:ietf:params:xml:ns:yang:ietf-network-instance
URI: urn:ietf:params:xml:ns:yang:ietf-network-instance
Registrant Contact: The IESG.
注册人联系人：IESG。
XML: N/A, the requested URI is an XML namespace.
XML:N/A，请求的URI是一个XML名称空间。
This document registers a YANG module in the "YANG Module Names" registry [RFC6020].
本文件在“阳模块名称”注册表[RFC6020]中注册阳模块。
name: ietf-network-instance
namespace: urn:ietf:params:xml:ns:yang:ietf-network-instance
prefix: ni
reference: RFC 8529
name: ietf-network-instance
namespace: urn:ietf:params:xml:ns:yang:ietf-network-instance
prefix: ni
reference: RFC 8529
The structure of the model defined in this document is described by the YANG module below.
本文件中定义的模型结构由以下模块描述。
<CODE BEGINS> file "ietf-network-instance@2019-01-21.yang"
module ietf-network-instance {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-network-instance";
prefix ni;
<CODE BEGINS> file "ietf-network-instance@2019-01-21.yang"
module ietf-network-instance {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-network-instance";
prefix ni;
// import some basic types
//导入一些基本类型
import ietf-interfaces {
prefix if;
reference
"RFC 8343: A YANG Data Model for Interface Management";
}
import ietf-ip {
prefix ip;
reference
"RFC 8344: A YANG Data Model for IP Management";
}
import ietf-yang-schema-mount {
prefix yangmnt;
reference
"RFC 8528: YANG Schema Mount";
}
import ietf-interfaces {
prefix if;
reference
"RFC 8343: A YANG Data Model for Interface Management";
}
import ietf-ip {
prefix ip;
reference
"RFC 8344: A YANG Data Model for IP Management";
}
import ietf-yang-schema-mount {
prefix yangmnt;
reference
"RFC 8528: YANG Schema Mount";
}
organization
"IETF Routing Area (rtgwg) Working Group";
contact
"WG Web: <https://datatracker.ietf.org/wg/rtgwg>
WG List: <mailto:rtgwg@ietf.org>
organization
"IETF Routing Area (rtgwg) Working Group";
contact
"WG Web: <https://datatracker.ietf.org/wg/rtgwg>
WG List: <mailto:rtgwg@ietf.org>
Author: Lou Berger <mailto:lberger@labn.net> Author: Christian Hopps <mailto:chopps@chopps.org> Author: Acee Lindem <mailto:acee@cisco.com> Author: Dean Bogdanovic <mailto:ivandean@gmail.com>"; description "This module is used to support multiple network instances within a single physical or virtual device. Network instances are commonly known as VRFs (VPN Routing and Forwarding) and VSIs (Virtual Switching Instances).
作者：Lou Berger<mailto:lberger@labn.net>作者：Christian Hopps<mailto:chopps@chopps.org>作者：Acee Lindem<mailto:acee@cisco.com>作者：迪安·博格达诺维奇<mailto:ivandean@gmail.com>“说明”此模块用于支持单个物理或虚拟设备中的多个网络实例。网络实例通常称为VRFs（VPN路由和转发）和VSIs（虚拟交换实例）。
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 (RFC 2119) (RFC 8174) when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可能”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14（RFC 2119）（RFC 8174）所述进行解释。
Copyright (c) 2019 IETF Trust and the persons identified as authors of the code. All rights reserved.
版权（c）2019 IETF信托基金和被认定为代码作者的人员。版权所有。
Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info).
根据IETF信托有关IETF文件的法律规定第4.c节规定的简化BSD许可证中包含的许可条款，允许以源代码和二进制格式重新分发和使用，无论是否修改(https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC 8529; see the RFC itself for full legal notices.";
此模块的此版本是RFC 8529的一部分；有关完整的法律通知，请参见RFC本身。“；
revision 2019-01-21 {
description
"Initial revision.";
reference
"RFC 8529";
}
revision 2019-01-21 {
description
"Initial revision.";
reference
"RFC 8529";
}
// top-level device definition statements
//顶级设备定义语句
container network-instances {
description
"Network instances, each of which consists of
VRFs and/or VSIs.";
reference
"RFC 8349: A YANG Data Model for Routing Management";
list network-instance {
key "name";
description
"List of network instances.";
leaf name {
type string;
mandatory true;
description
"device-scoped identifier for the network
instance.";
}
leaf enabled {
type boolean;
container network-instances {
description
"Network instances, each of which consists of
VRFs and/or VSIs.";
reference
"RFC 8349: A YANG Data Model for Routing Management";
list network-instance {
key "name";
description
"List of network instances.";
leaf name {
type string;
mandatory true;
description
"device-scoped identifier for the network
instance.";
}
leaf enabled {
type boolean;
default "true";
description
"Flag indicating whether or not the network
instance is enabled.";
}
leaf description {
type string;
description
"Description of the network instance
and its intended purpose.";
}
choice ni-type {
description
"This node serves as an anchor point for different types
of network instances. Each 'case' is expected to
differ in terms of the information needed in the
parent/core to support the NI and may differ in their
mounted-schema definition. When the mounted schema is
not expected to be the same for a specific type of NI,
a mount point should be defined.";
}
choice root-type {
mandatory true;
description
"Well-known mount points.";
container vrf-root {
description
"Container for mount point.";
yangmnt:mount-point "vrf-root" {
description
"Root for L3VPN-type models. This will typically
not be an inline-type mount point.";
}
}
container vsi-root {
description
"Container for mount point.";
yangmnt:mount-point "vsi-root" {
description
"Root for L2VPN-type models. This will typically
not be an inline-type mount point.";
}
}
container vv-root {
description
"Container for mount point.";
yangmnt:mount-point "vv-root" {
description
default "true";
description
"Flag indicating whether or not the network
instance is enabled.";
}
leaf description {
type string;
description
"Description of the network instance
and its intended purpose.";
}
choice ni-type {
description
"This node serves as an anchor point for different types
of network instances. Each 'case' is expected to
differ in terms of the information needed in the
parent/core to support the NI and may differ in their
mounted-schema definition. When the mounted schema is
not expected to be the same for a specific type of NI,
a mount point should be defined.";
}
choice root-type {
mandatory true;
description
"Well-known mount points.";
container vrf-root {
description
"Container for mount point.";
yangmnt:mount-point "vrf-root" {
description
"Root for L3VPN-type models. This will typically
not be an inline-type mount point.";
}
}
container vsi-root {
description
"Container for mount point.";
yangmnt:mount-point "vsi-root" {
description
"Root for L2VPN-type models. This will typically
not be an inline-type mount point.";
}
}
container vv-root {
description
"Container for mount point.";
yangmnt:mount-point "vv-root" {
description
"Root models that support both L2VPN-type bridging
and L3VPN-type routing. This will typically
not be an inline-type mount point.";
}
}
}
}
}
"Root models that support both L2VPN-type bridging
and L3VPN-type routing. This will typically
not be an inline-type mount point.";
}
}
}
}
}
// augment statements
//增广语句
augment "/if:interfaces/if:interface" { description "Add a node for the identification of the network instance associated with the information configured on a interface.
augment“/if:interfaces/if:interface”{description”添加一个节点，用于标识与接口上配置的信息关联的网络实例。
Note that a standard error will be returned if the
identified leafref isn't present. If an interface cannot
be assigned for any other reason, the operation SHALL fail
with an error-tag of 'operation-failed' and an
error-app-tag of 'ni-assignment-failed'. A meaningful
error-info that indicates the source of the assignment
failure SHOULD also be provided.";
leaf bind-ni-name {
type leafref {
path "/network-instances/network-instance/name";
}
description
"Network instance to which an interface is bound.";
}
}
augment "/if:interfaces/if:interface/ip:ipv4" {
description
"Add a node for the identification of the network
instance associated with the information configured
on an IPv4 interface.
Note that a standard error will be returned if the
identified leafref isn't present. If an interface cannot
be assigned for any other reason, the operation SHALL fail
with an error-tag of 'operation-failed' and an
error-app-tag of 'ni-assignment-failed'. A meaningful
error-info that indicates the source of the assignment
failure SHOULD also be provided.";
leaf bind-ni-name {
type leafref {
path "/network-instances/network-instance/name";
}
description
"Network instance to which an interface is bound.";
}
}
augment "/if:interfaces/if:interface/ip:ipv4" {
description
"Add a node for the identification of the network
instance associated with the information configured
on an IPv4 interface.
Note that a standard error will be returned if the
identified leafref isn't present. If an interface cannot
be assigned for any other reason, the operation SHALL fail
with an error-tag of 'operation-failed' and an
error-app-tag of 'ni-assignment-failed'. A meaningful
error-info that indicates the source of the assignment
failure SHOULD also be provided.";
leaf bind-ni-name {
type leafref {
path "/network-instances/network-instance/name";
Note that a standard error will be returned if the
identified leafref isn't present. If an interface cannot
be assigned for any other reason, the operation SHALL fail
with an error-tag of 'operation-failed' and an
error-app-tag of 'ni-assignment-failed'. A meaningful
error-info that indicates the source of the assignment
failure SHOULD also be provided.";
leaf bind-ni-name {
type leafref {
path "/network-instances/network-instance/name";
}
description
"Network instance to which IPv4 interface is bound.";
}
}
augment "/if:interfaces/if:interface/ip:ipv6" {
description
"Add a node for the identification of the network
instance associated with the information configured
on an IPv6 interface.
}
description
"Network instance to which IPv4 interface is bound.";
}
}
augment "/if:interfaces/if:interface/ip:ipv6" {
description
"Add a node for the identification of the network
instance associated with the information configured
on an IPv6 interface.
Note that a standard error will be returned if the
identified leafref isn't present. If an interface cannot
be assigned for any other reason, the operation SHALL fail
with an error-tag of 'operation-failed' and an
error-app-tag of 'ni-assignment-failed'. A meaningful
error-info that indicates the source of the assignment
failure SHOULD also be provided.";
leaf bind-ni-name {
type leafref {
path "/network-instances/network-instance/name";
}
description
"Network instance to which IPv6 interface is bound.";
}
}
Note that a standard error will be returned if the
identified leafref isn't present. If an interface cannot
be assigned for any other reason, the operation SHALL fail
with an error-tag of 'operation-failed' and an
error-app-tag of 'ni-assignment-failed'. A meaningful
error-info that indicates the source of the assignment
failure SHOULD also be provided.";
leaf bind-ni-name {
type leafref {
path "/network-instances/network-instance/name";
}
description
"Network instance to which IPv6 interface is bound.";
}
}
// notification statements
//通知声明
notification bind-ni-name-failed { description "Indicates an error in the association of an interface to an NI. Only generated after success is initially returned when bind-ni-name is set.
通知bind ni name failed{description”表示接口与ni关联时出错。只有在设置bind ni name时最初返回成功后生成的通知。
Note: Some errors may need to be reported for multiple associations, e.g., a single error may need to be reported for an IPv4 and an IPv6 bind-ni-name.
注意：可能需要为多个关联报告一些错误，例如，可能需要为IPv4和IPv6绑定ni名称报告单个错误。
At least one container with a bind-ni-name leaf MUST be
included in this notification.";
leaf name {
type leafref {
path "/if:interfaces/if:interface/if:name";
}
mandatory true;
description
"Contains the interface name associated with the
At least one container with a bind-ni-name leaf MUST be
included in this notification.";
leaf name {
type leafref {
path "/if:interfaces/if:interface/if:name";
}
mandatory true;
description
"Contains the interface name associated with the
failure.";
}
container interface {
description
"Generic interface type.";
leaf bind-ni-name {
type leafref {
path "/if:interfaces/if:interface"
+ "/ni:bind-ni-name";
}
description
"Contains the bind-ni-name associated with the
failure.";
}
}
container ipv4 {
description
"IPv4 interface type.";
leaf bind-ni-name {
type leafref {
path "/if:interfaces/if:interface/ip:ipv4/ni:bind-ni-name";
}
description
"Contains the bind-ni-name associated with the
failure.";
}
}
container ipv6 {
description
"IPv6 interface type.";
leaf bind-ni-name {
type leafref {
path "/if:interfaces/if:interface/ip:ipv6"
+ "/ni:bind-ni-name";
}
description
"Contains the bind-ni-name associated with the
failure.";
}
}
leaf error-info {
type string;
description
"Optionally, indicates the source of the assignment
failure.";
}
}
}
failure.";
}
container interface {
description
"Generic interface type.";
leaf bind-ni-name {
type leafref {
path "/if:interfaces/if:interface"
+ "/ni:bind-ni-name";
}
description
"Contains the bind-ni-name associated with the
failure.";
}
}
container ipv4 {
description
"IPv4 interface type.";
leaf bind-ni-name {
type leafref {
path "/if:interfaces/if:interface/ip:ipv4/ni:bind-ni-name";
}
description
"Contains the bind-ni-name associated with the
failure.";
}
}
container ipv6 {
description
"IPv6 interface type.";
leaf bind-ni-name {
type leafref {
path "/if:interfaces/if:interface/ip:ipv6"
+ "/ni:bind-ni-name";
}
description
"Contains the bind-ni-name associated with the
failure.";
}
}
leaf error-info {
type string;
description
"Optionally, indicates the source of the assignment
failure.";
}
}
}
<CODE ENDS>
<代码结束>
[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>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, <https://www.rfc-editor.org/info/rfc3688>.
[RFC3688]Mealling，M.，“IETF XML注册表”，BCP 81，RFC 3688，DOI 10.17487/RFC3688，2004年1月<https://www.rfc-editor.org/info/rfc3688>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, <https://www.rfc-editor.org/info/rfc6020>.
[RFC6020]Bjorklund，M.，Ed.“YANG-网络配置协议的数据建模语言（NETCONF）”，RFC 6020，DOI 10.17487/RFC6020，2010年10月<https://www.rfc-editor.org/info/rfc6020>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, <https://www.rfc-editor.org/info/rfc6241>.
[RFC6241]Enns，R.，Ed.，Bjorklund，M.，Ed.，Schoenwaeld，J.，Ed.，和A.Bierman，Ed.，“网络配置协议（NETCONF）”，RFC 6241，DOI 10.17487/RFC6241，2011年6月<https://www.rfc-editor.org/info/rfc6241>.
[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>.
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, <https://www.rfc-editor.org/info/rfc8340>.
[RFC8340]Bjorklund，M.和L.Berger，编辑，“杨树图”，BCP 215，RFC 8340，DOI 10.17487/RFC8340，2018年3月<https://www.rfc-editor.org/info/rfc8340>.
[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>.
[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, "Network Management Datastore Architecture (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, <https://www.rfc-editor.org/info/rfc8342>.
[RFC8342]Bjorklund，M.，Schoenwaeld，J.，Shafer，P.，Watsen，K.，和R.Wilton，“网络管理数据存储体系结构（NMDA）”，RFC 8342，DOI 10.17487/RFC8342，2018年3月<https://www.rfc-editor.org/info/rfc8342>.
[RFC8343] Bjorklund, M., "A YANG Data Model for Interface Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, <https://www.rfc-editor.org/info/rfc8343>.
[RFC8343]Bjorklund，M.，“用于接口管理的YANG数据模型”，RFC 8343，DOI 10.17487/RFC8343，2018年3月<https://www.rfc-editor.org/info/rfc8343>.
[RFC8344] Bjorklund, M., "A YANG Data Model for IP Management", RFC 8344, DOI 10.17487/RFC8344, March 2018, <https://www.rfc-editor.org/info/rfc8344>.
[RFC8344]Bjorklund，M.，“知识产权管理的杨氏数据模型”，RFC 8344，DOI 10.17487/RFC8344，2018年3月<https://www.rfc-editor.org/info/rfc8344>.
[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>.
[RFC8528] Bjorklund, M. and L. Lhotka, "YANG Schema Mount", RFC 8528, DOI 10.17487/RFC8528, March 2019, <https://www.rfc-editor.org/info/rfc8528>.
[RFC8528]Bjorklund，M.和L.Lhotka，“阳模式山”，RFC 8528，DOI 10.17487/RFC85282019年3月<https://www.rfc-editor.org/info/rfc8528>.
[RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual Private Network (VPN) Terminology", RFC 4026, DOI 10.17487/RFC4026, March 2005, <https://www.rfc-editor.org/info/rfc4026>.
[RFC4026]Andersson，L.和T.Madsen，“提供商提供的虚拟专用网络（VPN）术语”，RFC 4026，DOI 10.17487/RFC4026，2005年3月<https://www.rfc-editor.org/info/rfc4026>.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, <https://www.rfc-editor.org/info/rfc4364>.
[RFC4364]Rosen，E.和Y.Rekhter，“BGP/MPLS IP虚拟专用网络（VPN）”，RFC 4364，DOI 10.17487/RFC4364，2006年2月<https://www.rfc-editor.org/info/rfc4364>.
[RFC4664] Andersson, L., Ed. and E. Rosen, Ed., "Framework for Layer 2 Virtual Private Networks (L2VPNs)", RFC 4664, DOI 10.17487/RFC4664, September 2006, <https://www.rfc-editor.org/info/rfc4664>.
[RFC4664]Andersson，L.，Ed.和E.Rosen，Ed.，“第二层虚拟专用网络（L2VPN）框架”，RFC 4664，DOI 10.17487/RFC4664，2006年9月<https://www.rfc-editor.org/info/rfc4664>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, <https://www.rfc-editor.org/info/rfc7950>.
[RFC7950]Bjorklund，M.，Ed.“YANG 1.1数据建模语言”，RFC 7950，DOI 10.17487/RFC7950，2016年8月<https://www.rfc-editor.org/info/rfc7950>.
[RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for Routing Management (NMDA Version)", RFC 8349, DOI 10.17487/RFC8349, March 2018, <https://www.rfc-editor.org/info/rfc8349>.
[RFC8349]Lhotka，L.，Lindem，A.，和Y.Qu，“路由管理的YANG数据模型（NMDA版本）”，RFC 8349，DOI 10.17487/RFC8349，2018年3月<https://www.rfc-editor.org/info/rfc8349>.
[RFC8530] Berger, L., Hopps, C., Lindem, A., Bogdanovic, D., and X. Liu, "YANG Model for Logical Network Elements", RFC 8530, DOI 10.17487/RFC8530, March 2019.
[RFC8530]Berger，L.，Hopps，C.，Lindem，A.，Bogdanovic，D.，和X.Liu，“逻辑网络元素的杨模型”，RFC 8530，DOI 10.17487/RFC8530，2019年3月。
[YANG-L2VPN] Shah, H., Brissette, P., Chen, I., Hussain, I., Wen, B., and K. Tiruveedhula, "YANG Data Model for MPLS-based L2VPN", Work in Progress, draft-ietf-bess-l2vpn-yang-09, October 2018.
[YANG-L2VPN]Shah，H.，Brissette，P.，Chen，I.，Hussain，I.，Wen，B.，和K.Tiruveedhula，“基于MPLS的L2VPN的YANG数据模型”，正在进行的工作，草案-ietf-bess-L2VPN-YANG-09，2018年10月。
[YANG-L3VPN] Jain, D., Patel, K., Brissette, P., Li, Z., Zhuang, S., Liu, X., Haas, J., Esale, S., and B. Wen, "Yang Data Model for BGP/MPLS L3 VPNs", Work in Progress, draft-ietf-bess-l3vpn-yang-04, October 2018.
[YANG-L3VPN]Jain，D.，Patel，K.，Brissette，P.，Li，Z.，Zhuang，S.，Liu，X.，Haas，J.，Esale，S.，和B.Wen，“BGP/MPLS L3 VPN的YANG数据模型”，正在进行的工作，草案-ietf-bess-L3VPN-YANG-04，2018年10月。
[YANG-NETWORK] Lindem, A., Berger, L., Bogdanovic, D., and C. Hopps, "Network Device YANG Logical Organization", Work in Progress, draft-ietf-rtgwg-device-model-02, March 2017.
[YANG-NETWORK]Lindem，A.，Berger，L.，Bogdanovic，D.，和C.Hopps，“网络设备YANG逻辑组织”，正在进行的工作，草稿-ietf-rtgwg-Device-model-022017年3月。
[YANG-OSPF] Yeung, D., Qu, Y., Zhang, Z., Chen, I., and A. Lindem, "YANG Data Model for OSPF Protocol", Work in Progress, draft-ietf-ospf-yang-21, January 2019.
[YANG-OSPF]杨，D.，曲，Y.，张，Z.，陈，I.，和A.林登，“OSPF协议的YANG数据模型”，正在进行的工作，草案-ietf-OSPF-YANG-212019年1月。
The following subsections provide example uses of NIs.
以下小节提供了NIs的示例使用。
The following shows an example where two customer-specific network instances are configured:
下面显示了配置两个特定于客户的网络实例的示例：
{
"ietf-network-instance:network-instances": {
"network-instance": [
{
"name": "vrf-red",
"vrf-root": {
"ietf-routing:routing": {
"router-id": "192.0.2.1",
"control-plane-protocols": {
"control-plane-protocol": [
{
"type": "ietf-routing:ospf",
"name": "1",
"ietf-ospf:ospf": {
"af": "ipv4",
"areas": {
"area": [
{
"area-id": "203.0.113.1",
"interfaces": {
"interface": [
{
"name": "eth1",
"cost": 10
}
]
}
}
]
}
}
}
]
}
}
}
},
{
"name": "vrf-blue",
{
"ietf-network-instance:network-instances": {
"network-instance": [
{
"name": "vrf-red",
"vrf-root": {
"ietf-routing:routing": {
"router-id": "192.0.2.1",
"control-plane-protocols": {
"control-plane-protocol": [
{
"type": "ietf-routing:ospf",
"name": "1",
"ietf-ospf:ospf": {
"af": "ipv4",
"areas": {
"area": [
{
"area-id": "203.0.113.1",
"interfaces": {
"interface": [
{
"name": "eth1",
"cost": 10
}
]
}
}
]
}
}
}
]
}
}
}
},
{
"name": "vrf-blue",
"vrf-root": {
"ietf-routing:routing": {
"router-id": "192.0.2.2",
"control-plane-protocols": {
"control-plane-protocol": [
{
"type": "ietf-routing:ospf",
"name": "1",
"ietf-ospf:ospf": {
"af": "ipv4",
"areas": {
"area": [
{
"area-id": "203.0.113.1",
"interfaces": {
"interface": [
{
"name": "eth2",
"cost": 10
}
]
}
}
]
}
}
}
]
}
}
}
}
]
},
"vrf-root": {
"ietf-routing:routing": {
"router-id": "192.0.2.2",
"control-plane-protocols": {
"control-plane-protocol": [
{
"type": "ietf-routing:ospf",
"name": "1",
"ietf-ospf:ospf": {
"af": "ipv4",
"areas": {
"area": [
{
"area-id": "203.0.113.1",
"interfaces": {
"interface": [
{
"name": "eth2",
"cost": 10
}
]
}
}
]
}
}
}
]
}
}
}
}
]
},
"ietf-interfaces:interfaces": {
"interface": [
{
"name": "eth0",
"type": "iana-if-type:ethernetCsmacd",
"ietf-ip:ipv4": {
"address": [
{
"ip": "192.0.2.10",
"prefix-length": 24
}
]
},
"ietf-interfaces:interfaces": {
"interface": [
{
"name": "eth0",
"type": "iana-if-type:ethernetCsmacd",
"ietf-ip:ipv4": {
"address": [
{
"ip": "192.0.2.10",
"prefix-length": 24
}
]
},
"ietf-ip:ipv6": {
"address": [
{
"ip": "2001:db8:0:2::10",
"prefix-length": 64
}
]
}
},
{
"name": "eth1",
"type": "iana-if-type:ethernetCsmacd",
"ietf-ip:ipv4": {
"address": [
{
"ip": "192.0.2.11",
"prefix-length": 24
}
]
},
"ietf-ip:ipv6": {
"address": [
{
"ip": "2001:db8:0:2::11",
"prefix-length": 64
}
]
},
"ietf-network-instance:bind-network-instance-name": "vrf-red"
},
{
"name": "eth2",
"type": "iana-if-type:ethernetCsmacd",
"ietf-ip:ipv4": {
"address": [
{
"ip": "192.0.2.11",
"prefix-length": 24
}
]
},
"ietf-ip:ipv6": {
"address": [
{
"ip": "2001:db8:0:2::11",
"prefix-length": 64
}
]
"ietf-ip:ipv6": {
"address": [
{
"ip": "2001:db8:0:2::10",
"prefix-length": 64
}
]
}
},
{
"name": "eth1",
"type": "iana-if-type:ethernetCsmacd",
"ietf-ip:ipv4": {
"address": [
{
"ip": "192.0.2.11",
"prefix-length": 24
}
]
},
"ietf-ip:ipv6": {
"address": [
{
"ip": "2001:db8:0:2::11",
"prefix-length": 64
}
]
},
"ietf-network-instance:bind-network-instance-name": "vrf-red"
},
{
"name": "eth2",
"type": "iana-if-type:ethernetCsmacd",
"ietf-ip:ipv4": {
"address": [
{
"ip": "192.0.2.11",
"prefix-length": 24
}
]
},
"ietf-ip:ipv6": {
"address": [
{
"ip": "2001:db8:0:2::11",
"prefix-length": 64
}
]
}, "ietf-network-instance:bind-network-instance-name": "vrf-blue" } ] },
}，“ietf网络实例：绑定网络实例名称”：“vrf blue”}]}，
"ietf-system:system": {
"authentication": {
"user": [
{
"name": "john",
"password": "$0$password"
}
]
}
}
}
"ietf-system:system": {
"authentication": {
"user": [
{
"name": "john",
"password": "$0$password"
}
]
}
}
}
The following shows state data for the configuration example above based on [RFC8343], [RFC8344], and [RFC8349].
下面显示了基于[RFC8343]、[RFC8344]和[RFC8349]的上述配置示例的状态数据。
{
"ietf-network-instance:network-instances": {
"network-instance": [
{
"name": "vrf-red",
"vrf-root": {
"ietf-yang-library:modules-state": {
"module-set-id": "123e4567-e89b-12d3-a456-426655440000",
"module": [
{
"name": "ietf-yang-library",
"revision": "2019-01-04",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-yang-library",
"conformance-type": "implement"
},
{
"name": "ietf-ospf",
"revision": "2019-01-24",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-ospf",
"conformance-type": "implement"
},
{
"name": "ietf-routing",
{
"ietf-network-instance:network-instances": {
"network-instance": [
{
"name": "vrf-red",
"vrf-root": {
"ietf-yang-library:modules-state": {
"module-set-id": "123e4567-e89b-12d3-a456-426655440000",
"module": [
{
"name": "ietf-yang-library",
"revision": "2019-01-04",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-yang-library",
"conformance-type": "implement"
},
{
"name": "ietf-ospf",
"revision": "2019-01-24",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-ospf",
"conformance-type": "implement"
},
{
"name": "ietf-routing",
"revision": "2018-03-13",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-routing",
"conformance-type": "implement"
}
]
},
"ietf-routing:routing-state": {
"router-id": "192.0.2.1",
"control-plane-protocols": {
"control-plane-protocol": [
{
"type": "ietf-routing:ospf",
"name": "1",
"ietf-ospf:ospf": {
"af": "ipv4",
"areas": {
"area": [
{
"area-id": "203.0.113.1",
"interfaces": {
"interface": [
{
"name": "eth1",
"cost": 10
}
]
}
}
]
}
}
}
]
}
}
}
},
{
"name": "vrf-blue",
"vrf-root": {
"ietf-yang-library:modules-state": {
"module-set-id": "123e4567-e89b-12d3-a456-426655440000",
"module": [
{
"name": "ietf-yang-library",
"revision": "2019-01-04",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-yang-library",
"revision": "2018-03-13",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-routing",
"conformance-type": "implement"
}
]
},
"ietf-routing:routing-state": {
"router-id": "192.0.2.1",
"control-plane-protocols": {
"control-plane-protocol": [
{
"type": "ietf-routing:ospf",
"name": "1",
"ietf-ospf:ospf": {
"af": "ipv4",
"areas": {
"area": [
{
"area-id": "203.0.113.1",
"interfaces": {
"interface": [
{
"name": "eth1",
"cost": 10
}
]
}
}
]
}
}
}
]
}
}
}
},
{
"name": "vrf-blue",
"vrf-root": {
"ietf-yang-library:modules-state": {
"module-set-id": "123e4567-e89b-12d3-a456-426655440000",
"module": [
{
"name": "ietf-yang-library",
"revision": "2019-01-04",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-yang-library",
"conformance-type": "implement"
},
{
"name": "ietf-ospf",
"revision": "2019-01-24",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-ospf",
"conformance-type": "implement"
},
{
"name": "ietf-routing",
"revision": "2018-03-13",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-routing",
"conformance-type": "implement"
}
]
},
"ietf-routing:routing-state": {
"router-id": "192.0.2.2",
"control-plane-protocols": {
"control-plane-protocol": [
{
"type": "ietf-routing:ospf",
"name": "1",
"ietf-ospf:ospf": {
"af": "ipv4",
"areas": {
"area": [
{
"area-id": "203.0.113.1",
"interfaces": {
"interface": [
{
"name": "eth2",
"cost": 10
}
]
}
}
]
}
}
}
]
}
}
}
}
]
"conformance-type": "implement"
},
{
"name": "ietf-ospf",
"revision": "2019-01-24",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-ospf",
"conformance-type": "implement"
},
{
"name": "ietf-routing",
"revision": "2018-03-13",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-routing",
"conformance-type": "implement"
}
]
},
"ietf-routing:routing-state": {
"router-id": "192.0.2.2",
"control-plane-protocols": {
"control-plane-protocol": [
{
"type": "ietf-routing:ospf",
"name": "1",
"ietf-ospf:ospf": {
"af": "ipv4",
"areas": {
"area": [
{
"area-id": "203.0.113.1",
"interfaces": {
"interface": [
{
"name": "eth2",
"cost": 10
}
]
}
}
]
}
}
}
]
}
}
}
}
]
},
},
"ietf-interfaces:interfaces-state": {
"interface": [
{
"name": "eth0",
"type": "iana-if-type:ethernetCsmacd",
"oper-status": "up",
"phys-address": "00:01:02:A1:B1:C0",
"statistics": {
"discontinuity-time": "2017-06-26T12:34:56-05:00"
},
"ietf-ip:ipv4": {
"address": [
{
"ip": "192.0.2.10",
"prefix-length": 24
}
]
},
"ietf-ip:ipv6": {
"address": [
{
"ip": "2001:db8:0:2::10",
"prefix-length": 64
}
]
}
},
{
"name": "eth1",
"type": "iana-if-type:ethernetCsmacd",
"oper-status": "up",
"phys-address": "00:01:02:A1:B1:C1",
"statistics": {
"discontinuity-time": "2017-06-26T12:34:56-05:00"
},
"ietf-ip:ipv4": {
"address": [
{
"ip": "192.0.2.11",
"prefix-length": 24
}
]
},
"ietf-ip:ipv6": {
"address": [
{
"ietf-interfaces:interfaces-state": {
"interface": [
{
"name": "eth0",
"type": "iana-if-type:ethernetCsmacd",
"oper-status": "up",
"phys-address": "00:01:02:A1:B1:C0",
"statistics": {
"discontinuity-time": "2017-06-26T12:34:56-05:00"
},
"ietf-ip:ipv4": {
"address": [
{
"ip": "192.0.2.10",
"prefix-length": 24
}
]
},
"ietf-ip:ipv6": {
"address": [
{
"ip": "2001:db8:0:2::10",
"prefix-length": 64
}
]
}
},
{
"name": "eth1",
"type": "iana-if-type:ethernetCsmacd",
"oper-status": "up",
"phys-address": "00:01:02:A1:B1:C1",
"statistics": {
"discontinuity-time": "2017-06-26T12:34:56-05:00"
},
"ietf-ip:ipv4": {
"address": [
{
"ip": "192.0.2.11",
"prefix-length": 24
}
]
},
"ietf-ip:ipv6": {
"address": [
{
"ip": "2001:db8:0:2::11",
"prefix-length": 64
}
]
}
},
{
"name": "eth2",
"type": "iana-if-type:ethernetCsmacd",
"oper-status": "up",
"phys-address": "00:01:02:A1:B1:C2",
"statistics": {
"discontinuity-time": "2017-06-26T12:34:56-05:00"
},
"ietf-ip:ipv4": {
"address": [
{
"ip": "192.0.2.11",
"prefix-length": 24
}
]
},
"ietf-ip:ipv6": {
"address": [
{
"ip": "2001:db8:0:2::11",
"prefix-length": 64
}
]
}
}
]
},
"ip": "2001:db8:0:2::11",
"prefix-length": 64
}
]
}
},
{
"name": "eth2",
"type": "iana-if-type:ethernetCsmacd",
"oper-status": "up",
"phys-address": "00:01:02:A1:B1:C2",
"statistics": {
"discontinuity-time": "2017-06-26T12:34:56-05:00"
},
"ietf-ip:ipv4": {
"address": [
{
"ip": "192.0.2.11",
"prefix-length": 24
}
]
},
"ietf-ip:ipv6": {
"address": [
{
"ip": "2001:db8:0:2::11",
"prefix-length": 64
}
]
}
}
]
},
"ietf-system:system-state": {
"platform": {
"os-name": "NetworkOS"
}
},
"ietf-system:system-state": {
"platform": {
"os-name": "NetworkOS"
}
},
"ietf-yang-library:modules-state": {
"module-set-id": "123e4567-e89b-12d3-a456-426655440000",
"module": [
{
"name": "iana-if-type",
"revision": "2018-07-03",
"namespace": "urn:ietf:params:xml:ns:yang:iana-if-type",
"conformance-type": "import"
"ietf-yang-library:modules-state": {
"module-set-id": "123e4567-e89b-12d3-a456-426655440000",
"module": [
{
"name": "iana-if-type",
"revision": "2018-07-03",
"namespace": "urn:ietf:params:xml:ns:yang:iana-if-type",
"conformance-type": "import"
},
{
"name": "ietf-inet-types",
"revision": "2013-07-15",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-inet-types",
"conformance-type": "import"
},
{
"name": "ietf-interfaces",
"revision": "2018-02-20",
"feature": [
"arbitrary-names",
"pre-provisioning"
],
"namespace": "urn:ietf:params:xml:ns:yang:ietf-interfaces",
"conformance-type": "implement"
},
{
"name": "ietf-ip",
"revision": "2018-01-09",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-ip",
"conformance-type": "implement"
},
{
"name": "ietf-network-instance",
"revision": "2018-02-03",
"feature": [
"bind-network-instance-name"
],
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-network-instance",
"conformance-type": "implement"
},
{
"name": "ietf-ospf",
"revision": "2019-01-24",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-ospf",
"conformance-type": "implement"
},
{
"name": "ietf-routing",
"revision": "2018-03-13",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-routing",
"conformance-type": "implement"
},
{
"name": "ietf-system",
"revision": "2014-08-06",
},
{
"name": "ietf-inet-types",
"revision": "2013-07-15",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-inet-types",
"conformance-type": "import"
},
{
"name": "ietf-interfaces",
"revision": "2018-02-20",
"feature": [
"arbitrary-names",
"pre-provisioning"
],
"namespace": "urn:ietf:params:xml:ns:yang:ietf-interfaces",
"conformance-type": "implement"
},
{
"name": "ietf-ip",
"revision": "2018-01-09",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-ip",
"conformance-type": "implement"
},
{
"name": "ietf-network-instance",
"revision": "2018-02-03",
"feature": [
"bind-network-instance-name"
],
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-network-instance",
"conformance-type": "implement"
},
{
"name": "ietf-ospf",
"revision": "2019-01-24",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-ospf",
"conformance-type": "implement"
},
{
"name": "ietf-routing",
"revision": "2018-03-13",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-routing",
"conformance-type": "implement"
},
{
"name": "ietf-system",
"revision": "2014-08-06",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-system",
"conformance-type": "implement"
},
{
"name": "ietf-yang-library",
"revision": "2019-01-04",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-yang-library",
"conformance-type": "implement"
},
{
"name": "ietf-yang-schema-mount",
"revision": "2019-01-14",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-yang-schema-mount",
"conformance-type": "implement"
},
{
"name": "ietf-yang-types",
"revision": "2013-07-15",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-yang-types",
"conformance-type": "import"
}
]
},
"namespace": "urn:ietf:params:xml:ns:yang:ietf-system",
"conformance-type": "implement"
},
{
"name": "ietf-yang-library",
"revision": "2019-01-04",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-yang-library",
"conformance-type": "implement"
},
{
"name": "ietf-yang-schema-mount",
"revision": "2019-01-14",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-yang-schema-mount",
"conformance-type": "implement"
},
{
"name": "ietf-yang-types",
"revision": "2013-07-15",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-yang-types",
"conformance-type": "import"
}
]
},
"ietf-yang-schema-mount:schema-mounts": {
"mount-point": [
{
"module": "ietf-network-instance",
"label": "vrf-root",
"shared-schema": {
"parent-reference": [
"/*[namespace-uri() = 'urn:ietf:...:ietf-interfaces']"
]
}
}
]
}
}
"ietf-yang-schema-mount:schema-mounts": {
"mount-point": [
{
"module": "ietf-network-instance",
"label": "vrf-root",
"shared-schema": {
"parent-reference": [
"/*[namespace-uri() = 'urn:ietf:...:ietf-interfaces']"
]
}
}
]
}
}
The following shows state data for the configuration example above based on [RFC8343], [RFC8344], and [RFC8349].
下面显示了基于[RFC8343]、[RFC8344]和[RFC8349]的上述配置示例的状态数据。
{
"ietf-network-instance:network-instances": {
"network-instance": [
{
"name": "vrf-red",
"vrf-root": {
"ietf-yang-library:yang-library": {
"content-id": "41e2ab5dc325f6d86f743e8da3de323f1a61a801",
"module-set": [
{
"name": "ni-modules",
"module": [
{
"name": "ietf-yang-library",
"revision": "2019-01-04",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-yang-library"
},
{
"name": "ietf-ospf",
"revision": "2019-01-24",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-ospf"
},
{
"name": "ietf-routing",
"revision": "2018-03-13",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-routing"
}
],
"import-only-module": [
{
"name": "ietf-inet-types",
"revision": "2013-07-15",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-inet-types"
},
{
"name": "ietf-yang-types",
"revision": "2013-07-15",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-yang-types"
{
"ietf-network-instance:network-instances": {
"network-instance": [
{
"name": "vrf-red",
"vrf-root": {
"ietf-yang-library:yang-library": {
"content-id": "41e2ab5dc325f6d86f743e8da3de323f1a61a801",
"module-set": [
{
"name": "ni-modules",
"module": [
{
"name": "ietf-yang-library",
"revision": "2019-01-04",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-yang-library"
},
{
"name": "ietf-ospf",
"revision": "2019-01-24",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-ospf"
},
{
"name": "ietf-routing",
"revision": "2018-03-13",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-routing"
}
],
"import-only-module": [
{
"name": "ietf-inet-types",
"revision": "2013-07-15",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-inet-types"
},
{
"name": "ietf-yang-types",
"revision": "2013-07-15",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-yang-types"
},
{
"name": "ietf-datastores",
"revision": "2018-02-14",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-datastores"
}
]
}
],
"schema": [
{
"name": "ni-schema",
"module-set": [ "ni-modules" ]
}
],
"datastore": [
{
"name": "ietf-datastores:running",
"schema": "ni-schema"
},
{
"name": "ietf-datastores:operational",
"schema": "ni-schema"
}
]
},
"ietf-routing:routing": {
"router-id": "192.0.2.1",
"control-plane-protocols": {
"control-plane-protocol": [
{
"type": "ietf-routing:ospf",
"name": "1",
"ietf-ospf:ospf": {
"af": "ipv4",
"areas": {
"area": [
{
"area-id": "203.0.113.1",
"interfaces": {
"interface": [
{
"name": "eth1",
"cost": 10
}
]
}
},
{
"name": "ietf-datastores",
"revision": "2018-02-14",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-datastores"
}
]
}
],
"schema": [
{
"name": "ni-schema",
"module-set": [ "ni-modules" ]
}
],
"datastore": [
{
"name": "ietf-datastores:running",
"schema": "ni-schema"
},
{
"name": "ietf-datastores:operational",
"schema": "ni-schema"
}
]
},
"ietf-routing:routing": {
"router-id": "192.0.2.1",
"control-plane-protocols": {
"control-plane-protocol": [
{
"type": "ietf-routing:ospf",
"name": "1",
"ietf-ospf:ospf": {
"af": "ipv4",
"areas": {
"area": [
{
"area-id": "203.0.113.1",
"interfaces": {
"interface": [
{
"name": "eth1",
"cost": 10
}
]
}
}
]
}
}
}
]
}
}
}
},
{
"name": "vrf-blue",
"vrf-root": {
"ietf-yang-library:yang-library": {
"checksum": "41e2ab5dc325f6d86f743e8da3de323f1a61a801",
"module-set": [
{
"name": "ni-modules",
"module": [
{
"name": "ietf-yang-library",
"revision": "2019-01-04",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-yang-library",
"conformance-type": "implement"
},
{
"name": "ietf-ospf",
"revision": "2019-01-24",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-ospf",
"conformance-type": "implement"
},
{
"name": "ietf-routing",
"revision": "2018-03-13",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-routing",
"conformance-type": "implement"
}
],
"import-only-module": [
{
"name": "ietf-inet-types",
"revision": "2013-07-15",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-inet-types"
},
}
]
}
}
}
]
}
}
}
},
{
"name": "vrf-blue",
"vrf-root": {
"ietf-yang-library:yang-library": {
"checksum": "41e2ab5dc325f6d86f743e8da3de323f1a61a801",
"module-set": [
{
"name": "ni-modules",
"module": [
{
"name": "ietf-yang-library",
"revision": "2019-01-04",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-yang-library",
"conformance-type": "implement"
},
{
"name": "ietf-ospf",
"revision": "2019-01-24",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-ospf",
"conformance-type": "implement"
},
{
"name": "ietf-routing",
"revision": "2018-03-13",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-routing",
"conformance-type": "implement"
}
],
"import-only-module": [
{
"name": "ietf-inet-types",
"revision": "2013-07-15",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-inet-types"
},
{
"name": "ietf-yang-types",
"revision": "2013-07-15",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-yang-types"
},
{
"name": "ietf-datastores",
"revision": "2018-02-14",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-datastores"
}
]
}
],
"schema": [
{
"name": "ni-schema",
"module-set": [ "ni-modules" ]
}
],
"datastore": [
{
"name": "ietf-datastores:running",
"schema": "ni-schema"
},
{
"name": "ietf-datastores:operational",
"schema": "ni-schema"
}
]
},
"ietf-routing:routing": {
"router-id": "192.0.2.2",
"control-plane-protocols": {
"control-plane-protocol": [
{
"type": "ietf-routing:ospf",
"name": "1",
"ietf-ospf:ospf": {
"af": "ipv4",
"areas": {
"area": [
{
"area-id": "203.0.113.1",
"interfaces": {
"interface": [
{
{
"name": "ietf-yang-types",
"revision": "2013-07-15",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-yang-types"
},
{
"name": "ietf-datastores",
"revision": "2018-02-14",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-datastores"
}
]
}
],
"schema": [
{
"name": "ni-schema",
"module-set": [ "ni-modules" ]
}
],
"datastore": [
{
"name": "ietf-datastores:running",
"schema": "ni-schema"
},
{
"name": "ietf-datastores:operational",
"schema": "ni-schema"
}
]
},
"ietf-routing:routing": {
"router-id": "192.0.2.2",
"control-plane-protocols": {
"control-plane-protocol": [
{
"type": "ietf-routing:ospf",
"name": "1",
"ietf-ospf:ospf": {
"af": "ipv4",
"areas": {
"area": [
{
"area-id": "203.0.113.1",
"interfaces": {
"interface": [
{
"name": "eth2",
"cost": 10
}
]
}
}
]
}
}
}
]
}
}
}
}
]
},
"name": "eth2",
"cost": 10
}
]
}
}
]
}
}
}
]
}
}
}
}
]
},
"ietf-interfaces:interfaces": {
"interface": [
{
"name": "eth0",
"type": "iana-if-type:ethernetCsmacd",
"oper-status": "up",
"phys-address": "00:01:02:A1:B1:C0",
"statistics": {
"discontinuity-time": "2017-06-26T12:34:56-05:00"
},
"ietf-ip:ipv4": {
"address": [
{
"ip": "192.0.2.10",
"prefix-length": 24
}
]
},
"ietf-ip:ipv6": {
"address": [
{
"ip": "2001:db8:0:2::10",
"prefix-length": 64
}
]
}
},
{
"name": "eth1",
"type": "iana-if-type:ethernetCsmacd",
"ietf-interfaces:interfaces": {
"interface": [
{
"name": "eth0",
"type": "iana-if-type:ethernetCsmacd",
"oper-status": "up",
"phys-address": "00:01:02:A1:B1:C0",
"statistics": {
"discontinuity-time": "2017-06-26T12:34:56-05:00"
},
"ietf-ip:ipv4": {
"address": [
{
"ip": "192.0.2.10",
"prefix-length": 24
}
]
},
"ietf-ip:ipv6": {
"address": [
{
"ip": "2001:db8:0:2::10",
"prefix-length": 64
}
]
}
},
{
"name": "eth1",
"type": "iana-if-type:ethernetCsmacd",
"oper-status": "up",
"phys-address": "00:01:02:A1:B1:C1",
"statistics": {
"discontinuity-time": "2017-06-26T12:34:56-05:00"
},
"ietf-ip:ipv4": {
"address": [
{
"ip": "192.0.2.11",
"prefix-length": 24
}
]
},
"ietf-ip:ipv6": {
"address": [
{
"ip": "2001:db8:0:2::11",
"prefix-length": 64
}
]
}
},
{
"name": "eth2",
"type": "iana-if-type:ethernetCsmacd",
"oper-status": "up",
"phys-address": "00:01:02:A1:B1:C2",
"statistics": {
"discontinuity-time": "2017-06-26T12:34:56-05:00"
},
"ietf-ip:ipv4": {
"address": [
{
"ip": "192.0.2.11",
"prefix-length": 24
}
]
},
"ietf-ip:ipv6": {
"address": [
{
"ip": "2001:db8:0:2::11",
"prefix-length": 64
}
]
}
}
]
"oper-status": "up",
"phys-address": "00:01:02:A1:B1:C1",
"statistics": {
"discontinuity-time": "2017-06-26T12:34:56-05:00"
},
"ietf-ip:ipv4": {
"address": [
{
"ip": "192.0.2.11",
"prefix-length": 24
}
]
},
"ietf-ip:ipv6": {
"address": [
{
"ip": "2001:db8:0:2::11",
"prefix-length": 64
}
]
}
},
{
"name": "eth2",
"type": "iana-if-type:ethernetCsmacd",
"oper-status": "up",
"phys-address": "00:01:02:A1:B1:C2",
"statistics": {
"discontinuity-time": "2017-06-26T12:34:56-05:00"
},
"ietf-ip:ipv4": {
"address": [
{
"ip": "192.0.2.11",
"prefix-length": 24
}
]
},
"ietf-ip:ipv6": {
"address": [
{
"ip": "2001:db8:0:2::11",
"prefix-length": 64
}
]
}
}
]
},
},
"ietf-system:system-state": {
"platform": {
"os-name": "NetworkOS"
}
},
"ietf-system:system-state": {
"platform": {
"os-name": "NetworkOS"
}
},
"ietf-yang-library:yang-library": {
"content-id": "75a43df9bd56b92aacc156a2958fbe12312fb285",
"module-set": [
{
"name": "host-modules",
"module": [
{
"name": "ietf-interfaces",
"revision": "2018-02-20",
"feature": [
"arbitrary-names",
"pre-provisioning"
],
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-interfaces"
},
{
"name": "ietf-ip",
"revision": "2018-01-09",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-ip"
},
{
"name": "ietf-network-instance",
"revision": "2018-02-03",
"feature": [
"bind-network-instance-name"
],
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-network-instance"
},
{
"name": "ietf-ospf",
"revision": "2019-01-24",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-ospf"
},
{
"name": "ietf-routing",
"revision": "2018-03-13",
"namespace":
"ietf-yang-library:yang-library": {
"content-id": "75a43df9bd56b92aacc156a2958fbe12312fb285",
"module-set": [
{
"name": "host-modules",
"module": [
{
"name": "ietf-interfaces",
"revision": "2018-02-20",
"feature": [
"arbitrary-names",
"pre-provisioning"
],
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-interfaces"
},
{
"name": "ietf-ip",
"revision": "2018-01-09",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-ip"
},
{
"name": "ietf-network-instance",
"revision": "2018-02-03",
"feature": [
"bind-network-instance-name"
],
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-network-instance"
},
{
"name": "ietf-ospf",
"revision": "2019-01-24",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-ospf"
},
{
"name": "ietf-routing",
"revision": "2018-03-13",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-routing"
},
{
"name": "ietf-system",
"revision": "2014-08-06",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-system"
},
{
"name": "ietf-yang-library",
"revision": "2019-01-04",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-yang-library"
},
{
"name": "ietf-yang-schema-mount",
"revision": "2019-01-14",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-yang-schema-mount"
}
],
"import-only-module": [
{
"name": "iana-if-type",
"revision": "2018-07-03",
"namespace": "urn:ietf:params:xml:ns:yang:iana-if-type"
},
{
"name": "ietf-inet-types",
"revision": "2013-07-15",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-inet-types"
},
{
"name": "ietf-yang-types",
"revision": "2013-07-15",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-yang-types"
},
{
"name": "ietf-datastores",
"revision": "2018-02-14",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-datastores"
}
]
}
],
"schema": [
"urn:ietf:params:xml:ns:yang:ietf-routing"
},
{
"name": "ietf-system",
"revision": "2014-08-06",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-system"
},
{
"name": "ietf-yang-library",
"revision": "2019-01-04",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-yang-library"
},
{
"name": "ietf-yang-schema-mount",
"revision": "2019-01-14",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-yang-schema-mount"
}
],
"import-only-module": [
{
"name": "iana-if-type",
"revision": "2018-07-03",
"namespace": "urn:ietf:params:xml:ns:yang:iana-if-type"
},
{
"name": "ietf-inet-types",
"revision": "2013-07-15",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-inet-types"
},
{
"name": "ietf-yang-types",
"revision": "2013-07-15",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-yang-types"
},
{
"name": "ietf-datastores",
"revision": "2018-02-14",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-datastores"
}
]
}
],
"schema": [
{
"name": "host-schema",
"module-set": [ "host-modules" ]
}
],
"datastore": [
{
"name": "ietf-datastores:running",
"schema": "host-schema"
},
{
"name": "ietf-datastores:operational",
"schema": "host-schema"
}
]
},
{
"name": "host-schema",
"module-set": [ "host-modules" ]
}
],
"datastore": [
{
"name": "ietf-datastores:running",
"schema": "host-schema"
},
{
"name": "ietf-datastores:operational",
"schema": "host-schema"
}
]
},
"ietf-yang-schema-mount:schema-mounts": {
"mount-point": [
{
"module": "ietf-network-instance",
"label": "vrf-root",
"shared-schema": {
"parent-reference": [
"/*[namespace-uri() = 'urn:ietf:...:ietf-interfaces']"
]
}
}
]
}
}
"ietf-yang-schema-mount:schema-mounts": {
"mount-point": [
{
"module": "ietf-network-instance",
"label": "vrf-root",
"shared-schema": {
"parent-reference": [
"/*[namespace-uri() = 'urn:ietf:...:ietf-interfaces']"
]
}
}
]
}
}
Acknowledgments
致谢
The Routing Area Yang Architecture design team members included Acee Lindem, Anees Shaikh, Christian Hopps, Dean Bogdanovic, Lou Berger, Qin Wu, Rob Shakir, Stephane Litkowski, and Yan Gang. Martin Bjorklund and John Scudder provided useful review comments.
杨建筑设计团队成员包括Acee Lindem、Anes Shaikh、Christian Hopps、Dean Bogdanovic、Lou Berger、Qin Wu、Rob Shakir、Stephane Litkowski和Yan Gang。Martin Bjorklund和John Scudder提供了有用的评论。
This document was motivated by, and derived from, "Network Device YANG Logical Organization" [YANG-NETWORK].
本文件由“网络设备YANG逻辑组织”[YANG-Network]发起并衍生而来。
Thanks for Area Director and IETF last-call comments from Alia Atlas, Liang Xia, Benoit Claise, and Adam Roach.
感谢Alia Atlas、Liang Xia、Benoit Claise和Adam Roach的区域总监和IETF最后通话评论。
Authors' Addresses
作者地址
Lou Berger LabN Consulting, L.L.C.
Lou Berger LabN咨询公司，L.L.C。
Email: lberger@labn.net
Email: lberger@labn.net
Christian Hopps LabN Consulting, L.L.C.
Christian Hopps LabN咨询公司，L.L.C。
Email: chopps@chopps.org
Email: chopps@chopps.org
Acee Lindem Cisco Systems 301 Midenhall Way Cary, NC 27513 United States of America
Acee Lindem思科系统301美国北卡罗来纳州米登霍尔大道卡里27513号
Email: acee@cisco.com
Email: acee@cisco.com
Dean Bogdanovic Volta Networks
迪安·博格达诺维奇·沃尔塔网络公司
Email: ivandean@gmail.com
Email: ivandean@gmail.com
Xufeng Liu Volta Networks
徐峰刘伏塔网络
Email: xufeng.liu.ietf@gmail.com
Email: xufeng.liu.ietf@gmail.com