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 для экземпляров сетей
Аннотация
Этот документ определяет модуль для экземпляра сети, который может служить для управления разделением виртуальных ресурсов, которые могут присутствовать на сетевом устройстве. Примерами таких ресурсов являются экземпляры маршрутизации и пересылки VPN (VPN Routing and Forwarding или VRF) и виртуальных коммутаторов (Virtual Switch Instance или VSI).
Модель YANG в этом документе соответствует архитектуре хранилищ данных управления сетью (Network Management Datastore Architecture или NMDA), описанной в RFC 8342.
Статус документа
Документ относится к категории Internet Standards Track.
Документ является результатом работы IETF1 и представляет согласованный взгляд сообщества IETF. Документ прошёл открытое обсуждение и был одобрен для публикации IESG2. Дополнительную информацию о стандартах Internet можно найти в разделе 2 в RFC 7841.
Информацию о текущем статусе документа, ошибках и способах обратной связи можно найти по ссылке https://www.rfc-editor.org/info/rfc8529.
Авторские права
Copyright (c) 2019. Авторские права принадлежат IETF Trust и лицам, указанным в качестве авторов документа. Все права защищены.
К документу применимы права и ограничения, указанные в BCP 78 и IETF Trust Legal Provisions и относящиеся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно. Фрагменты программного кода, включённые в этот документ, распространяются в соответствии с упрощённой лицензией BSD, как указано в параграфе 4.e документа IETF Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).
1. Введение
Этот документ определяет второй из двух новых модулей, предназначенных для поддержки настройки и эксплуатации сетевых устройств, позволяющих выделить ресурсы для работы и управления (или одного из них). Оба модуля используют функциональность YANG, заданную модулей монтирования схемы YANG [RFC8528]. Модель YANG в этом документе соответствует архитектуре хранилищ сетевой информации NMDA, определённой в [RFC8342].
Первая форма выделения ресурсов обеспечивает логическое разделение сетевого устройства, в котором каждый раздел управляется раздельно как независимый элемент сети, который «размещается» на базовом сетевом устройстве (host). Эти элементы называются логическими сетевыми элементами (logical network element или LNE) и поддерживаются модулем logical-network-element, заданным в [RFC8530]. Этот модуль служит для идентификации LNE и связанных с каждым LNE ресурсов сетевого устройства. Сами элементы LNE представляются в YANG как независимые сетевые устройства с независимым доступом. Примеры терминов производителей для LNE включают logical system, logical router, virtual switch, chassis, fabric.
Вторая форма, определённая в этом документе, обеспечивает поддержку того, что называется экземплярами маршрутизации и пересылки VPN (VPN Routing and Forwarding или VRF), а также экземплярами виртуальных коммутаторов (Virtual Switch Instance или VSI), описанными в [RFC4026] и [RFC4664]. В этом варианте разделения ресурсов создаётся множество экземпляров плоскостей пересылки, а также маршрутизации и коммутации, предоставляемых и поддерживаемых на одном сетевом устройстве (физическом или виртуальном). Это форму разделения ресурсов называют экземплярами сетей (Network Instance или NI) и она поддерживается определенным ниже модулем. Конфигурация и работа каждого экземпляра сети всегда осуществляется через сетевое устройство и модуль экземпляра сети.
Существенное различие между моделями LNE и NI состоит в том, что модель NI обеспечивает основу для управления VRF и VSI. В этом документе предусмотрено раздельное определение моделей для VRF и VSI, т. е. технологий L3 VPN и L2 VPN. Примеры имеются в новой модели L3VPN из [YANG-L3VPN] и представлены ниже.
1.1. Терминология
Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не следует (SHALL NOT), следует (SHOULD), не нужно (SHOULD NOT), рекомендуется (RECOMMENDED), не рекомендуется (NOT RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с BCP 14 [RFC2119] [RFC8174] тогда и только тогда, когда они выделены шрифтом, как показано здесь.
Предполагается знакомство читателя с концепциями YANG [RFC7950] и YANG Schema Mount [RFC8528]. В документе применяется графическое представление моделей данных, описанное в [RFC8340].
2. Обзор
В этом документе рассматриваются сетевые устройства, которые поддерживают протоколы и функции, определённые в IETF, например, маршрутизаторы, межсетевые экраны, хосты. Такие устройства могут быть физическими или виртуальными, например, классический маршрутизатор с нестандартным (custom) оборудованием или маршрутизатор внутри виртуальной машины на сервере, реализующей функцию виртуальной сети (VNF). Каждое устройство может выделять свои ресурсы в элементы LNE, каждый из которых является управляемым логическим устройством. Примеры терминов производителей для LNE включают logical system, logical router, virtual switch, chassis, fabric. Каждый LNE может также поддерживать функции маршрутизации и пересылки VPN (VPN Routing and Forwarding или VRF) и экземпляра виртуальной коммутации (Virtual Switching Instance или VSI), которые далее называются экземплярами сети (Network Instance или NI). Это разделение представлено на рисунке 1.
,'''''''''''''''''''''''''''''''''''''''''''''''.
|Сетевое устройство (физическое или виртуальное)|
| ..................... ..................... |
| : LNE : : LNE : |
| :+-----+-----+-----+: :+-----+-----+-----+: |
| :| NI | NI | NI |: :| NI | NI | NI |: |
| :+-----+-----+-----+: :+-----+-----+-----+: |
| : | | | | | | : : | | | | | | : |
| :..|.|...|.|...|.|..: :..|.|...|.|...|.|..: |
| | | | | | | | | | | | | |
''''|'|'''|'|'''|'|'''''''''|'|'''|'|'''|'|'''''
| | | | | | | | | | | |
Интерфейсы Интерфейсы
Рисунок 1. Связи между элементами модуля.
Модель LNE описана в [RFC8530], а модель NI в разделе 3. Экземпляры сетей.
Текущая модель управления интерфейсом [RFC8343] затрагивается определениями LNE и NI. Этот документ и [RFC8530] определяют дополнения к модели интерфейса для поддержки LNE и NI.
Модель NI поддерживает конфигурации VRF и VSI. Каждый экземпляр поддерживается сведениями, относящимися к устройству, например, цель маршрута, применяемая при анонсировании маршрутов VRF с помощью механизмов [RFC4364], и информация, относящаяся к внутренней работе NI, такой как протоколы маршрутизации [RFC8349] и OSPF [YANG-OSPF]. В этом документе определён модуль network-instance, обеспечивающий основу для управления обоими типами информации.
Относящиеся к устройству сведения NI, включая назначение интерфейсов экземплярам NI, определена как часть этого документа. Заданный здесь модуль также обеспечивает замену (placeholder) для определения связанной с технологией NI информации на уровне устройства и внутренних операций NI. Сведения, относящиеся к внутренним операциям NI поддерживаются через монтирование схемы [RFC8528] и подходящих модулей в заданной точке. Определены общеизвестные точки монтирования для NI типов L3VPN, L2VPN, L2+L3VPN.
3. Экземпляры сетей
Контейнер network-instances служит для представления VRF и 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
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
Экземпляр сети указывается строкой name, которая применяется как индекс в модуле экземпляра сети и для связывания ресурсов с экземпляром, как показано выше в дополнении к interface. Операторы выбора (choice) ni-type и root-type служат для поддержки разных типов технологий VPN для L2 и L3. Уведомление bind-ni-name-failed передаётся при некоторых типах отказов.
3.1. Типы NI и точки монтирования
Модуль network-instance структурирован для упрощения определений моделей информации для конкретных типов VRF и VSI с использованием дополнений (augment). Например, сведения, требуемые для поддержки L2VPN, таких как VPLS, и EVPN, явно различаются. Примеры разрабатываемых моделей, которые можно реструктурировать для использования преимуществ NI, включают модели для L3VPN [YANG-L3VPN] и L2VPN [YANG-L2VPN].
Документам с определениями новых моделей YANG для поддержки определённых типов экземпляров сетей следует дополнять модуль network-instance. Базовая структура, которую следует применять для таких дополнений, включает оператор case с контейнерами для данных конфигурации и состояния, а также (при необходимости) зависящей от типа точки монтирования. В общем случае предполагается, что типам NI не требуется задавать специфические точки монтирования, используя для таких целей общеизвестные точки, описанные в следующем параграфе. Ниже приведён пример зависящего от типа дополнения.
augment "/ni:network-instances/ni:network-instance/ni:ni-type" {
case l3vpn {
container l3vpn {
...
}
container l3vpn-state {
...
}
}
}
3.1.1. Общеизвестные точки монтирования
YANG Schema Mount [RFC8528] указывает в модуле точки монтирования по имени. Это позволяет указать точки монтирования, схемы которых могут быть доступны всем типам NI. Как отмечено выше, ni-type в значительной степени различаются по конфигурационным сведениям, требуемым в экземпляре ядра или верхнего уровня для поддержки NI, а не по сведениям, представленным в NI. Это позволяет применять общие точки монтирования для разных типов NI.
Предполагается, что есть очень немного разных схем, которые требуется определить для поддержки NI в реализации. В частности, предполагается, что будут нужна три указанных ниже формы схем NI, каждую из которых можно определить с общеизвестной точкой монтирования, пригодной для будущих модулей с определениями типов NI.
vrf-root
Предназначена для использования с типами NI для L3VPN.vsi-root
Предназначена для использования с типами NI для L2VPN.vv-root
Предназначена для использования с типами NI, поддерживающими сразу мосты L2VPN и маршрутизацию L3VPN.Будущим определениям моделей следует использовать указанные выше точки монтирования, когда это возможно. Когда общеизвестные точки доступа не подходят, модель может определить свои точки монтирования через дополнения.
3.1.2. Пример типа NI
Ниже приведён пример L3VPN VRF, использующий гипотетическое дополнение к схеме NI, определённой в [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
| | ... // Данные конфигурации
| +--ro l3vpn:l3vpn-state
| | ... // данные состояния
+--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@
| ...
Здесь монтируются модули YANG Routing Management [RFC8349] и YANG OSPF [YANG-OSPF], которые ссылаться на информацию через parent-reference на контейнеры, определённые в [RFC8343].
3.2. NI и интерфейсы
Интерфейсы являются важной частью конфигурации и рабочего состояния любого сетевого устройства. Обычно они включают комбинацию необработанных (raw) физических интерфейсов, интерфейсов канального уровня, настройку адресов и логические интерфейсы, которые могут быть не привязаны ни к какому физическому интерфейсу. Некоторые системные службы, а также протоколы L2 и L3 тоже могут связывать свои данные конфигурации и рабочего состояния в различными типами интерфейсов (эти связи для простоты не показаны). Модель управления интерфейсом задана в [RFC8343].
Как показано ниже, модуль network-instance дополняет имеющуюся модель управления интерфейсом, добавляя имя, используемое в типе интерфейса или субинтерфейса для идентификации связанного NI. Это имя добавляется также для типов IPv4 и IPv6, как задано в [RFC8344].
Ниже приведён пример предполагаемого использования. Контейнер interfaces включает ряд часто применяемых элементов в качестве примеров.
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
Модуль ietf-interfaces [RFC8343] структурирован для включения всех интерфейсов в плоский список без учёта логического выделения ресурсов, поддерживаемых на устройстве. Лист (leaf) bind-network-instance-name обеспечивают связь между интерфейсом и соответствующим NI (например, VRF или VSI). Отметим, что в настоящее время при назначении интерфейсу как LNE, так и NI нужно сначала выделять интерфейс для LNE с использованием механизма из [RFC8530], а потом в модели интерфейса этого LNE связывать представление LNE для интерфейса с экземпляром NI.
3.3. Управление NI
Модули, которые могут применяться для представления сведений NI, доступны от точки монтирования root, зависящей от ni-type. Для идентификации доступных модулей должен применяться метод shared-schema, заданный в модуле ietf-yang-schema-mount [RFC8528]. Будущие версии спецификации могут смягчить это требование. Смонтированным модулям следует определять доступ через подходящие parent-reference [RFC8528] монтирования схемы к ресурсам устройства, таким как интерфейсы. Реализация может ограничить сведения parent-reference информацией, связанной с конкретным экземпляром, например, разрешать ссылки только на интерфейсы с bind-network-instance-name, идентичным name для экземпляра.
Все модули, представляющие сведения плоскостей данных и управления могут присутствовать в точке монтирования root и предоставлять доступ через пути, изменённые в соответствии с [RFC8528]. Предполагается, что список доступных модулей будет зависеть от реализации, как и метод, применяемый реализацией для поддержки NI.
Приведённый ниже фрагмент может использоваться для определения организации данных в примере NI из параграфа 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, будут создаваться в точке монтирования, указанной mount-point. Эти модули могут ссылаться на информацию обузлах, относящихся к модулям верхнего уровня, которые указаны в иерархии parent-reference. Эти сведения доступны клиентам через их пути верхнего уровня, а не из связанной точки монтирования.
Чтобы позволить клиенту понимать упомянутые выше ограничения экзампляра для сведений parent-reference, реализация может представить такие ограничения в листе-списке parent-reference. Например,
"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]"
]
}
}
],
Такие же ограничения parent-reference для реализаций, не соответствующих NMDA, можно представить на основе [RFC8343] и [RFC8344] как
"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]"
]
}
}
],
3.4. Создание экземпляра NI
Элементами NI может управлять клиент с использованием имеющегося списка операций. При создании записей списка порождается новый экземпляр NI. Предполагается, что модели, монтируемые в корень NI, будут зависеть от реализации сервера. При удалении записи списка уничтожается имеющийся элемент NI. Дополнительные сведения можно найти в параграфе 7.8.6 [RFC7950].
После создания экземпляра NI с ним можно связать ресурсы хост-устройства. Как отмечено ранее, этот документ дополняет ietf-interfaces листом bind-ni-name для поддержки таких ассоциаций с интерфейсами. При указании в bind-ni-name действительного имени NI реализация должна предпринять все требуемые шаги по назначению интерфейса элементу NI или возвратить сообщение об ошибке (см. ниже) с указанием причины отказа в назначении. Назначение может завершаться отказом во время обработки набора или по завершении асинхронной обработки. В последнем случае сведения об ошибке передаются через уведомление.
4. Вопросы безопасности
Заданный в этом документе модуль YANG определяет схему для данных, которая разработана для доступа через протоколы управления сетью, такие как NETCONF [RFC6241] и RESTCONF [RFC8040]. Нижним уровнем NETCONF является защищённый транспорт с обязательной реализацией Secure Shell (SSH) [RFC6242]. Нижним уровнем RESTCONF служит HTTPS с обязательной реализацией защищённого транспорта TLS [RFC8446].
Модель управления доступом NACM [RFC8341] обеспечивает средства, позволяющие предоставить доступ лишь конкретным пользователям NETCONF и RESTCONF к предопределённому подмножеству доступных в NETCONF или RESTCONF протокольных операций и содержимого.
В контексте этого документа нужно рассмотреть два аспекта безопасности. Один связан со сведениями, содержащимися в смонтированных модулях. Соображения безопасности для смонтированных модулей существенно не меняются на основе сведений, доступных из контекста NI. Например, при рассмотрении модулей, заданных в [RFC8349], указанные в этом документе соображения безопасности применимы независимо от доступа к модулям из корня сервера или корневого узла экземпляра NI.
Второй аспект безопасности относится к сведениям, содержащимся в самом модуле NI, представляющим конфигурацию сети и правила распространения маршрутов. Безопасность этих сведений важна, но принципиально не отличается от защиты других сведений о конфигурации устройства или интерфейса, рассмотренной в таких документах, как [RFC8343], [RFC8349].
Уязвимы могут быть параметры и ветви с config true, указанные ниже.
/network-instances/network-instance
Этот список указывает NI и связанные с ними протоколы плоскости управления, настроенные на устройстве./if:interfaces/if:interface/*/bind-network-instance-name
Этот лист указывает экземпляр NI, которому назначен интерфейс.Несанкционированный доступ к любому из этих списков может негативно влиять на подсистему маршрутизации локального устройства и сети. Это может приводить к сбоям в работе сети, доставке пакетов в непредусмотренные места и иным проблемам.
5. Взаимодействие с IANA
Этот документ регистрирует URI в реестре IETF XML Registry [RFC3688].
URI: urn:ietf:params:xml:ns:yang:ietf-network-instance
Registrant Contact: The IESG.
XML: N/A, the requested URI is an XML namespace.
Документ регистрирует модуль YANG в реестре YANG Module Names [RFC6020].
name: ietf-network-instance
namespace: urn:ietf:params:xml:ns:yang:ietf-network-instance
prefix: ni
reference: RFC 8529
6. Модель NI
Структура определённой в документе модели описана в представленном ниже модуле YANG.
<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 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>
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
"Этот модуль служит для поддержки множества экземпляров сетей
в одном физическом или виртуальном устройстве. Экземплярами
сетей обычно служат VRF и VSI.
Ключевые слова ДОЛЖНО, НЕДОПУСТИМО, ТРЕБУЕТСЯ, НУЖНО, НЕ СЛЕДУЕТ,
СЛЕДУЕТ, НЕ НУЖНО, РЕКОМЕДУЕТСЯ, НЕ РЕКОМЕНДУЕТСЯ, МОЖНО и
НЕОБЯЗАТЕЛЬНО в этом документе интерпретируются в соответствии с
BCP 14 (RFC 2119) (RFC 8174) тогда и только тогда, когда они
указаны заглавными буквами, как показано здесь.
Авторские права (Copyright (c) 2019) принадлежат IETF Trust
и лицам, указанным в качестве авторов кода. Все права защищены.
Распространение и использование в исходной или двоичной форме с
изменениями или без таковых разрешено в соответствии с лицензией
Simplified BSD, изложенной в разделе 4 IETF Trust's Legal
Provisions применительно к документам IETF
(http://trustee.ietf.org/license-info).
Эта версия данного модуля YANG является частью RFC 8529, где
правовые вопросы рассмотрены более полно.";
revision 2019-01-21 {
description
"Initial revision.";
reference
"RFC 8529";
}
// Операторы определения устройства верхнего уровня
container network-instances {
description
"Экземпляры NI, каждый из которых состоит из VRF и/или VSI.";
reference
"RFC 8349: A YANG Data Model for Routing Management";
list network-instance {
key "name";
description
"Список экземпляров сетей.";
leaf name {
type string;
mandatory true;
description
"Идентификатор экземпляра внутри устройства.";
}
leaf enabled {
type boolean;
default "true";
description
"Флаг, управляющий включением экземпляра сети.";
}
leaf description {
type string;
description
"Описание экземпляра сети и его назначения.";
}
choice ni-type {
description
"Этот узел служит якорной точкой для разных типов NI.
Предполагается, что каждый вариант (case) отличается в
части информации, требуемой в родителе (ядре) для
поддержки NI, и может отличатся в определении монтируемой
схемы. Когда смонтированные схемы не предполагаются
одинаковыми для конкретного типа NI, следует задавать
точку монтирования.";
}
choice root-type {
mandatory true;
description
"Общеизвестные точки монтирования.";
container vrf-root {
description
"Контейнер для точки монтирования.";
yangmnt:mount-point "vrf-root" {
description
"Корень для моделей L3VPN, обычно не типа inline.";
}
}
container vsi-root {
description
"Контейнер для точки монтирования.";
yangmnt:mount-point "vsi-root" {
description
"Корень для моделей L2VPN, обычно не типа inline.";
}
}
container vv-root {
description
"Контейнер для точки монтирования.";
yangmnt:mount-point "vv-root" {
description
"Корень для моделей, поддерживающих мосты L2VPN и
маршрутизацию L3VPN, обычно не типа inline.";
}
}
}
}
}
// Операторы дополнения (augment)
augment "/if:interfaces/if:interface" {
description
"Добавляет узел для идентификации элемента сети, связанного
со сведениями, настроенными на интерфейсе.
Отметим, что будет возвращаться стандартная ошибка, если
указанный leafref отсутствует. Если интерфейс по какой-либо
причине не может быть назначен, операцию НУЖНО прервать с
возвратом error-tag operation-failed и error-app-tag
ni-assignment-failed. СЛЕДУЕТ также предоставлять значимый
элемент error-info с указанием причины отказа в назначении.";
leaf bind-ni-name {
type leafref {
path "/network-instances/network-instance/name";
}
description
"Экземпляр сети, к которому привязан интерфейс.";
}
}
augment "/if:interfaces/if:interface/ip:ipv4" {
description
"Добавляет узел для идентификации элемента сети, связанного
со сведениями, настроенными на интерфейсе IPv4.
Отметим, что будет возвращаться стандартная ошибка, если
указанный leafref отсутствует. Если интерфейс по какой-либо
причине не может быть назначен, операцию НУЖНО прервать с
возвратом error-tag operation-failed и error-app-tag
ni-assignment-failed. СЛЕДУЕТ также предоставлять значимый
элемент error-info с указанием причины отказа в назначении.";
leaf bind-ni-name {
type leafref {
path "/network-instances/network-instance/name";
}
description
"Экземпляр сети, к которому привязан интерфейс IPv4.";
}
}
augment "/if:interfaces/if:interface/ip:ipv6" {
description
"Добавляет узел для идентификации элемента сети, связанного
со сведениями, настроенными на интерфейсе IPv6.
Отметим, что будет возвращаться стандартная ошибка, если
указанный leafref отсутствует. Если интерфейс по какой-либо
причине не может быть назначен, операцию НУЖНО прервать с
возвратом error-tag operation-failed и error-app-tag
ni-assignment-failed. СЛЕДУЕТ также предоставлять значимый
элемент error-info с указанием причины отказа в назначении.";
leaf bind-ni-name {
type leafref {
path "/network-instances/network-instance/name";
}
description
"Экземпляр сети, к которому привязан интерфейс IPv6.";
}
}
// Оператор уведомления (notification)
notification bind-ni-name-failed {
description
"Указывает ошибку при связывании интерфейса с NI. Создается
лишь после первоначального успеха при установке bind-ni-name.
Примечание. Некоторые ошибки может потребоваться сообщать
для нескольких ассоциаций, например для IPv4 и IPv6
bind-ni-name.
В уведомление ДОЛЖЕН включаться хотя бы один контейнер
с листом bind-ni-name.";
leaf name {
type leafref {
path "/if:interfaces/if:interface/if:name";
}
mandatory true;
description
"Имя интерфейса, связанного с отказом.";
}
container interface {
description
"Базовый тип интерфейса.";
leaf bind-ni-name {
type leafref {
path "/if:interfaces/if:interface"
+ "/ni:bind-ni-name";
}
description
"Значение bind-ni-name, связанное с отказом.";
}
}
container ipv4 {
description
"Интерфейс IPv4.";
leaf bind-ni-name {
type leafref {
path "/if:interfaces/if:interface/ip:ipv4/ni:bind-ni-name";
}
description
"Значение bind-ni-name, связанное с отказом.";
}
}
container ipv6 {
description
"Интерфейс IPv6.";
leaf bind-ni-name {
type leafref {
path "/if:interfaces/if:interface/ip:ipv6"
+ "/ni:bind-ni-name";
}
description
"Значение bind-ni-name, связанное с отказом.";
}
}
leaf error-info {
type string;
description
"Указывает причину отказа (необязательный элемент).";
}
}
}
<CODE ENDS>
7. Литература
7.1. Нормативные документы
[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC3688] Mealling, M., “The IETF XML Registry”, BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, <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>.
[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>.
[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>.
[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>.
[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>.
[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>.
[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>.
[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>.
[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>.
[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>.
[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>.
[RFC8528] Bjorklund, M. and L. Lhotka, “YANG Schema Mount”, RFC 8528, DOI 10.17487/RFC8528, March 2019, <https://www.rfc-editor.org/info/rfc8528>.
7.2. Нормативные документы
[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>.
[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>.
[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>.
[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>.
[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>.
[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, <https://www.rfc-editor.org/info/rfc8530>.
[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-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-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-OSPF] Yeung, D., Qu, Y., Zhang, Z., Chen, I., and A. Lindem, “YANG Data Model for OSPF Protocol”, Work in Progress3, draft-ietf-ospf-yang-21, January 2019.
Приложение A. Пример использования NI
В этом приложении даны примеры использования NI.
A.1. Configuration Data
Ниже приведён пример настройки двух клиентских экземпляров сетей.
{
"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
}
]
}
}
]
}
}
}
]
}
}
}
}
]
},
"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-network-instance:bind-network-instance-name":
"vrf-blue"
}
]
},
"ietf-system:system": {
"authentication": {
"user": [
{
"name": "john",
"password": "$0$password"
}
]
}
}
}
A.2. Данные состояния – без NMDA
Здесь показаны данные состояния для предыдущей конфигурации на основе [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",
"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
}
]
}
}
]
}
}
}
]
}
}
}
}
]
},
"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
}
]
}
}
]
},
"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"
},
{
"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"
}
]
},
"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']"
]
}
}
]
}
}
A.3. Данные состояния – NMDA
Здесь показаны данные состояния для предыдущей конфигурации на основе [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"
},
{
"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": "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
}
]
}
}
]
}
}
}
]
}
}
}
}
]
},
"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
}
]
}
}
]
},
"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":
"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"
}
]
},
"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']"
]
}
}
]
}
}
Благодарности
Команда разработчиков Routing Area Yang Architecture включала Acee Lindem, Anees Shaikh, Christian Hopps, Dean Bogdanovic, Lou Berger, Qin Wu, Rob Shakir, Stephane Litkowski, Yan Gang. Martin Bjorklund и John Scudder предоставили полезные обзорные комментарии.
Этот документ был выведен из Network Device YANG Logical Organization [YANG-NETWORK].
Спасибо за комментарии для Area Director и IETF last-call Alia Atlas, Liang Xia, Benoit Claise, Adam Roach.
Адреса авторов
Перевод на русский язык
Николай Малых
1Internet Engineering Task Force.
2Internet Engineering Steering Group.
3Опубликовано в RFC 9129. Прим. перев.