RFC 8199 YANG Module Classification

Internet Engineering Task Force (IETF)                     D. Bogdanovic
Request for Comments: 8199                          Volta Networks, Inc.
Category: Informational                                        B. Claise
ISSN: 2070-1721                                                C. Moberg
                                                     Cisco Systems, Inc.
                                                               July 2017

YANG Module Classification

Классификация модулей YANG

PDF

Аннотация

Язык моделирования данных YANG в настоящее время рассматривается для широкого спектра приложений сетевой отрасли в целом. Многие организации по разработке стандартов (SDO1), программные проекты с открытом кодом, производители и пользователи применяют YANG для разработки и публикации модулей с широким спектром применения. В то же время, нет установившейся терминологии для классификации различных модулей YANG.

Согласованная терминология поможет классифицировать модули YANG, проанализировать усилия IETF и других организаций по моделированию данных в YANG, а также внесет ясность в связанные с YANG дискуссии между различными группами.

В этом документе описан набор понятий и терминов для поддержки согласованной классификации модулей YANG.

Статус документа

Документ не относится к категории Internet Standards Track и публикуется с информационными целями.

Документ является результатом работы IETF2 и представляет согласованный взгляд сообщества IETF. Документ прошел открытое обсуждение и был одобрен для публикации IESG3. Дополнительную информацию о стандартах Internet можно найти в разделе 2 в RFC 7841.

Информацию о текущем статусе документа, ошибках и способах обратной связи можно найти по ссылке http://www.rfc-editor.org/info/rfc8199.

Авторские права

Авторские права (Copyright (c) 2017) принадлежат 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. Введение

IESG активно поощряет рабочие группы IETF к использования языка моделирования данных YANG [RFC7950] и протокола NETCONF4 [RFC6241] для целей управления конфигурацией (особенно в уставах новых рабочих групп [IESG-Statement]).

YANG также получает широкое признание в качестве стандартного (де-факто) языка моделирования данных в более широкой сфере. Это распространяется не только на IETF, но и на многие SDO, отраслевые консорциумы, специализированные группы, проекты с открытым кодом, производителей и конечных пользователей.

В настоящее время нет четких рекомендаций по классификации уровней модулей YANG в соответствии с абстракцией и способов классификации модулей среди публикаций формальных стандартов, фирменных модулей производителей и модулей конечных пользователей.

В этом документе представлен набор понятий и терминов для формирования таксономии согласованной классификации модулей YANG в двух аспектах:

  • уровни модулей на основе абстракций;

  • тип происхождения модуля на основе его природы и назначения.

Целью этого документа является обеспечение таксономии для упрощения человеческих коммуникаций, относящихся к модулям YANG. Хотя границы классификации порой размыты, документ должен послужить хорошей отправной точкой для сообщества YANG в процессе обретения дополнительного опыта разработки и внедрения модулей. Точнее говоря, предполагается, что критерии классификации будут меняться с течением времени.

Многие  модули, например, модули, связанные с топологией, вызвали серьезные дискуссии в процессе разработки этого документа. Топологические модули полезны как на уровне элементов сети (например, содержимое базы состояний каналов), так и на уровне сетевого сервиса (например, топология в масштабе сети). В конечном итоге модуль классифицирует его разработчик в соответствии с исходным назначением и содержимым модуля.

Этот документ должен помочь трем категориям, указанным ниже.

  • Во-первых, общая таксономия поможет в дискуссиях между SDO и отраслевыми консорциумами, цели которых определяются соответствующими областями работы.

  • Во-вторых, операторы могут рассмотреть уровни абстракции модулей YANG, чтобы понять, какие модули YANG для сетевого сервиса и элементов сети доступны при организации сервиса. Сложно определить тип модуля без проверки самого модуля YANG. Имя модуля может включать полезную информацию, но не является определенным ответом. Например, модуль YANG L2VPN5 может быть модулем сетевого сервиса, готовым для использования сетевым оператором в качестве модели сервиса. Однако он может быть и модулем YANG для элемента сети, который содержит определения данных L2VPN, требуемые для настройки конфигурации отдельного устройства.

  • В-третьих, такая таксономия поможет производителям оборудования (физического и виртуального), контроллеров и оркестраторов объяснить их заказчикам связи между различными модулями YANG, поддерживаемыми в их продукции.

