RFC 8342 Network Management Datastore Architecture (NMDA)

Опубликовано 31.03.2018 автором Nikolai Malykh 
Internet Engineering Task Force (IETF)                      M. Bjorklund
Request for Comments: 8342                                Tail-f Systems
Updates: 7950                                           J. Schoenwaelder
Category: Standards Track                              Jacobs University
ISSN: 2070-1721                                                P. Shafer
                                                               K. Watsen
                                                        Juniper Networks
                                                               R. Wilton
                                                           Cisco Systems
                                                              March 2018

Архитектура хранилища данных сетевого управления NMDA

Network Management Datastore Architecture (NMDA)

PDF

Аннотация

Хранилища данных являются фундаментальной концепцией привязки моделей данных, написанных на языке моделирования YANG, к протоколам сетевого управления, таким как NETCONF1 и RESTCONF. Этот документ определяет архитектурную модель для хранилищ данных на основе опыта, полученного с начальными простыми моделями, которая решает вопросы, не поддерживаемые первоначальной моделью. Документ обновляет RFC 7950.

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

Документ относится к категории Internet Standards Track.

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

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

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

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

Этот документ предоставляет архитектурную модель для хранилищ данных, используемых протоколами сетевого управления типа NETCONF [RFC6241] и RESTCONF [RFC8040], а также языком моделирования данных YANG [RFC7950]. Хранилища являются фундаментальной концепцией, привязывающей модели данных сетевого управления к протоколам сетевого управления. Согласование общей архитектурной модели хранилища данных позволит создавать модели данных без привязки к конкретному протоколу сетевого управления. Эта архитектурная основа идентифицирует набор концептуальных хранилищ, но не обязывает все протоколы сетевого управления предоставлять все эти концептуальные хранилища. Архитектура не привязана к кодированию, используемому протоколами сетевого управления.