1.1. Терминология

Приведенные ниже термины определены в [RFC7950].

data model — модель данных

Модель данных описывает представление данных и доступ к ним.

module — модуль

Модуль YANG определяет иерархии узлов схемы. Со своими и импортированными или включенными из любого источника определениями модуль является самодостаточным и «компилируемым».

2. Уровни абстракции модулей YANG

Разработчики модулей применяли два подхода для создания модулей YANG — «сверху-вниз» и «снизу-вверх». При нисходящем подходе сначала создаются абстракции верхнего уровня, моделирующие требования бизнеса или клиента, а затем они отображаются на конкретные сетевые технологии. Восходящий подход начинается с фундаментальных сетевых технологий и отображает их в более абстрактные конструкции.

В настоящее время нет конкретных требований или достаточно большого опыта разработки модулей YANG. В этом документе рассматриваются оба означенных выше подхода, поскольку каждый из них обеспечивает те или иные преимущества.

Для разделения по уровням документ предлагает классифицировать модули YANG на 2 разных уровня абстракции.

  • Модули элементов сети (Network Element YANG Module) описывают конфигурацию, данные состояния, операции и уведомления конкретных технологий или функций, связанных с устройством.

  • Модули сетевого сервиса (Network Service YANG Module) описывают конфигурацию, данные состояния, операции и уведомления абстрактного представления сервиса, реализованного в одном или множестве элементов сети.

На рисунке 1 показано применение модулей YANG на разных уровнях абстракции. Организация модулей по уровням обеспечивает возможность многократного применения модулей высокого уровня без дублирования функций.

Для разработчиков модулей разбиение по уровням позволяет разделить задачи между группами, специализирующимися в конкретных областях.

Например, опыт IETF показывает, что создание полезных модулей Network Element YANG (например, для протоколов маршрутизации или коммутации) требует команд, включающих разработчиков с опытом реализации таких протоколов.

                +--------------------------+
                |     Системы поддержки    |
                |     операция и бизнеса   |
                |         (OSS и BSS)      |
                +--------------------------+

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Модули YANG для сетевого сервиса

     +------------+      +-------------+      +-------------+
     |            |      |             |      |             |
     |  - L2VPN   |      |   - L2VPN   |      |    L3VPN    |
     |  - VPWS    |      |   - VPLS    |      |             |
     |            |      |             |      |             |
     +------------+      +-------------+      +-------------+

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Модули YANG для элементов сети

+------------+  +------------+  +-------------+  +------------+
|            |  |            |  |             |  |            |
|    MPLS    |  |    BGP     |  | IPv4 / IPv6 |  |  Ethernet  |
|            |  |            |  |             |  |            |
+------------+  +------------+  +-------------+  +------------+

  L2VPN - виртуальная частная сеть L2
  L3VPN - виртуальная частная сеть L3
  VPWS - виртуальный частный провод
  VPLS - виртуальная частная ЛВС

Рисунок 1. Абстрактные уровни модулей YANG.


С другой стороны, модули Network Service YANG лучше разрабатывать сетевым операторам, имеющим опыт определения сетевого сервиса для программистов, например, разработчиков систем обеспечения сквозного доступа или порталов самообслуживания.

2.1. Модули YANG для сетевого сервиса

Модули YANG для сетевого сервиса описывают характеристики сервиса, согласуемые с потребителями услуг. Сервисный модуль не раскрывает детально параметры конфигурации всех участвующих элементов и функций, но описывает абстрактную модель, которая позволяет разобрать экземпляр сервиса на экземпляры данных по модулям Network Element YANG участвующих в сервисе элементов сети. Декомпозиция сервиса по элементам является отдельным процессом, детали которого зависят от выбранной оператором реализации услуг. В этом документе системы, реализующие такой процесс, называются оркестраторами (orchestrator).

Внешние системы могут быть системами обеспечения, оркестраторами сервиса, OSS6, BSS7 и приложениями, раскрываемыми потребителям сетевого сервиса (внутренним участникам сетевых операций или внешним абонентам). Такие модули обычно проектируются, разрабатываются и внедряются командами поддержки сетевой инфраструктуры.

YANG позволяет использовать разные шаблоны для описания сетевого сервиса — от монолитных до компонентных.

Монолитный вариант охватывает сервис целиком в одном модуле, но не заботится о многократном использовании внутренних определений данных и группировок. Такой подход обеспечивает преимущества при создании модуля для решения одной задачи за счет скорости разработки в ущерб возможности повторного использования.

Компонентный подход охватывает ориентированные на устройства функции (например, VRF8, протоколы маршрутизации, фильтрация пакетов) независимым от производителя способом. Компоненты создаются с учетом их использования в других сервисных модулях. Затем из компонентов собирается модуль верхнего уровня для конкретного сервиса. Компонентный подход обеспечивает преимущества модульной разработки, включая возможность многократного использования компонентов, обеспечиваемую ценой замедления исходной разработки.

Например, сервис L2VPN может быть организован на основе множества технологий транспортных сетей, включая MPLS и Carrier Ethernet. Компонентный подход позволит применять определения интерфейсов между пользователем и сетью (UNI9), такие как MEF UNI или MPLS, независимо от базовой транспортной сети. При монолитном подходе нужно будет разрабатывать модули для конкретной комбинации транспорта и определений интерфейсов.

Пример модуля Network Service YANG содержится в [RFC8049], где представлена абстрактная модель конфигурации сервиса L3 IP VPN. Этот модуль включает концепцию доступа сайта в сеть (site-network-access) для представления параметров физического соединения. Оркестратор принимает операции над экземплярами сервиса в соответствии с модулем сервиса и разбирает данные в параметры конфигурации в соответствии с модулями Network Element YANG для настройки участвующих в сервисе элементов сети. В случае L3VPN параметры site-network-access будут транслироваться в параметры модулей Network Element YANG для соответствующих элементов.

2.2. Модули YANG для элементов сети

Модули Network Element YANG описывают характеристики сетевых устройств в соответствии с определениями производителей этих устройств. Модули обычно структурированы по функциям устройства. Например, конфигурация интерфейсов [RFC7223], конфигурация OSPF [OSPF-YANG], конфигурация ACL10 [ACL-YANG].

Модуль Network Element YANG обеспечивает согласованное представление модели данных программной среды, включающей операционную систему и приложения, работающие на устройстве. Декомпозиция, упорядочение и внесение изменений в конфигурацию операционной системы и приложений являются задачами агента, реализующего модуль.

3. Происхождение модуля YANG

Документ предлагает классифицировать модули YANG по типу их происхождения — стандартные (Standard) модули, фирменные (Vendor-Specific) модули и расширения, пользовательские (User-Specific) модули и расширения.

Предложенная классификация применима как для модулей Network Element YANG так и для Network Service YANG.

Предполагается, что реальные реализации модулей Network Service YANG и Network Element YANG будут включать все три типа по происхождению.

На рисунке 2 показаны связи между тремя типами модулей.

+----------------+
|Пользовательские|
|   расширения   |
+-------+--------+
    Дополнения
+-------+--------+  +----------------+  +----------------+
|   Фирменные    |  |Пользовательские|  |Пользовательские|
|   расширения   |  |   расширения   |  |   расширения   |
+-------+--------+  +-------+--------+  +-------+--------+
   Дополнения         Дополнения          Дополнения
+-------+-------------------+--------+  +-------+--------+  +----------------+
|            Стандартные             |  |   Фирменные    |  |Пользовательские|
|              модули                |  |     модули     |  |     модули     |
+------------------------------------+  +----------------+  +----------------+

Рисунок 2. Варианты происхождения модулей YANG.

3.1. Стандартные модули YANG

Стандартные модули YANG публикуют организации SDO. Многие SDO создают спецификации в соответствии с формальным процессом для создания стандартов, которые будут полезны их потребителям.

Жизненные циклы таких модулей определяются циклами стандартизации и не привязаны к конкретной реализации.

Примерами SDO в сетевой отрасли могут служить IETF и IEEE.

3.2. Фирменные модули YANG и расширения

Фирменные модули YANG разрабатываются организациями для поддержки определенного набора реализаций под контролем данной организации. Это могут быть производители виртуального или физического оборудования, отраслевые консорциумы, проекты с открытым кодом. Назначение таких модулей варьируется от предоставления открытых публичных модулей YANG, которые могут приниматься SDO в качестве стандартных, до строго внутренних модулей YANG, не предназначенных для использования другими.