Данный документ обновляет RFC 7950 в части определения доступного дерева для некоторых вариантов контекста XPath4 (см. параграф 6.1) и контекста вызова операций ( см. параграф 6.2).

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не следует (SHALL NOT), следует (SHOULD), не нужно (SHOULD NOT), рекомендуется (RECOMMENDED), не рекомендуется (NOT RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с BCP 14 [RFC2119] [RFC8174] тогда и только тогда, когда они выделены шрифтом, как показано здесь.

2. Цели

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

Исходная модель хранилищ данных требует моделирования этих данных в схеме YANG дважды – как объекты config true и config false. Соглашение, принятое в модели данных интерфейса [RFC8343] и модели данных IP [RFC8344], состоит в использовании двух раздельных ветвей с общим корнем – одна ветвь для объектов данных конфигурации, другая для объектов данных текущего состояния.

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

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

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

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

Используемые в документе термины определены ниже. Некоторые термины используют пересмотренные определения из [RFC6241] и [RFC7950] (см. также раздел 4). Эти пересмотренные определения семантически эквивалентны определениям из [RFC6241] и [RFC7950]. Предполагается, что обновлённые определения из этого раздела будут применяться взамен определений [RFC6241] и [RFC7950] при пересмотре этих документов.

datastore – хранилище данных

Концептуальное место для хранения и доступа к информации. Хранилище может быть реализовано, например, в виде файла, базы данных, flash-памяти или их комбинации. Хранилище отображается на экземпляр дерева данных YANG.

schema node – узел схемы

Узел в дереве схемы. Формальное определение приведено в RFC 7950.

datastore schema – схема хранилища данных

Комбинированный набор узлов схемы для всех модулей, поддерживаемых конкретным хранилищем с учётом всех отклонений и активных функций (feature) хранилища.

configuration – конфигурация, данные конфигурации

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

configuration datastore – хранилище конфигурации

Хранилище данных, содержащее параметры конфигурации.

running configuration datastore – хранилище рабочей конфигурации

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

candidate configuration datastore – хранилище будущей конфигурации, хранилище-кандидат

Конфигурационное хранилище, данные в котором можно изменять без влияния на рабочее хранилище данных устройства. Впоследствии эти данные могут быть переданы в рабочее хранилище. Это хранилище обозначают <candidate>.

startup configuration datastore – хранилище стартовой конфигурации

Конфигурационное хранилище, содержащие данные, которые будут помещены в рабочее хранилище при следующей загрузке устройства. Это хранилище обозначают <startup>.

intended configuration – предполагаемая конфигурация

Конфигурация, предназначенная для использования устройством. Представляет собой конфигурацию после выполнения всех преобразований в <running> и является конфигурацией, которую система попытается применить.

intended configuration datastore – хранилище предполагаемой конфигурации

Конфигурационное хранилище содержащее полную предполагаемую конфигурацию. Это хранилище обозначают <intended>.

configuration transformation – преобразование конфигурации

Дополнение, изменение или удаление данных конфигурации при передаче между хранилищами <running> и <intended>. Примерами конфигурационных преобразований служат удаление из конфигурации неактивных элементов и создание конфигурации из шаблона.

conventional configuration datastore – традиционное (обычное) хранилище данных конфигурации

Одно из хранилищ <running>, <startup>, <candidate> и <intended>. Эти хранилища используют общую схему и протокольные операции позволяют копировать данные между хранилищами. Термин conventional выбран в качестве общего обозначения всех таких хранилищ.

conventional configuration – конфигурация общего назначения

Конфигурационные данные, хранящиеся в любом из традиционных хранилищ.

dynamic configuration datastore – хранилище динамических данных конфигурации

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

dynamic configuration – динамическая конфигурация

Конфигурация, полученная из динамического хранилища.

learned configuration – выведенная конфигурация

Конфигурация, которая была выведена (learned) путём протокольного взаимодействия с другими системами и не является ни традиционной, ни динамической.

system configuration – системная конфигурация

Конфигурация, поставляемая (обеспечиваемая) самой системой.

default configuration – принятая по умолчанию конфигурация

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

applied configuration – применённая конфигурация

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

system state – состояние системы

Дополнительные данные системы, которые не относятся к конфигурационным, это могут быть предназначенные только для чтения параметры состояния или собранная статистика. Состояние системы является временным и меняется в результате взаимодействия с внутренними компонентами или внешними системами. Состояние системы моделируется в YANG с использованием узлов config false.

operational state – рабочее состояние

Комбинация применённой конфигурации и состояния системы.

operational state datastore – хранилище рабочего состояния

Хранилище данные, содержащее полное рабочее состояние устройства и обозначаемое <operational>.

origin – источник, происхождение

Аннотация метаданных, показывающая источник элементе данных.

remnant configuration – остаточная конфигурация

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

Приведённые ниже термины не связаны напрямую с хранилищами данных, но часто используются в документе.

client – клиент

Объект, который может иметь доступ к данным YANG на сервере с помощью некого протокола управления сетью.

server – сервер

Объект, который предоставляет клиенту доступ к данным YANG с помощью некого протокола управления сетью.

notification – уведомление

Инициированное сервером сообщение, указывающее на некое событие, которое распознал сервер.

remote procedure call – вызов удалённой процедуры

Операция которая может быть вызвана клиентом для выполнения на сервере.

4. Предпосылки

Протокол NETCONF [RFC6241] включает приведённые ниже определения.

datastore – хранилище данных

Концептуальное место хранения информации и доступа к ней. Хранилище может быть реализовано с использованием файлов, баз данных, флэш-памяти или их комбинации.

configuration datastore – хранилище конфигурации

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

Язык YANG 1.1 [RFC7950] вносит уточнения для использования NETCONF с YANG (обычное дело, но отметим, что протокол NETCONF был создан раньше YANG).

datastore

При моделировании с использованием YANG хранилище данных реализуется в виде экземпляра дерева данных.

configuration datastore

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

[RFC6244] определяет данные операционного состояния, как показано ниже.

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

В параграфе 4.3.3 [RFC6244] рассматривается операционное состояние и среди прочего упоминается возможность рассматривать это состояние, как сохраняемое в другом хранилище данных. В параграфе 4.4 [RFC6244] делается заключение, что во время написания документа рекомендовалось моделирование состояния в виде отдельных листьев и ветвей.

Опыт реализации и запросы операторов [OpState-Reqs] [OpState-Modeling] показали, что модель хранилища, разработанная изначально для NETCONF и уточнённая YANG, требует расширения. В частности, были разработаны понятия предполагаемой конфигурации и применённой конфигурации.

4.1. Исходная модель хранилищ данных

На рисунке 1 показана исходная модель хранилищ данных, используемая сейчас протоколом NETCONF [RFC6241].

+-------------+                 +-----------+
| <candidate> |                 | <startup> |
|  (ct, rw)   |<---+       +--->| (ct, rw)  |
+-------------+    |       |    +-----------+
       |           |       |           |
       |         +-----------+         |
       +-------->| <running> |<--------+
                 | (ct, rw)  |
                 +-----------+
                       |
                       v
                 рабочее состояние  <-- плоскость управления
                    (cf, ro)

ct = config true; cf = config false
rw = read-write; ro = read-only
прямоугольники обозначают хранилища

Рисунок 1.

Отметим, что модель на рисунке упрощена, полномочия read-only (ro) и read-write (rw) представлены с точки зрения клиента на концептуальном уровне. В NETCONF, например, поддержка хранилищ <candidate> и <startup> является не обязательной, а запись в хранилище <running> не разрешена. Кроме того, хранилище <startup> может быть изменено только путём копирования в него хранилища <running> <startup> в стандартизованной модели редактирования хранилищ NETCONF. Протокол RESTCONF не показывает таких различий и вместо этого обеспечивает универсальное хранилище с возможностью записи, которое скрывает редактирование через промежуточное хранилище <candidate> путём прямой записи в <running> или иного механизма, зависящего от реализации. RESTCONF также скрывает, как конфигурация становится постоянной. Отметим, что реализации могут иметь дополнительные хранилища, которые могут распространять изменения на <running>. NETCONF явно указывает «именованные хранилища данных» (named datastore).

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

  • Операционное состояние не было определено как хранилище данных, хотя были предложения о создании такого хранилища.

  • Операция NETCONF <get> возвращает содержимое хранилища <running> вместе с операционным состоянием. Это требует хранения данных config false и config true в разных ветвях, если данные операционного состояния по сроку жизни отличаются от конфигурационных данных, в также в тех случаях, когда конфигурация применяется не сразу или возникают проблемы с её применением.

  • Некоторые реализации используют фирменные механизмы, которые позволяют клиентам сохранять неактивные данные в хранилище <running>. Концептуально такие данные удаляются перед проверкой пригодности конфигурации.

  • Некоторые реализации используют фирменные механизмы, которые позволяют клиентам определять шаблоны конфигурации в хранилище <running>. Эти шаблоны автоматически раскрываются (преобразуются) системой и полученная в результате конфигурация применяется внутренними средствами.

  • Некоторые операторы отмечали, что для них важно получить успешно применению конфигурацию, которая может быть надмножеством или подмножеством конфигурации в хранилище <running>.

5. Архитектурная модель хранилищ данных

На рисунке 2 представлена новая концептуальная модель хранилищ данных, расширяющая исходную модель в соответствии с набранным при её использовании опытом.

+-------------+                 +-----------+
| <candidate> |                 | <startup> |
|  (ct, rw)   |<---+       +--->| (ct, rw)  |
+-------------+    |       |    +-----------+
       |           |       |           |
       |         +-----------+         |
       +-------->| <running> |<--------+
                 | (ct, rw)  |
                 +-----------+
                       |
                       |        // преобразования конфигурации,
                       |        // например, удаление узлов с 
                       |        // меткой "inactive", раскрытие
                       |        // шаблонов
                       v
                 +------------+
                 | <intended> | // нужна проверка на пригодность
                 | (ct, ro)   |
                 +------------+
                       |        // применение изменений; может
                       |        // от локальных факторов, например,
                       |        // отсутствие ресурсов, задержки
                       |
  хранилища            |   +-------- выведенная конфигурация
  динамической         |   +-------- конфигурация системы
  конфигурации ---+    |   +-------- конфигурация по умолчанию
                  |    |   |
                  v    v   v
               +---------------+
               | <operational> | <-- состояние системы
               | (ct + cf, ro) |
               +---------------+

     ct = config true; cf = config false
     rw = read-write; ro = read-only
     прямоугольники показывают именованные хранилища

Рисунок 2.


5.1. Традиционные хранилища конфигурации

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

  • <running>

  • <candidate>

  • <startup>

  • <intended>

В будущих документах могут быть определены дополнительные хранилища.

Поток данных между хранилищами описан в разделе 5.

Конкретные протоколы могут определять явные операции копирования между хранилищами (например, NETCONF <copy-config>.

5.1.1. Хранилище стартовой конфигурации (<startup>)

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

Хранилище стартовой конфигурации может поддерживаться не всеми протоколами и реализациями.

На устройствах с энергонезависимой памятью содержимое хранилища <startup> обычно будет сохраняться при перезагрузке устройства с использованием этого хранилища. Во время загрузки устройство помещает стартовую конфигурацию в хранилище <running>. Для сохранения новой стартовой конфигурации данные копируются в <startup> с помощью явной или неявной операции протокола.

5.1.2. Хранилище будущей конфигурации (<candidate>)

Хранилище будущей конфигурации <candidate> представляет собой хранилище конфигурационных данных, которыми можно манипулировать без влияния на текущую конфигурацию устройства, а затем представлять в хранилище <running>.

Хранилище будущей конфигурации может поддерживаться не всеми протоколами и реализациями.

Хранилище <candidate> обычно не сохраняется при перезагрузке устройства, даже если для него используется энергонезависимая память. Если хранилище <candidate> сохраняется в такой памяти, в процессе перезагрузки оно заменяется содержимым хранилища <running>.

5.1.3. Хранилище рабочей конфигурации (<running>)

Хранилище рабочей конфигурации <running> представляет собой хранилище с текущей конфигурацией устройства. Оно может содержать конфигурацию, которая перед применением требует преобразования (например, удаление неактивных элементов или раскрытие шаблонов). Однако хранилище <running> всегда должно быть пригодным деревом конфигурационных данных, как указано в параграфе 8.1 [RFC7950].

Хранилище <running> должно поддерживаться, если устройство настраивается с использованием традиционного хранилища конфигурации.

Если устройство не имеет отдельно хранилища <startup> и доступна энергонезависимая память, такое устройство обычно будет использовать эту память для сохранения <running> в процессе перезагрузки.

5.1.4. Хранилище предполагаемой конфигурации (<intended>)

Хранилище предполагаемой конфигурации <intended> открыто только для чтения. Оно представляет конфигурацию после выполнения всех преобразования в <running> (например, расширения шаблонов и удаления неактивных компонент), которую система пытается применить.

Хранилище <intended> тесно связано с <running>. При записи данных в хранилище <running> сервер должен незамедлительно обновить и проверить на пригодность хранилище <intended>.

Содержимое <intended> может также обновляться независимо от <running>, если воздействие преобразований конфигурации меняется, но хранилище <intended> всегда должен быть пригодным деревом данных конфигурации, как указано в параграфе 8.1 [RFC7950].

В простых реализациях хранилища <running> и <intended> идентичны.

Содержимое <intended> также связано с подмножеством config true хранилища <operational>, поэтому клиент может определить, в какой степени предполагаемая конфигурация соответствует текущей, просто проверяя, какая часть содержимого <intended> присутствует в <operational>.

Хранилище <intended> не сохраняется при перезагрузке – его привязка к <running> делает это ненужным.

В настоящее время не определено стандартных механизмов воздействия на хранилище <intended> так, чтобы оно отличалось от <running>, но данная архитектура позволяет определить такие механизмы.

Примером такого механизма может служить поддержка маркировки неактивных узлов в хранилище <running>. Неактивные узлы не будут копироваться в хранилище <intended>. Вторым примером является поддержка шаблонов, которые могут выполнять преобразования конфигурации из <running> для записи в хранилище <intended>.

5.2. Хранилища динамической конфигурации

Модель принимает необходимость хранилищ динамической конфигурации, которые по определению не являются частью постоянной конфигурации устройства. Иногда такие хранилища называют эфемерными (ephemeral datastore), поскольку хранящаяся в них информация теряется при перезагрузке. Хранилища динамической конфигурации взаимодействуют с остальной системой через хранилище <operational>.

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

5.3. Хранилище операционного состояния (<operational>)

Хранилище операционного состояния (<operational>) открыто лишь для чтения и включает все узлы config true и config false, определённые в схеме хранилища данных. В исходной модели NETCONF модель операционного состояния содержит только узлы config false. Причиной включения узлов config true является потребность в представлении рабочих параметров без их дублирования в модели данных.

Хранилище <operational> содержит данные состояния и конфигурацию, реально используемую системой. Это включает применённую конфигурацию из хранилища <intended>, выведенную (learned) и представленную системой конфигурацию, а также значения, принятые по умолчанию, которые определены любыми поддерживаемыми моделями данных. В дополнение к этому <operational> содержит также применённую конфигурацию из хранилища динамической конфигурации.

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

Запросы на поиск узлов из хранилища <operational> всегда возвращают используемое значение для существующих узлов, независимо от наличия в модуле YANG принятых по умолчанию значений. Если для данного узла значение не возвращено, это означает, что узел не используется устройством.

Интерпретация слов «используется системой» (in use) зависит от определения схемы и реализации устройства. Обычно функциональность, которая разрешена (включена) и работает в системе, считается используемой. И наоборот, функциональность, которая не включена и не работает считается «не используемой», поэтому её не следует включать в <operational>.

Для хранилища <operational> следует соблюдать любые ограничения, указанные в модели данных, но с учётом главной цели возвращать «используемые» значения, возможны случаи, когда такие ограничения могут быть нарушены при некоторых обстоятельствах (например, использование аномального значения, изменении структуры списка или наличии остаточной конфигурации (см. параграф 5.3.1)). Отметим, что такие отклонения следует допускать лишь в тех случаях, когда заранее известно, что устройство не полностью соответствует схеме <operational>.

Нарушаться могут только семантические ограничения. К ним относятся операторы YANG when, must, mandatory, unique, min-elements и max-elements, а также уникальность значений ключей.

Синтаксические ограничения, включая иерархическую организацию, идентификаторы и ограничения по типам, нарушать недопустимо. Если узел в хранилище <operational> не соответствует синтаксическим ограничениям, недопустимо возвращать его, а для информирования об ошибке следует применять другие механизмы.

Хранилище <operational> не сохраняется при перезагрузке устройства.

5.3.1. Остаточная конфигурация

При изменении конфигурации может потребоваться некоторое время на прохождение через хранилище <operational>. В этом интервале хранилище <operational> может одновременно содержать узлы предшествующей и текущей конфигурации, насколько возможно точно отслеживая текущую работу устройства. Остаточные данные предыдущей конфигурации будут сохраняться до тех пор, пока система не освободит ресурсы, использованные недавно удалённой конфигурацией (например, сетевые соединения, память, файлы).

Остаточная конфигурация является типичным примером, где семантические ограничения, определённые в модели данных, не могут быть применены для хранилища <operational>, поскольку в системе может сохраняться конфигурация, ограничения которой были пригодны для прежнего варианта, но недействительны в текущей конфигурации. Поскольку ограничения узлов config false могут быть связаны с узлами config true, остаточная конфигурация может вызывать нарушение этих ограничений.

5.3.2. Отсутствующие ресурсы

Конфигурация в <intended> может указывать ресурсы, которые не доступны или физически отсутствуют. В такой ситуации соответствующие части <intended> не применяются. Данные этих разделов присутствуют в <intended>, но не появляются в <operational>.

Типичным примером является конфигурация интерфейса, который в настоящее не присутствует. В этом случае конфигурация интерфейса остаётся в хранилище <intended>, но не включается в <operational>.

Отметим, что пригодность конфигурации не может зависеть от текущего состояния таких ресурсов, поскольку это приводило бы в непригодности конфигурации в случае удаления ресурса. Это неприемлемо, особенно с учётом того, что перезагрузка такого устройства будет приводить к его перезапуску с непригодной конфигурацией. Поэтому конфигурации с отсутствующими ресурсами разрешаются для хранилищ <running> и <intended>, но эти ресурсы не могут присутствовать в <operational>.

5.3.3. Контролируемые системой ресурсы

Иногда ресурсы, контролируемые системой и соответствующие данные появляются (и исчезают) в хранилище <operational> динамически. Если контролируемый системой ресурс имеет соответствующую конфигурацию в <intended> при его появлении, система попытается применить эту конфигурацию и это в конечном итоге приведёт к её появлению в хранилище <operational> (если применение пройдёт успешно).

5.3.4. Аннотация метаданных источника

При передаче конфигурации в хранилище <operational> она концептуально помечается аннотацией метаданных [RFC7952]Ю указывающей источник. Источник применяет все узлы за исключением контейнеров отсутствия. Аннотация метаданных origin определена в разделе 7. Значениями служат отождествления YANG, перечисленные ниже.

  • origin – абстрактное базовое отождествление, из которого выведено другое отождествление источника.

  • intended – представляет конфигурацию из хранилища <intended>.

  • dynamic – представляет конфигурацию из хранилища динамической конфигурации.

  • system – представляет конфигурацию, обеспеченную самой системой. Примеры системной конфигурации включают всегда присутствующий интерфейс loopback или конфигурацию интерфейса, которая создаётся автоматически при наличии оборудования в устройстве.

  • learned – представляет конфигурацию, которая была выведена через протокольные взаимодействия с другими системами (включая такие взаимодействия как согласование канального уровня, протоколы маршрутизации, DHCP).

  • default – представляет конфигурацию с применением значений, принятых по умолчанию в модели данных, используя значения в операторе default или любые значения, описанные в операторе description. Этот источник лишь про отсутствии других источников конфигурации.

  • unknown – представляет конфигурацию, для которой система не может определить источник.

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

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

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

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

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

Если устройство не может точно указать источник данных для отдельного узла конфигурации, следует указывать источник unknown.

6. Воздействие на YANG

6.1. Контекст XPath

Этот параграф обновляет параграф 6.4.1 из RFC 7950.

Если сервер реализует определённую в этом документе архитектуру, доступные деревья для некоторых вариантов контекста XPath уточняются как показано ниже.

  • Если выражение XPath определено в субоператоре узла данных, который представляет состояние системы, доступным деревом является все операционное состояние сервера. Корневой узел имеет в качестве потомков узлы верхнего уровня всех модулей.

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

  • Если выражение XPath определено в субоператоре оператора input внутри оператора rpc или action, доступным деревом будет экземпляр RPC или операции и все операционное состояние сервера. Корневой узел имеет в качестве потомков узлы верхнего уровня всех модулей. Кроме того, для RPC корневой узел имеет в качестве потомка также узел, который представляет определяемую операцию RPC. Этот узел имеет в качестве потомков входные параметры операции.

  • Если выражение XPath определено в субоператоре оператора output внутри оператора rpc или action, доступным деревом будет экземпляр RPC или операции и все операционное состояние сервера. Корневой узел имеет в качестве потомков узлы верхнего уровня всех модулей. Кроме того, для RPC корневой узел имеет в качестве потомка также узел, который представляет определяемую операцию RPC. Этот узел имеет в качестве потомков выходные результаты операции.

6.2. Вызовы операций и RPC

Этот параграф обновляет параграф 7.15 из RFC 7950.

Операции всегда вызываются к контексте хранилища операционного состояния. Узел, для которого вызывается операция, должен существовать в хранилище операционного состояния.

Отметим, что этот документ никак не ограничивает результат вызова RPC или операции. Например, можно определить RPC для изменения содержимого того или иного хранилища данных.

7. Модули YANG

   <CODE BEGINS> file "ietf-datastores@2018-02-14.yang"

   module ietf-datastores {
     yang-version 1.1;
     namespace "urn:ietf:params:xml:ns:yang:ietf-datastores";
     prefix ds;

     organization
       "IETF Network Modeling (NETMOD) Working Group";

     contact
       "WG Web:   <https://datatracker.ietf.org/wg/netmod/> 

        WG List:  <mailto:netmod@ietf.org> 

        Author:   Martin Bjorklund
                  <mailto:mbj@tail-f.com> 

        Author:   Juergen Schoenwaelder
                  <mailto:j.schoenwaelder@jacobs-university.de> 

        Author:   Phil Shafer
                  <mailto:phil@juniper.net> 

        Author:   Kent Watsen
                  <mailto:kwatsen@juniper.net> 

        Author:   Rob Wilton
                  <rwilton@cisco.com>"; 

     description
       "Этот модуль YANG задает набор идентификаторов хранилищ данных.

        Авторские права (Copyright (c) 2018) принадлежат IETF Trust
        и лицам, указанным в качестве авторов кода. Все права защищены.

        Распространение и использование в исходной или двоичной форме с
        изменениями или без таковых разрешено в соответствии с лицензией
        Simplified BSD, изложенной в разделе 4  IETF Trust's Legal
        Provisions применительно к документам IETF
        (http://trustee.ietf.org/license-info). 
 
        Эта версия данного модуля YANG является частью RFC 8342, где
        правовые вопросы рассмотрены более полно.";

     revision 2018-02-14 {
       description
         "Initial revision.";
       reference
         "RFC 8342: Network Management Datastore Architecture (NMDA)";
     }

     /*
      * Отождествления (идентификаторы)
      */

     identity datastore {
       description
         "Абстрактный базовый идентификатор для хранилища данных.";
     }

     identity conventional {
       base datastore;
       description
         "Абстрактный базовый идентификатор для традиционного
          хранилища данных.";
     }

     identity running {
       base conventional;
       description
         "Хранилище рабочей конфигурации.";
     }

     identity candidate {
       base conventional;
       description
         "Хранилище конфигурации-кандидата.";
     }

     identity startup {
       base conventional;
       description
         "Хранилище данных стартовой конфигурации.";
     }

     identity intended {
       base conventional;
       description
         "Хранилище данных предполагаемой конфигурации.";
     }

     identity dynamic {
       base datastore;
       description
         "Абстрактный базовый идентификатор для хранилища
          данных динамической конфигурации.";
     }

     identity operational {
       base datastore;
       description
         "Хранилище данных рабочего состояния.";
     }

     /*
      * Определения типов
      */

     typedef datastore-ref {
       type identityref {
         base datastore;
       }
       description
         "Ссылка на идентификатор хранилища данных.";
     }
   }

   <CODE ENDS>
   <CODE BEGINS> file "ietf-origin@2018-02-14.yang"

   module ietf-origin {
     yang-version 1.1;
     namespace "urn:ietf:params:xml:ns:yang:ietf-origin";
     prefix or;

     import ietf-yang-metadata {
       prefix md;
     }

     organization
       "IETF Network Modeling (NETMOD) Working Group";

     contact
       "WG Web:   <https://datatracker.ietf.org/wg/netmod/> 

        WG List:  <mailto:netmod@ietf.org> 

        Author:   Martin Bjorklund
                  <mailto:mbj@tail-f.com> 

        Author:   Juergen Schoenwaelder
                  <mailto:j.schoenwaelder@jacobs-university.de> 

        Author:   Phil Shafer
                  <mailto:phil@juniper.net> 

        Author:   Kent Watsen
                  <mailto:kwatsen@juniper.net> 

        Author:   Rob Wilton
                  <rwilton@cisco.com>"; 

     description
       "Этот модуль YANG задает аннотацию метаданных origin и набор
        идентификаторов для значения origin.

        Авторские права (Copyright (c) 2018) принадлежат IETF Trust
        и лицам, указанным в качестве авторов кода. Все права защищены.

        Распространение и использование в исходной или двоичной форме с
        изменениями или без таковых разрешено в соответствии с лицензией
        Simplified BSD, изложенной в разделе 4  IETF Trust's Legal
        Provisions применительно к документам IETF
        (http://trustee.ietf.org/license-info). 
 
        Эта версия данного модуля YANG является частью RFC 8342, где
        правовые вопросы рассмотрены более полно.";

     revision 2018-02-14 {
       description
         "Initial revision.";
       reference
         "RFC 8342: Network Management Datastore Architecture (NMDA)";
     }

     /*
      * Отождествления (идентификаторы)
      */

     identity origin {
       description
         "Абстрактный базовый идентификатор для аннотации источника.";
     }

     identity intended {
       base origin;
       description
         "Конфигурация из хранилища intended.";
     }

     identity dynamic {
       base origin;
       description
         "Конфигурация из хранилища dynamic.";
     }

     identity system {
       base origin;
       description
         "Конфигурация самой системы.

          Примеры конфигурации системы включают конфигурацию, 
          примененную к всегда имеющемуся интерфейсу loopback или 
          автоматически созданную конфигурацию присутствующего
          в устройстве оборудования.";
     }

     identity learned {
       base origin;
       description
         "Конфигурация, полученная из протокольных взаимодействий с
          другими устройствами, а не из хранилища intended или иного
          хранилища динамической конфигурации.

          Примеры протоколов изучения конфигурации включают согласование
          на канальном уровне, протоколы маршрутизации и DHCP.";
     }

     identity default {
       base origin;
       description
         "Конфигурация, которая не была настроена или получена от
          протокола, а задана по умолчанию. Включает значения операторов
          default и значения, полученные из объяснений в операторах
          description.";
     }

     identity unknown {
       base origin;
       description
         "Конфигурация, для которой система не может узнать источник.";
     }

     /*
      * Определения типов
      */

     typedef origin-ref {
       type identityref {
         base origin;
       }
       description
         "Ссылка на идентификатор источника.";
     }

     /*
      * Аннотации метаданных
      */

     md:annotation origin {
       type origin-ref;
       description
         "Аннотация origin может присутствовать в любом узле данных
          конфигурации хранилища рабочего состояния. Она указывает,
          откуда взят узел. Если источник не указан для узла данных
          конфигурации, принимается источник родительского узла в
          дереве данных. Источник для узлов данных конфигурации 
          верхнего уровня должен указываться всегда.";
     }
   }

   <CODE ENDS>

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

8.1. Обновление реестра IETF XML Registry

Этот документ регистрирует два URI в реестре IETF XML Registry [RFC3688] в соответствии с форматом [RFC3688]

      URI: urn:ietf:params:xml:ns:yang:ietf-datastores
      Registrant Contact: The IESG.
      XML: N/A; the requested URI is an XML namespace.

      URI: urn:ietf:params:xml:ns:yang:ietf-origin
      Registrant Contact: The IESG.
      XML: N/A; the requested URI is an XML namespace.

8.2. Обновление реестра YANG Module Names Registry

Документ регистрирует два модуля YANG в реестре YANG Module Names [RFC6020] в соответствии с [RFC6020]

      name:         ietf-datastores
      namespace:    urn:ietf:params:xml:ns:yang:ietf-datastores
      prefix:       ds
      reference:    RFC 8342

      name:         ietf-origin
      namespace:    urn:ietf:params:xml:ns:yang:ietf-origin
      prefix:       or
      reference:    RFC 8342

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

В этом документе обсуждается архитектурная модель для хранилищ данных сетевого управления, используемых протоколами NETCONF/RESTCONF и языком YANG. Это не оказывает влияния на безопасность Internet.

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

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

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

10.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>.

[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>.

[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>.

[RFC7952] Lhotka, L., “Defining and Using Metadata with YANG”, RFC 7952, DOI 10.17487/RFC7952, August 2016, <https://www.rfc-editor.org/info/rfc7952>.

[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>.

[W3C.REC-xml-20081126] Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and F. Yergeau, “Extensible Markup Language (XML) 1.0 (Fifth Edition)”, World Wide Web Consortium Recommendation REC-xml-20081126, November 2008, <https://www.w3.org/TR/2008/REC-xml-20081126>.

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

[NETMOD-Operational] Bjorklund, M. and L. Lhotka, “Operational Data in NETCONF and YANG”, Work in Progress, draft-bjorklund-netmod-operational-00, October 2012.

[OpState-Enhance] Watsen, K., Bierman, A., Bjorklund, M., and J. Schoenwaelder, “Operational State Enhancements for YANG, NETCONF, and RESTCONF”, Work in Progress, draft-kwatsen-netmod-opstate-02, February 2016.

[OpState-Modeling] Shakir, R., Shaikh, A., and M. Hines, “Consistent Modeling of Operational State Data in YANG”, Work in Progress, draft-openconfig-netmod-opstate-01, July 2015.

[OpState-Reqs] Watsen, K. and T. Nadeau, “Terminology and Requirements for Enhanced Handling of Operational State”, Work in Progress, draft-ietf-netmod-opstate-reqs-04, January 2016.

[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>.

[RFC6244] Shafer, P., “An Architecture for Network Management Using NETCONF and YANG”, RFC 6244, DOI 10.17487/RFC6244, June 2011, <https://www.rfc-editor.org/info/rfc6244>.

[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>.

[With-config-state] Wilton, R., “”With-config-state” Capability for NETCONF/RESTCONF”, Work in Progress, draft-wilton-netmod-opstate-yang-02, December 2015.

[YANG-SEC] IETF, “YANG Security Guidelines”, <https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines>.

Приложение A. Рекомендации по определению хранилищ

Определение нового хранилища в рамках данной архитектуры следует приводить в специальном документе (например, RFC). Когда это имеет смысл, в одном документе может определяться множество хранилищ (например, когда эти хранилища логически связаны). В определении каждого хранилища должны включать описанные ниже аспекты.

A.1. Определение модулей YANG, применимых для хранилища

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

A.2. Определение применимого подмножества операторов YANG

По умолчанию данные в хранилище моделируются с использованием всех операторов YANG в доступных модулях YANG. Однако возможно задание критериев, которым должны удовлетворять операторы YANG для включения в хранилище. Например, могут разрешаться только узлы config true или узлы config false, имеющие конкретное расширение YANG.

A.3. Определение способов актуализации данных

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

Например, рисунок 2 показывает хранилища динамической конфигурации, подаваемые в хранилище <operational>. Способ такой передачи определяет конкретным хранилищем динамической конфигурации. В некоторых случаях это может происходить неявно просто при попадании данных в хранилище динамической конфигурации, а в других случаях может потребоваться явное действие (например, RPC).

A.4. Определение применимых протоколов

По умолчанию предполагается что взаимодействие с хранилищами может выполняться с обоими протоколами NETCONF и RESTCONF. Однако можно задать использование лишь одного конкретного протокола (например, ForCES5), подмножества операций протокола или доступных возможностей (например, без блокировки или фильтрации по XPath).

A.5. Определение отождествлений YANG для хранилища

Хранилище должно быть определено с использованием отождествления YANG, использующего ds:datastore или одно из производных от него отождествлений. Это отождествление требуется, чтобы по по нему можно было ссылаться на хранилище в операциях протокола (например, <get-data>).

Хранилище может быть также определено с использованием в качестве базы отождествления or:origin или производного от него отождествления. Такое отождествление требуется, если хранилище взаимодействует с <operational>, чтобы по нему можно указать хранилище в атрибуте метаданных origin, определённом в разделе 7.

Примеры использования этих рекомендаций приведены в Приложении B.

Приложение B. Пример эфемерного хранилища

В этом приложении описаны примеры хранилища динамической конфигурации с использованием рекомендаций из Приложения A. Для краткости представлен сокращённый пример, предполагается что будет выпущен отдельный документ RFC с полным описанием.

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

Свойства примера «эфемерного» хранилища.

Имя

Значение

Name

ephemeral

YANG modules

all (default)

YANG nodes

all “config true” data nodes

How applied

changes automatically propagated to <operational>

Protocols

NETCONF/RESTCONF (default)

Defining YANG module

“example-ds-ephemeral”

 
   module example-ds-ephemeral {
     yang-version 1.1;
     namespace "urn:example:ds-ephemeral";
     prefix eph;

     import ietf-datastores {
       prefix ds;
     }
     import ietf-origin {
       prefix or;
     }

     // Идентификатор хранилища данных
     identity ds-ephemeral {
       base ds:dynamic;
       description
         "Эфемерное хранилище динамической конфигурации.";
     }

     // Идентификатор источника
     identity or-ephemeral {
       base or:dynamic;
       description
         "Данные из эфемерного хранилища динамической конфигурации.";
     }
   }

Приложение C. Примеры

Использование хранилищ является сложной задачей и многие тонкие эффекты проще показать на примерах. В этом приложении представлена серия примеров моделей данных с некоторым содержимым различных хранилищ.

Фрагменты XML [W3C.REC-xml-20081126] представлены лишь для иллюстрации.

C.1. Пример хранилища System

Ниже показан используемый в примере функциональный модуль.

   module example-system {
     yang-version 1.1;
     namespace urn:example:system;
     prefix sys;

     import ietf-inet-types {
       prefix inet;
     }

     container system {
       leaf hostname {
         type string;
       }

       list interface {
         key name;

         leaf name {
           type string;
         }

         container auto-negotiation {
           leaf enabled {
             type boolean;
             default true;
           }
           leaf speed {
             type uint32;
             units mbps;
             description
               "Аносируемая скорость в Мбит/с.";
           }
         }

         leaf speed {
           type uint32;
           units mbps;
           config false;
           description
             "Скорость интерфейса в Мбит/с .";
         }

         list address {
           key ip;

           leaf ip {
             type inet:ip-address;
           }
           leaf prefix-length {
             type uint8;
           }
         }
       }
     }
   }

Оператор настроил имя хоста и два интерфейса и хранилище <intended> имеет вид

   <system xmlns="urn:example:system">

     <hostname>foo.example.com</hostname>

     <interface>
       <name>eth0</name>
       <auto-negotiation>
         <speed>1000</speed>
       </auto-negotiation>
       <address>
         <ip>2001:db8::10</ip>
         <prefix-length>64</prefix-length>
       </address>
     </interface>

     <interface>
       <name>eth1</name>
       <address>
         <ip>2001:db8::20</ip>
         <prefix-length>64</prefix-length>
       </address>
     </interface>

   </system>

Система обнаружила, что аппаратная часть одного из настроенных интерфейсов (eth1) ещё отсутствует, поэтому настройка данного интерфейса не была применена. После этого система получила имя хоста и дополнительный адрес IP для eth0 по протоколу DHCP. В дополнение к установке принятого по умолчанию значения для листа управления автоматическим согласованием (auto-negotiation) в системе также автоматически создан интерфейс loopback. Все упомянутое нашло отражение в хранилище <operational>. Отметим, что атрибут метаданных origin для некоторых узлов данных config true унаследован от их родителей.

   <system
       xmlns="urn:example:system"
       xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin">

     <hostname or:origin="or:learned">bar.example.com</hostname>

     <interface or:origin="or:intended">
       <name>eth0</name>
       <auto-negotiation>
         <enabled or:origin="or:default">true</enabled>
         <speed>1000</speed>
       </auto-negotiation>
       <speed>100</speed>
       <address>
         <ip>2001:db8::10</ip>
         <prefix-length>64</prefix-length>
       </address>
       <address or:origin="or:learned">
         <ip>2001:db8::1:100</ip>
         <prefix-length>64</prefix-length>
       </address>
     </interface>

     <interface or:origin="or:system">
       <name>lo0</name>
       <address>
         <ip>::1</ip>
         <prefix-length>128</prefix-length>
       </address>
     </interface>

   </system>

C.2. Пример BGP

Рассмотрим фрагмент функционального модуля BGP

       container bgp {
         leaf local-as {
           type uint32;
         }
         leaf peer-as {
           type uint32;
         }
         list peer {
           key name;
           leaf name {
             type inet:ip-address;
           }
           leaf local-as {
             type uint32;
             description
               "... По умолчанию ../local-as.";
           }
           leaf peer-as {
             type uint32;
             description
               "... По умолчанию ../peer-as.";
           }
           leaf local-port {
             type inet:port;
           }
           leaf remote-port {
             type inet:port;
             default 179;
           }
           leaf state {
             config false;
             type enumeration {
               enum init;
               enum established;
               enum closing;
             }
           }
         }
       }

В этой модели оба узла bgp/peer/local-as и bgp/peer/peer-as имеют комплексные иерархические значения, позволяя пользователю задать используемые по умолчанию значения для всех партнёров в одном месте.

Модель также следует шаблону полного объединения узлов состояния (config false) и узлов конфигурации (config true). Здесь нет отдельной иерархии bgp-state и связанного с ней повтора узлов сдерживания ограничений и именования. Это делает модель более простой и удобочитаемой.

C.2.1. Хранилища данных

Каждое хранилище даёт разные представления этих узлов. Хранилище <running> будет содержать конфигурацию, заданную оператором (например, один партнёр BGP). Хранилище <intended> концептуально будет содержать все проверенные на пригодность данные после исключения не предназначенных для такой проверки данных и выполнения всех локальных механизмов преобразования шаблонов. Хранилище <operational> будет показывать данные из <intended>, а также все узлы config false.

C.2.2. Добавление партнёра

Если оператор указал одного партнёра BGP, этот партнёр будет виден в обоих хранилищах <running> и <intended>. Он может также присутствовать в <candidate>, если сервер поддерживает хранилище для будущих конфигураций. Поиск партнёра будет возвращать только заданные пользователем значения.

Между появлением партнёра в хранилищах <running> и <intended> не должно быть задержки.

Добавим в хранилище <running> представленную ниже информацию.

     <bgp>
       <local-as>64501</local-as>
       <peer-as>64502</peer-as>
       <peer>
         <name>2001:db8::2:3</name>
       </peer>
     </bgp>
C.2.2.1. Хранилище <operational>

Операционное хранилище будет содержать полностью раскрытые данные партнёра, включая узлы config false. В нашем примере это означает появление узла state.

Кроме того, хранилище <operational> будет содержать реально используемые (currently in use) значения для всех узлов. Это значит, что local-as и peer-as будут заполнены даже в том случае, когда их значения не заданы в <intended>. При отсутствии bgp/peer/local-as будет использовано значение bgp/local-as, а при отсутствии bgp/peer/peer-as – bgp/peer-as. В операционном представлении это означает, что каждый партнёр будет иметь значения для своих local-as и peer-as, даже если эти значения не будут заданы явно, но будут представлены в bgp/local-as и bgp/peer-as.

Каждый из партнёров BGP имеет связанное с ним соединение TCP, использующее значения local-port и remote-port из <intended>. Если эти значения не представлены, они будут выбраны системой. После организации соединения хранилище <operational> будет содержать текущие значения для local-port и remote-port, независимо от их происхождения. Если значения выбраны системой, атрибут origin будет указывать system. Перед организацией соединения один или оба узла могут отсутствовать, поскольку система может ещё не иметь их значений.

     <bgp xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"
          or:origin="or:intended">
       <local-as>64501</local-as>
       <peer-as>64502</peer-as>
       <peer>
         <name>2001:db8::2:3</name>
         <local-as or:origin="or:default">64501</local-as>
         <peer-as or:origin="or:default">64502</peer-as>
         <local-port or:origin="or:system">60794</local-port>
         <remote-port or:origin="or:default">179</remote-port>
         <state>established</state>
       </peer>
     </bgp>

C.2.3. Удаление партнёра

При изменении конфигурации может потребоваться время на прохождение этих изменений через вовлечённые в процесс программные компоненты. В этом интервале времени необходимо сохранять точное представление о работе устройства. Хранилище <operational> будет содержать узлы предыдущей и текущей конфигурации, насколько возможно точно отслеживая текущее операционное состояние устройства.

Рассмотрим сценарий с удалением партнёра BGP. В этом случае операционное состояние будет по-прежнему отражать наличие этого партнёра до тех пор, пока не будут освобождены ресурсы закрываемого партнерского соединения. В течение переходного периода текущие значения данных будут видны в хранилище <operational> с атрибутом origin, указывающим происхождение исходных данных.

     <bgp xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"
          or:origin="or:intended">
       <local-as>64501</local-as>
       <peer-as>64502</peer-as>
       <peer>
         <name>2001:db8::2:3</name>
         <local-as or:origin="or:default">64501</local-as>
         <peer-as or:origin="or:default">64502</peer-as>
         <local-port or:origin="or:system">60794</local-port>
         <remote-port or:origin="or:default">179</remote-port>
         <state>closing</state>
       </peer>
     </bgp>

После освобождения ресурсов и закрытия соединения данные о партнёре удаляются из хранилища <operational>.

C.3. Пример интерфейса

В этом параграфе используется простая модель данных интерфейса.

     container interfaces {
       list interface {
         key name;
         leaf name {
           type string;
         }
         leaf description {
           type string;
         }
         leaf mtu {
           type uint16;
         }
         leaf-list ip-address {
           type inet:ip-address;
         }
       }
     }

C.3.1. Заранее представленные интерфейсы

Одной из проблем сетевых устройств является поддержка сменных узлов (FRU6), которые могут добавляться и удаляться из устройства без его перезагрузки и нарушения нормальной работы. Эти FRU обычно являются интерфейсными модулями (платами) и устройства поддерживают упреждающее представление этих интерфейсов.

Если клиент создаёт интерфейс et-0/0/0, которого в этот момент нет физически, хранилище <intended> может содержать представленную ниже информацию.

     <interfaces>
       <interface>
         <name>et-0/0/0</name>
         <description>Тестовый интерфейс</description>
       </interface>
     </interfaces>

Поскольку интерфейса нет, эти данные не будут присутствовать в хранилище <operational>.

При установке FRU с этим интерфейсом система обнаружит его и обработает соответствующую конфигурацию. Хранилище <operational> будет содержать данные из <intended>, а также узлы, добавленные системой типа текущего значения MTU для интерфейса.

     <interfaces xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"
                 or:origin="or:intended">
       <interface>
         <name>et-0/0/0</name>
         <description>Тестовый интерфейс</description>
         <mtu or:origin="or:system">1500</mtu>
       </interface>
     </interfaces>

Если FRU удаляется, данные интерфейса исключаются из хранилища <operational>.

C.3.2. Предоставляемые системой интерфейсы

Рассмотрим систему, предоставляющую петлевой интерфейс lo0 с принятым по умолчанию адресом IPv4 127.0.0.1 и IPv6 ::1. Система будет обеспечивать конфигурацию для этого интерфейса, если для него нет данных в <intended>.

При отсутствии конфигурации для lo0 в хранилище <intended>, <operational> будет показывать предоставляемые системой данные.

     <interfaces xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"
                 or:origin="or:intended">
       <interface or:origin="or:system">
         <name>lo0</name>
         <ip-address>127.0.0.1</ip-address>
         <ip-address>::1</ip-address>
       </interface>
     </interfaces>

Если конфигурация для lo0 имеется в <intended>, хранилище <operational> будет показывать эти данные с источником intended. Если значение ip-address не было задано, предоставленные системой значения будут иметь вид

     <interfaces xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"
                 or:origin="or:intended">
       <interface>
         <name>lo0</name>
         <description>loopback</description>
         <ip-address or:origin="or:system">127.0.0.1</ip-address>
         <ip-address>::1</ip-address>
       </interface>
     </interfaces>

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

Этот документ является результатом многочисленных обсуждений, тянувшихся с 2010 года. Проблемы исходной модели хранилищ данных были рассмотрены в NETMOD-Operational] [With-config-state] [OpState-Reqs] [OpState-Enhance] [OpState-Modeling], а также [RFC6244]. Перечисленные ниже люди были авторами этих работ или внесли какой-либо иной вклад в создание этого документа.

Работа Juergen Schoenwaelder частично финансировалась в рамках Flamingo – проекта Network of Excellence (ICT-318488), поддерживаемого Европейской комиссией про программе Seventh Framework.

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

Martin Bjorklund

Tail-f Systems

Email: mbj@tail-f.com

Juergen Schoenwaelder

Jacobs University

Email: j.schoenwaelder@jacobs-university.de

Phil Shafer

Juniper Networks

Email: phil@juniper.net

Kent Watsen

Juniper Networks

Email: kwatsen@juniper.net

Robert Wilton

Cisco Systems

Email: rwilton@cisco.com 



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


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


nmalykh@protokols.ru




1Network Configuration Protocol – протокол настройки сети.






2Internet Engineering Task Force – комиссия по решению инженерных задач Internet.






3Internet Engineering Steering Group – комиссия по инженерным разработкам Internet.






4XML Path Language – язык путей XML.






5Forwarding and Control Element Separation – разделение элементов пересылки и управления.






6Field Replaceable Unit – заменяемый в процессе работы блок.



 											


		
						

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