Жизненный цикл таких модулей обычно связан с циклами выпуска продукции или результатов открытого проекта.

Важно отметить усиление взаимодействия в сетевой отрасли между проектами с открытым кодом и SDO. Это включает проекты с открытым кодом, реализующие опубликованные стандарты, а также вклад таких проектов в процессы SDO.

Производители также разрабатывают фирменные расширения для стандартных модулей, используя конструкции YANG для расширения определений данных из опубликованных ранее модулей. Это делается с помощью операторов augment, которые позволяют добавлять локально определенные деревья данных во внешние определения данных.

Производители используют это для расширения стандартных модулей с целью полного охвата возможностей реализации, которые обычно шире области действия стандартных модулей.

3.3. Пользовательские модули YANG и расширения

Пользовательские модули YANG разрабатываются организациями, которые работают с инфраструктурой на базе YANG, включая устройства и оркестраторы. Например, это могут быть сетевые администраторы предприятий или сервис-провайдеров. Эти модули предназначены для представления конкретных потребностей определенной реализации, дополняющих предоставленные производителем возможности.

Для этого типа модулей обычно нужна поддержка возможности внедрения в инфраструктуру пользовательских модулей и расширений. Это будет включать возможность описать декомпозицию сервиса в сеть для оркестраторов и декомпозицию модуля в конфигурацию для устройств.

Жизненный цикл таких модулей обычно связан с изменениями в инфраструктуре.

4. Вопросы безопасности

Документ не связан с какими-либо вопросами безопасности.

5. Взаимодействие с IANA

Этот документ не требует действий со стороны IANA.

6. Литература

6.1. Нормативные документы

[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, <http://www.rfc-editor.org/info/rfc6241>.

[RFC7223] Bjorklund, M., «A YANG Data Model for Interface Management», RFC 7223, DOI 10.17487/RFC7223, May 2014, <http://www.rfc-editor.org/info/rfc7223>.

[RFC7950] Bjorklund, M., Ed., «The YANG 1.1 Data Modeling Language», RFC 7950, DOI 10.17487/RFC7950, August 2016, <http://www.rfc-editor.org/info/rfc7950>.

[RFC8049] Litkowski, S., Tomotaki, L., and K. Ogaki, «YANG Data Model for L3VPN Service Delivery», RFC 8049, DOI 10.17487/RFC8049, February 2017, <http://www.rfc-editor.org/info/rfc8049>.

6.2. Дополнительная литература

[ACL-YANG] Bogdanovic, D., Jethanandani, M., Huang, L., Agarwal, S., and D. Blair, «Network Access Control List (ACL) YANG Data Model», Work in Progress, draft-ietf-netmod-acl-model-11, June 2017.

[IESG-Statement] «Writable MIB Module IESG Statement», <https://www.ietf.org/iesg/statement/writable-mib-module.html>.

[OSPF-YANG] Yeung, D., Qu, Y., Zhang, Z., Chen, I., and A. Lindem, «Yang Data Model for OSPF Protocol», Work in Progress, draft-ietf-ospf-yang-08, July 2017.

Благодарности

Спасибо David Ball и Jonathan Hansford за отклики и предложения.

Адреса авторов

Dean Bogdanovic

Volta Networks, Inc.

Email: dean@voltanet.io

Benoit Claise

Cisco Systems, Inc.

De Kleetlaan 6a b1

1831 Diegem

Belgium

Phone: +32 2 704 5622

Email: bclaise@cisco.com

Carl Moberg

Cisco Systems, Inc.

Email: camoberg@cisco.com

Перевод на русский язык

Николай Малых

nmalykh@protokols.ru

1Standards development organization.

2Internet Engineering Task Force.

3Internet Engineering Steering Group.

4Network Configuration Protocol — протокол настройки конфигурации сети.

5Layer 2 Virtual Private Network — виртуальная частная сеть L2.

6Operations Support System — система поддержки операций.

7Business Support System — система поддержки бизнеса.

8VPN Routing and Forwarding — маршрутизация и пересылка VPN.

9User-Network Interface.

10Access control list — список управления доступом.

Запись опубликована в рубрике RFC. Добавьте в закладки постоянную ссылку.