Internet Engineering Task Force (IETF) S. Litkowski
Request for Comments: 9020 Cisco Systems
Category: Standards Track Y. Qu
ISSN: 2070-1721 Futurewei
A. Lindem
Cisco Systems
P. Sarkar
VMware, Inc
J. Tantsura
Juniper Networks
May 2021
YANG Data Model for Segment Routing
Модель данных YANG для маршрутизации по сегментам
Аннотация
Этот документ задаёт три модели YANG. Первая описывает конфигурацию и рабочее состояние для маршрутизации по сегментам (Segment Routing или SR) и будет дополняться для различных плоскостей данных SR. Вторая модель задаёт набор базовых типов и группировок для SR. Третья модель определяет конфигурацию и рабочее состояние для плоскости данных SR MPLS.
Статус документа
Документ относится к категории Internet Standards Track.
Документ является результатом работы IETF1 и представляет согласованный взгляд сообщества IETF. Документ прошёл открытое обсуждение и был одобрен для публикации IESG2. Дополнительную информацию о стандартах Internet можно найти в разделе 2 в RFC 7841.
Информация о текущем статусе документа, найденных ошибках и способах обратной связи доступна по ссылке https://www.rfc-editor.org/info/rfc9020.
Авторские права
Copyright (c) 2021. Авторские права принадлежат 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 [RFC7950]. Первая описывает конфигурацию и рабочее состояние для маршрутизации по сегментам (SR) [RFC8402]. Документ не задаёт расширений IGP для поддержки SR, но второй модуль определяет базовые группировки, которые могут применяться в таких модулях. Причина выбора состоит в том, чтбы избежать требования поддержки реализациями всех расширений IGP. Например, реализация может поддерживать расширение IS-IS, не поддерживая расширение OSPF. Третья модель данных YANG задаёт модуль для использования в элементах сети для настройки и эксплуатации плоскости данных SR MPLS [RFC8660].
Модули YANG в этом документе соответствуют архитектуре хранилищ данных управления сетью (Network Management Datastore Architecture или NMDA) [RFC8342].
2. Терминология и нотация
Ключевые слова должно (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не следует (SHALL NOT), следует (SHOULD), не нужно (SHOULD NOT), рекомендуется (RECOMMENDED), не рекомендуется (NOT RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с BCP 14 [RFC2119] [RFC8174] тогда и только тогда, когда они выделены шрифтом, как показано здесь.
2.1. Диаграммы деревьев
В диаграммах деревьев применяется нотация, заданная в [RFC8340].
2.2. Префиксы имён узлов данных
В этом документе имена узлов данных, действий и других объектов модели данных часто применяются без префиксов, если из контекста ясно, в каком модуле YANG определено каждое имя. При отсутствии такой ясности имена указываются со стандартными префиксами, связанными с соответствующими модулямиYANG (Таблица 1).
Таблица 1. Префиксы в модулях YANG.
|
Префикс |
Модуль YANG |
Документ |
|---|---|---|
|
if |
ietf-interfaces |
[RFC8343] |
|
rt |
ietf-routing |
[RFC8349] |
|
rt-types |
ietf-routing-types |
[RFC8294] |
|
yang |
ietf-yang-types |
[RFC6991] |
|
inet |
ietf-inet-types |
[RFC6991] |
3. Устройство модели данных
Модуль YANG ietf-segment-routing дополняет контейнер routing из модуля ietf-routing [RFC8349] и определяет базовое состояние настройки и работы SR. Этот модуль дополняется модулями для различных плоскостей данных.
Модуль ietf-segment-routing-mpls дополняет ietf-segment-routing и поддерживает конфигурацию и рабочее состояние плоскости данных SR-MPLS.
Модуль ietf-segment-routing-common задаёт базовые типы и группировки, которые следует применять в модулях расширения IGP.
module: ietf-segment-routing
augment /rt:routing:
+--rw segment-routing
module: ietf-segment-routing-mpls
augment /rt:routing/sr:segment-routing:
+--rw sr-mpls
+--rw bindings
| +--rw mapping-server {mapping-server}?
| | +--rw policy* [name]
| | +--rw name string
| | +--rw entries
| | +--rw mapping-entry* [prefix algorithm]
| | +--rw prefix inet:ip-prefix
| | +--rw value-type? enumeration
| | +--rw start-sid uint32
| | +--rw range? uint32
| | +--rw algorithm identityref
| +--rw connected-prefix-sid-map
| | +--rw connected-prefix-sid* [prefix algorithm]
| | +--rw prefix inet:ip-prefix
| | +--rw value-type? enumeration
| | +--rw start-sid uint32
| | +--rw range? uint32
| | +--rw algorithm identityref
| | +--rw last-hop-behavior? enumeration
| +--rw local-prefix-sid
| +--rw local-prefix-sid* [prefix algorithm]
| +--rw prefix inet:ip-prefix
| +--rw value-type? enumeration
| +--rw start-sid uint32
| +--rw range? uint32
| +--rw algorithm identityref
+--rw srgb
| +--rw srgb* [lower-bound upper-bound]
| +--rw lower-bound uint32
| +--rw upper-bound uint32
+--rw srlb
| +--rw srlb* [lower-bound upper-bound]
| +--rw lower-bound uint32
| +--rw upper-bound uint32
+--ro label-blocks* []
| +--ro lower-bound? uint32
| +--ro upper-bound? uint32
| +--ro size? uint32
| +--ro free? uint32
| +--ro used? uint32
| +--ro scope? enumeration
+--ro sid-db
+--ro sid* [target sid source source-protocol binding-type]
+--ro target string
+--ro sid uint32
+--ro algorithm? uint8
+--ro source inet:ip-address
+--ro used? boolean
+--ro source-protocol -> /rt:routing
/control-plane-protocols
/control-plane-protocol/name
+--ro binding-type enumeration
+--ro scope? enumeration
notifications:
+---n segment-routing-srgb-collision
| +--ro srgb-collisions* []
| +--ro lower-bound? uint32
| +--ro upper-bound? uint32
| +--ro routing-protocol? -> /rt:routing
| /control-plane-protocols
| /control-plane-protocol/name
| +--ro originating-rtr-id? router-or-system-id
+---n segment-routing-global-sid-collision
| +--ro received-target? string
| +--ro new-sid-rtr-id? router-or-system-id
| +--ro original-target? string
| +--ro original-sid-rtr-id? router-or-system-id
| +--ro index? uint32
| +--ro routing-protocol? -> /rt:routing
| /control-plane-protocols
| /control-plane-protocol/name
+---n segment-routing-index-out-of-range
+--ro received-target? string
+--ro received-index? uint32
+--ro routing-protocol? -> /rt:routing
/control-plane-protocols
/control-plane-protocol/name
4. Конфигурация
Модуль ietf-segment-routing-mpls дополняет /rt:routing/sr:segment-routing: контейнером sr-mpls, который определяет все параметры конфигурации, относящиеся к плоскости данных SR MPLS. Конфигурация sr-mpls разделена на глобальную и настройки интерфейсов. Глобальные настройки указаны ниже.
Bindings – привязки
Задают отображения префиксов на идентификаторы сегментов (Prefix-SID). Оператор может контролировать анонсы Prefix-SID независимо для IPv4 и IPv6. Поддерживается два типа отображений.Mapping-server – сервер отображения
Отображаются префиксы, которые не локальны для SID. Конфигурация привязок не разрешает автоматически их анонсирование, и оно должно контролироваться каждым экземпляром протокола маршрутизации (см. 5. Конфигурация плоскости управления IGP). Можно задать несколько правил отображения.Connected prefixes – подключенные префиксы
Подключенные префиксы отображаются на SID. Анонсы отображений будет выполняться IGP при включении SR (см. 5. Конфигурация плоскости управления IGP). SID можно указать индексом (принято по умолчанию) или абсолютным значением. Конфигурация last-hop-behavior диктует поведение предпоследнего узла пересылки MPLS (Penultimate Hop Popping или PHP) – explicit-null, php, non-php.Segment Routing Global Block (SRGB) – глобальный блок SR
Задаёт список блоков меток, представленных парой меток верхней и нижней границы. SRGB не зависит от используемой плоскости управления, поэтому все локальные экземпляры протокола маршрутизации будут анонсировать один и тот же SRGB.Segment Routing Local Block (SRLB) – локальный блок SR
Задаёт список блоков меток, представленных парой меток верхней и нижней границы, зарезервированных для локальных SID.5. Конфигурация плоскости управления IGP
Поддержка расширений SR для конкретной плоскости управления IGP достагается путём дополнения конфигурации протокола маршрутизации расширениями SR. Эти дополнениям следует быть частью модулей YANG для протоколов маршрутизации, чтобы не создавать для реализаций зависимости от поддержки расширений SR для всех протоколов.
Этот модуль задаёт группировки, которые следует использовать в модулях IGP SR. Группировка sr-control-plane определяет базовую глобальную конфигурацию для IGP. Лист enabled включает расширения SR для экземпляра протокола маршрутизации. Контейнер bindings управляет анонсами экземпляра протокола маршрутизации для локальных присвязок и обработкой полученных привязок.
5.1. Конфигурация интерфейса IGP
Конфигурация интерфейса является частью группировки igp-interface и включает свойства SID-смежности (Adj-SID).
5.1.1. Свойства SID-смежности (Adj-SID)
5.1.1.1. Привязка
При наличии параллельных каналов IP между маршрутизаторами могут анонсироваться дополнительные Adj-SID [RFC8402], представляющие более 1 смежности (т. е. группу смежностей). Конфигурация advertise-adj-group-sid управляет анонсированием таких дополнительных Adj-SID. Список advertise-adj-group-sid представляет групповые идентификаторы, каждый из которых указывает собранные вместе интерфейсы.
+-------+ +------+ | | ------- L1 ---- | | | R1 | ------- L2 ---- | R2 | | | ------- L3 ---- | | | | ------- L4 ---- | | +-------+ +------+
На рисунке маршрутизаторы R1 и R2 соединены 4 каналами, на каждом из которых установлена маршрутная смежность. Оператор хочет создать Adj-SID, представляющие группы (bundle) каналов. Можно представить две разных группы – L1/L2 и L3/L4. Для этого оператор может настроить group-id X для интерфейсов L1 и L2 и group-id Y для L3 и L4. В результате R1 анонсирует дополнительный Adj-SID для каждой смежности. Например, Adj-SID со значением 400 будет добавлен к L1 и L2, а Adj-SID 500 – к L3 и L4. Поскольку L1/L2 и L3/L4 не используют общий group-id, выделены разные значения SID.
5.1.1.2. Защита
Лист advertise-protection определяет анонсирование защиты для интерфейса, но не включает и не отключает эту защиту. При использовании варианта single для интерфейса будет анонсироваться 1 Adj-SID. Если интерфейс защищён, для Adj-SID будет установлен B-Flag. Если выбран вариант dual и интерфейс защищён, для смежности интерфейсов бедет анонсироваться 2 Adj-SID, в одном из которых B-Flag установлен, в другом сброшен. Этот вариант предназначен для случая организации трафика, когда путь должен использовать защищённые, либо незащищённые сегменты.
6. Данные состояния
Сведения рабочего состояния отражают использование выделенных меток SRGB, а также список всех глобальных SID, связанных с ними привязок и другую информацию, такую как связанный протокол и алгоритм.
7. Уведомления
Модель определяет указанные ниже уведомления для SR.
segment-routing-srgb-collision
Передаётся при возникновении кнфликта анонсируемых плоскостью управления блоков SRGB.segment-routing-global-sid-collision
Передаётся, когда индекс, анонсируемый плоскостью управления, уже применяется с другой целью (в этой версии целями являются только префиксы IPv4 и IPv6).segment-routing-index-out-of-range
Передаётся, когда индекс, анонсируемый плоскостью управления, выходит из диапазона SRGB, настроенного для сетевого устройства.8. Модули YANG
В этот документ включены три модуля YANG.
В тексте документа не указаны, но упоминаются в модулях ietf-segment-routing.yang, ietf-segment-routing-common.yang, ietf-segment-routing-mpls.yang [RFC6991], [RFC8294], [RFC8661], [RFC8665], [RFC8667], [RFC8669], [RFC8814].
8.1. Модуль YANG для SR
Модуль ietf-segment-routing.yang задаёт базовую схему для SR и дополняется моделями для разных плоскостей данных SR.
<CODE BEGINS> file "ietf-segment-routing@2021-05-26.yang"
module ietf-segment-routing {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-segment-routing";
prefix sr;
import ietf-routing {
prefix rt;
reference "RFC 8349: A YANG Data Model for Routing
Management (NMDA Version)";
}
organization
"IETF SPRING - SPRING Working Group";
contact
"WG Web: <https://datatracker.ietf.org/wg/spring/>
WG List: <mailto:spring@ietf.org>
Author: Stephane Litkowski
<mailto:slitkows.ietf@gmail.com>
Author: Yingzhen Qu
<mailto:yingzhen.qu@futurewei.com>
Author: Acee Lindem
<mailto:acee@cisco.com>
Author: Pushpasis Sarkar
<mailto:pushpasis.ietf@gmail.com>
Author: Jeff Tantsura
<jefftant.ietf@gmail.com>
";
description
"Этот модуль YANG задаёт базовую модель для SR. Он будет
дполняться моделями для разных плоскостей данных SR.
Модуль соответствует архитектуре NMDA, описанной в RFC 8242.
Ключевые слова ДОЛЖНО, НЕДОПУСТИМО, ТРЕБУЕТСЯ, НУЖНО, НЕ НУЖНО,
СЛЕДУЕТ, НЕ СЛЕДУЕТ, РЕКОМЕНДУЕТСЯ, НЕ РЕКОМЕНДУЕТСЯ, МОЖНО,
НЕОБЯЗАТЕЛЬНО в этом документе трактуются в соответствии с
BCP 14 (RFC 2119) (RFC 8174) тогда и только тогда, когда они
указаны заглавными буквами, как показано здесь.
Авторские права (Copyright (c) 2021) принадлежат IETF Trust и
лицам, указанным как авторы. Все права защищены.
Распространение и применение модуля в исходной или двоичной
форме с изменениями или без таковых разрешено в соответствии с
лицензией Simplified BSD License, изложенной в параграфе 4.c
IETF Trust's Legal Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info).
Эта версия модуля YANG является частью RFC 9020, где правовые
аспекты приведены более полно.";
reference
"RFC 9020: YANG Data Model for Segment Routing.";
revision 2021-05-26 {
description
"Исходный выпуск";
reference
"RFC 9020: YANG Data Model for Segment Routing.";
}
augment "/rt:routing" {
description
"Этот модуль дополняет модель данных маршрутизации (RFC 8349)
маршрутизацией по сегментам (Segment Routing или SR).";
container segment-routing {
description
"Конфигурация SR. Этот контейнер будет дополняться моделями
для разных плоскостей данных SR.";
reference
"RFC 8402: Segment Routing Architecture.";
}
}
}
<CODE ENDS>
8.2. Модуль YANG для базовых типов SR
Модуль ietf-segment-routing-common.yang определяет набор базовых типов и группировок для SR, заданной [RFC8402].
<CODE BEGINS> file "ietf-segment-routing-common@2021-05-26.yang"
module ietf-segment-routing-common {
yang-version 1.1;
namespace
"urn:ietf:params:xml:ns:yang:ietf-segment-routing-common";
prefix sr-cmn;
import ietf-inet-types {
prefix inet;
reference
"RFC 6991: Common YANG Data Types";
}
organization
"IETF SPRING - SPRING Working Group";
contact
"WG Web: <https://datatracker.ietf.org/wg/spring/>
WG List: <mailto:spring@ietf.org>
Author: Stephane Litkowski
<mailto:slitkows.ietf@gmail.com>
Author: Yingzhen Qu
<mailto:yingzhen.qu@futurewei.com>
Author: Acee Lindem
<mailto:acee@cisco.com>
Author: Pushpasis Sarkar
<mailto:pushpasis.ietf@gmail.com>
Author: Jeff Tantsura
<jefftant.ietf@gmail.com>
";
description
"Этот модуль YANG определяет набор базовых типов и группировок
для маршрутизации по сегментам (SR), описанной в RFC 8402.
Модуль соответствует архитектуре NMDA, описанной в RFC 8242.
Ключевые слова ДОЛЖНО, НЕДОПУСТИМО, ТРЕБУЕТСЯ, НУЖНО, НЕ НУЖНО,
СЛЕДУЕТ, НЕ СЛЕДУЕТ, РЕКОМЕНДУЕТСЯ, НЕ РЕКОМЕНДУЕТСЯ, МОЖНО,
НЕОБЯЗАТЕЛЬНО в этом документе трактуются в соответствии с
BCP 14 (RFC 2119) (RFC 8174) тогда и только тогда, когда они
указаны заглавными буквами, как показано здесь.
Авторские права (Copyright (c) 2021) принадлежат IETF Trust и
лицам, указанным как авторы. Все права защищены.
Распространение и применение модуля в исходной или двоичной
форме с изменениями или без таковых разрешено в соответствии с
лицензией Simplified BSD License, изложенной в параграфе 4.c
IETF Trust's Legal Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info).
Эта версия модуля YANG является частью RFC 9020, где правовые
аспекты приведены более полно.";
reference
"RFC 9020: YANG Data Model for Segment Routing";
revision 2021-05-26 {
description
"Исходный выпуск";
reference
"RFC 9020: YANG Data Model for Segment Routing";
}
feature sid-last-hop-behavior {
description
"Настраиваемое поведение last-hop.";
reference
"RFC 8660: Segment Routing with the MPLS Data Plane";
}
identity prefix-sid-algorithm {
description
"Базовый идентификатор для алгоритма prefix-sid.";
reference
"RFC 8402: Segment Routing Architecture";
}
identity prefix-sid-algorithm-shortest-path {
base prefix-sid-algorithm;
description
"Алгоритм SPF Prefix-SID (принят по умолчанию).";
}
identity prefix-sid-algorithm-strict-spf {
base prefix-sid-algorithm;
description
"Этот алгоритм требует пересылки пакетов в соответствии
с алгоритмом SPF, поддерживающим ECMP.";
}
grouping srlr {
description
"Группировка для конфигурации SR Label Range.";
leaf lower-bound {
type uint32;
description
"Нижнее значение диапазона меток.";
}
leaf upper-bound {
type uint32;
must '../lower-bound < ../upper-bound' {
error-message
"Значение upper-bound должно быть больше lower-bound.";
description
"Значение должно быть больше чем lower-bound.";
}
description
"Верхнее значение диапазона меток.";
}
}
grouping srgb {
description
"Группировка для SR Global Label Range.";
list srgb {
key "lower-bound upper-bound";
ordered-by user;
description
"Список глобальных блоков для анонсирования.";
uses srlr;
}
}
grouping srlb {
description
"Группировка для SR Local Block Range.";
list srlb {
key "lower-bound upper-bound";
ordered-by user;
description
"Список SRLB.";
uses srlr;
}
}
grouping sid-value-type {
description
"Задаёт способ представления SID.";
leaf value-type {
type enumeration {
enum index {
description
"Значение будет интерпретироваться как индекс.";
}
enum absolute {
description
"Абсолютное значение.";
}
}
default "index";
description
"Этот лист задаёт интерпретацию значений.";
}
}
grouping prefix-sid {
description
"Задаёт конфигурацию Prefix-SID.";
leaf prefix {
type inet:ip-prefix;
description
"Подключённый Prefix-SID.";
}
uses prefix-sid-attributes;
}
grouping ipv4-sid {
description
"Группировка для IPv4 Prefix-SID.";
leaf prefix {
type inet:ipv4-prefix;
description
"Подключённый IPv4 Prefix-SID.";
}
uses prefix-sid-attributes;
}
grouping ipv6-sid {
description
"Группировка для IPv6 Prefix-SID.";
leaf prefix {
type inet:ipv6-prefix;
description
"Подключённый IPv6 Prefix-SID.";
}
uses prefix-sid-attributes;
}
grouping last-hop-behavior {
description
"Задаёт поведение last-hop.";
leaf last-hop-behavior {
if-feature "sid-last-hop-behavior";
type enumeration {
enum explicit-null {
description
"использовать explicit-null для SID.";
}
enum no-php {
description
"Не применять MPLS PHP для SID.";
}
enum php {
description
"Применять MPLS PHP для SID.";
}
}
description
"Настройка поведения last-hop.";
}
}
grouping prefix-sid-attributes {
description
"Группировка для атрибутов префикса SR.";
uses sid-value-type;
leaf start-sid {
type uint32;
mandatory true;
description
"Значение, связанное с префиксом, которое должно
интерпретироваться в контексте sid-value-type.";
}
leaf range {
type uint32;
description
"Указывает, сколько SID можно выделить.";
}
leaf algorithm {
type identityref {
base prefix-sid-algorithm;
}
description
"Алгоритм Prefix-SID.";
}
}
}
<CODE ENDS>
8.3. Модуль YANG для SR MPLS
Модуль ietf-segment-routing-mpls.yang определяет конфигурацию и рабочее состояние для плоскости данных SR MPLS.
<CODE BEGINS> file "ietf-segment-routing-mpls@2021-05-26.yang"
module ietf-segment-routing-mpls {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-segment-routing-mpls";
prefix sr-mpls;
import ietf-inet-types {
prefix inet;
reference
"RFC 6991: Common YANG Data Types";
}
import ietf-routing {
prefix rt;
reference
"RFC 8349: A YANG Data Model for Routing
Management (NMDA Version)";
}
import ietf-routing-types {
prefix rt-types;
reference
"RFC 8294: Common YANG Data Types for the
Routing Area";
}
import ietf-segment-routing {
prefix sr;
reference
"RFC 9020: YANG Data Model for Segment Routing";
}
import ietf-segment-routing-common {
prefix sr-cmn;
reference
"RFC 9020: YANG Data Model for Segment Routing";
}
organization
"IETF SPRING - SPRING Working Group";
contact
"WG Web: <https://datatracker.ietf.org/wg/spring/>
WG List: <mailto:spring@ietf.org>
Author: Stephane Litkowski
<mailto:slitkows.ietf@gmail.com>
Author: Yingzhen Qu
<mailto:yingzhen.qu@futurewei.com>
Author: Acee Lindem
<mailto:acee@cisco.com>
Author: Pushpasis Sarkar
<mailto:pushpasis.ietf@gmail.com>
Author: Jeff Tantsura
<jefftant.ietf@gmail.com>
";
description
"Этот модуль YANG определяет базовую модель конфигурации для
плоскости данных SR MPLS.
Модуль соответствует архитектуре NMDA, описанной в RFC 8242.
Ключевые слова ДОЛЖНО, НЕДОПУСТИМО, ТРЕБУЕТСЯ, НУЖНО, НЕ НУЖНО,
СЛЕДУЕТ, НЕ СЛЕДУЕТ, РЕКОМЕНДУЕТСЯ, НЕ РЕКОМЕНДУЕТСЯ, МОЖНО,
НЕОБЯЗАТЕЛЬНО в этом документе трактуются в соответствии с
BCP 14 (RFC 2119) (RFC 8174) тогда и только тогда, когда они
указаны заглавными буквами, как показано здесь.
Авторские права (Copyright (c) 2021) принадлежат IETF Trust и
лицам, указанным как авторы. Все права защищены.
Распространение и применение модуля в исходной или двоичной
форме с изменениями или без таковых разрешено в соответствии с
лицензией Simplified BSD License, изложенной в параграфе 4.c
IETF Trust's Legal Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info).
Эта версия модуля YANG является частью RFC 9020, где правовые
аспекты приведены более полно.";
reference
"RFC 9020: YANG Data Model for Segment Routing";
revision 2021-05-26 {
description
"Исходный выпуск";
reference
"RFC 9020: YANG Data Model for Segment Routing";
}
feature mapping-server {
description
"Поддержка сервера отображения SR (SRMS).";
reference
"RFC 8661: Segment Routing MPLS Interworking
with LDP";
}
feature protocol-srgb {
description
"Поддержка конфигурации SRGB по протоколам.";
reference
"RFC 8660: Segment Routing with the MPLS
Data Plane";
}
typedef system-id {
type string {
pattern '[0-9A-Fa-f]{4}\.[0-9A-Fa-f]{4}\.[0-9A-Fa-f]{4}';
}
description
"Этот тип задаёт IS-IS system-id с использованием шаблона,
например, system-id 0143.0438.AEF0.";
}
typedef router-or-system-id {
type union {
type rt-types:router-id;
type system-id;
}
description
"OSPF/BGP router-id или IS-IS system ID.";
}
grouping sr-control-plane {
description
"Определяет конфигурацию протокола.";
container segment-routing {
description
"Глобальная конфигурация SR.";
leaf enabled {
type boolean;
default "false";
description
"Разрешает расширения протокола плоскости управления SR.";
}
container bindings {
if-feature "mapping-server";
description
"Управляет анонсированием и получением привязок.";
container advertise {
description
"Управляет анонсированием локальных отображений
в TLV привязок.";
leaf-list policies {
type leafref {
path "/rt:routing/sr:segment-routing/sr-mpls:sr-mpls"
+ "/sr-mpls:bindings/sr-mpls:mapping-server"
+ "/sr-mpls:policy/sr-mpls:name";
}
description
"List of binding advertisement policies.";
}
}
leaf receive {
type boolean;
default "true";
description
"Разрешает получать и применять TLV привязок.";
}
}
}
}
grouping igp-interface {
description
"Группировка для конфигурации интерфейса IGP.";
container segment-routing {
description
"Контейнер для конфигурации интерфейса SR.";
container adjacency-sid {
description
"Конфигурация SID-смежности (Adj-SID).";
reference
"RFC 8660: Segment Routing with the MPLS
Data Plane";
list adj-sids {
key "value";
uses sr-cmn:sid-value-type;
leaf value {
type uint32;
description
"Значение Adj-SID.";
}
leaf protected {
type boolean;
default "false";
description
"Применяется для защиты Adj-SID, например, применения
IP Fast Reroute (IPFRR) или MPLS-FRR.";
}
leaf weight {
type uint8;
description
"Коэффициент распределения нагрузки между параллельными
смежностями.";
reference
"RFC 8402: Segment Routing Architecture
RFC 8665: OSPF Extensions for Segment Routing
RFC 8667: IS-IS Extensions for Segment
Routing";
}
description
"Список Adj-SID и их конфигурация.";
}
list advertise-adj-group-sid {
key "group-id";
description
"Управляет анонсированием S-flag или G-flag. Включает
анонсирование общего Adj-SID для параллельных каналов.";
reference
"RFC 8665: OSPF Extensions for Segment Routing,
Section 6.1
RFC 8667: IS-IS Extensions for Segment
Routing, Section 2.2.1";
leaf group-id {
type uint32;
description
"Внутреннее значение для идентификации group-ID.
Интерфейсы с одним group-ID будут сгруппированы.";
}
}
leaf advertise-protection {
type enumeration {
enum single {
description
"Один Adj-SID связывается со смежностью и отражает
конфигурацию защиты.";
}
enum dual {
description
"2 Adj-SID связываются со смежностью, если интерфейс
защищен. В этом случае 1 Adj-SID анонсируется с
флагом резервирования (backup), а у другого этот
флаг будет сброшен. Если защита не настроена, будет
анонсироваться 1 Adj-SID со сброшенным флагом.";
}
}
description
"Если установлено, Adj-SID указывает защищённую
смежность.";
reference
"RFC 8665: OSPF Extensions for Segment Routing,
Section 6.1
RFC 8667: IS-IS Extensions for Segment
Routing, Section 2.2.1";
}
}
}
}
augment "/rt:routing/sr:segment-routing" {
description
"Дополняет модель данных маршрутизации (RFC 8349)
маршрутизацией SR с плоскостью данных MPLS.";
container sr-mpls {
description
"Глобальная конфигурация и рабочее состояние SR.";
container bindings {
description
"Список привязок.";
container mapping-server {
if-feature "mapping-server";
description
"Конфигурация локальных записей сервера отображения.";
list policy {
key "name";
description
"Список правил сервера отображения.";
leaf name {
type string;
description
"Имя политики отображения.";
}
container entries {
description
"Записи отображений IPv4/IPv6.";
list mapping-entry {
key "prefix algorithm";
description
"Записи отображений.";
uses sr-cmn:prefix-sid;
}
}
}
}
container connected-prefix-sid-map {
description
"Конфигурация Prefix-SID.";
list connected-prefix-sid {
key "prefix algorithm";
description
"Список отображений Prefix-SID на локальные
префиксы IPv4/IPv6.";
uses sr-cmn:prefix-sid;
uses sr-cmn:last-hop-behavior;
}
}
container local-prefix-sid {
description
"Конфигурация локальных SID.";
list local-prefix-sid {
key "prefix algorithm";
description
"Список локальных IPv4/IPv6 Prefix-SID.";
uses sr-cmn:prefix-sid;
}
}
}
container srgb {
description
"Конфигурация глобальных SRGB.";
uses sr-cmn:srgb;
}
container srlb {
description
"Конфигурация локального блока SR (SRLB).";
uses sr-cmn:srlb;
}
list label-blocks {
config false;
description
"Список используемых сейчас блоков меток.";
leaf lower-bound {
type uint32;
description
"Нижняя граница блока меток.";
}
leaf upper-bound {
type uint32;
description
"Верхняя граница блока меток .";
}
leaf size {
type uint32;
description
"Число индексов в блоке.";
}
leaf free {
type uint32;
description
"Число свободных индексов в блоке.";
}
leaf used {
type uint32;
description
"Число использованных индексов в блоке.";
}
leaf scope {
type enumeration {
enum global {
description
"Глобальный SID.";
}
enum local {
description
"Локальный SID.";
}
}
description
"Область действия этого блока меток.";
}
}
container sid-db {
config false;
description
"Список префиксов и ассоциаций SID.";
list sid {
key "target sid source source-protocol binding-type";
ordered-by system;
description
"Привязка SID.";
leaf target {
type string;
description
"Цель привязки (префикс или что-то иное).";
}
leaf sid {
type uint32;
description
"Индекс, связанный с префиксом.";
}
leaf algorithm {
type uint8;
description
"Алгоритм для использования с Prefix-SID.";
reference
"RFC 8665: OSPF Extensions for Segment Routing
RFC 8667: IS-IS Extensions for Segment
Routing
RFC 8669: Segment Routing Prefix Segment
Identifier Extensions to BGP";
}
leaf source {
type inet:ip-address;
description
"IP-адрес маршрутизатора, владеющего привязкой.";
}
leaf used {
type boolean;
description
"Указывает, установлены ли привязки в плоскости
пересылки.";
}
leaf source-protocol {
type leafref {
path "/rt:routing/rt:control-plane-protocols/"
+ "rt:control-plane-protocol/rt:name";
}
description
"Протокол маршрутизации, владеющий привязкой.";
}
leaf binding-type {
type enumeration {
enum prefix-sid {
description
"Привязки изучаются из Prefix-SID.";
}
enum binding-tlv {
description
"Привязки изучаются из TLV привязок.";
}
}
description
"Тип привязки.";
}
leaf scope {
type enumeration {
enum global {
description
"Глобальный SID.";
}
enum local {
description
"Локальный SID.";
}
}
description
"Область действия SID.";
}
}
}
}
}
notification segment-routing-srgb-collision {
description
"Передаётся при конфликте блоков SRGB, полученных
от разных маршрутизаторов.";
list srgb-collisions {
description
"Список конфликтующих блоков SRGB.";
leaf lower-bound {
type uint32;
description
"Нижнее значение в блоке.";
}
leaf upper-bound {
type uint32;
description
"Верхнее значение в блоке.";
}
leaf routing-protocol {
type leafref {
path "/rt:routing/rt:control-plane-protocols/"
+ "rt:control-plane-protocol/rt:name";
}
description
"Ссылка на протокол маршрутизации для конфликта SRGB.";
}
leaf originating-rtr-id {
type router-or-system-id;
description
"Идентификатор маршрутизатора, создавшего этот блок SRGB.";
}
}
}
notification segment-routing-global-sid-collision {
description
"Передаётся при получении нового отображения, где SID уже
используется. Генерация уведомлений должна происходить с
интервалом не меньше 5 секунд.";
leaf received-target {
type string;
description
"Цель в полученном анонсе маршрутизатора вызвала конфликт
SID.";
}
leaf new-sid-rtr-id {
type router-or-system-id;
description
"Router ID из анонса конфликтующего SID.";
}
leaf original-target {
type string;
description
"В базе данных уже доступна цель с SID, который получен.";
}
leaf original-sid-rtr-id {
type router-or-system-id;
description
"Router ID маршрутизатора, исходно анонсировавшего
конфликтующий SID, т. е., экземпляр в базе данных.";
}
leaf index {
type uint32;
description
"Значение индекса, использованного 2 разными префиксами.";
}
leaf routing-protocol {
type leafref {
path "/rt:routing/rt:control-plane-protocols/"
+ "rt:control-plane-protocol/rt:name";
}
description
"Ссылка на протокол маршрутизации для конфликтующего SID.";
}
}
notification segment-routing-index-out-of-range {
description
"Передаётся, когда полученная привязка содержит индекс сегмента
вне локально заданных диапазонов. Генерация уведомлений должна
происходить с интервалом не меньше 5 секунд.";
leaf received-target {
type string;
description
"Предназначенная человеку строка, представляющая цель,
полученную в зависящем от протокола уведомлении,
соответствующем индексу вне диапазона.";
}
leaf received-index {
type uint32;
description
"Значение полученного индекса.";
}
leaf routing-protocol {
type leafref {
path "/rt:routing/rt:control-plane-protocols/"
+ "rt:control-plane-protocol/rt:name";
}
description
"Ссылка на протокол маршрутизации для индекса вне диапазона";
}
}
}
<CODE ENDS>
9. Вопросы безопасности
Заданные этим документом модули YANG определяют схему для данных, предназначенную для доступа через сеть с использованием протоколов управления, таких как NETCONF [RFC6241] или RESTCONF [RFC8040]. Нижним уровнем NETCONF служит защищённый транспорт с обязательной поддержкой SSH (Secure Shell) [RFC6242]. Нижним уровнем RESTCONF служит протокол HTTPS с обязательной поддержкой защиты на транспортном уровне (TLS) [RFC8446].
Модель доступа к конфигурации сети (NACM – Network Configuration Access Control Model) [RFC8341] обеспечивает возможность разрешить доступ лишь определённых пользователей NETCONF или RESTCONF к заранее заданному подмножеству операций NETCONF или RESTCONF и содержимого.
В модулях данных YANG определено множество узлов данных, которые разрешают запись, создание и удаление (т. е. config true, как принято по умолчанию). Эти узлы могут быть конфиденциальными или уязвимыми в некоторых сетевых средах. Запись в такие узлы (например, edit-config) без должной защиты может негативно влиять на работу сети. Ниже перечислены ветви и узлы, которые могут быть конфиденциальны или уязвимы.
/segment-routing
/segment-routing/mpls
/segment-routing/mpls/bindings
Изменение локальных привязок может приводить к DoS3-атаке. Атакующий может также пытаться организовать конфликты сегментов (используя один идентификатор сегмента для разных целей) для перенаправления трафика в доверенном домене. Однако трафик из этого домена не будет выходить. Перенаправление можно использовать для отправки трафика на скомпрометированные узлы или обхода некоторых функций защиты (например, межсетевого экрана). Обсуждение доверенных доменов SR-MPLS приведено в параграфе 8.1 [RFC8402]./segment-routing/mpls/srgb
Изменение SRGB может служить для организации DoS-атаки. Например, при снижении размера SRGB до очень малого значения большая часть имеющихся сегментов больше не будет установлена и это нарушит трафик./segment-routing/mpls/srlb
Изменение SRLB может служить для организации DoS-атаки, похожей на случай изменения SRGB.Некоторые из доступных для чтения узлов в этом модуле YANG могут быть конфиденциальны или уязвимы в той или иной сетевой среде. Важно контролировать доступ к таким объектам (например, get, get-config, notification). Ниже перечислены ветви и узлы, которые могут быть конфиденциальны или уязвимы.
/segment-routing/mpls/bindings
Знание этих узлов данных можно использовать для DoS-атаки на локальный маршрутизатор./segment-routing/mpls/sid-db
Знание этих узлов данных можно использовать для DoS-атаки на другие маршрутизаторы домена DoS или перенаправления трафика, адресованного этим маршрутизаторам.10. Взаимодействие с IANA
Этот документ регистрирует указанные ниже URI в реестре IETF XML Registry [RFC3688].
ID: yang:ietf-segment-routing-common URI: urn:ietf:params:xml:ns:yang:ietf-segment-routing-common Registrant Contact: The IESG. XML: N/A, запрошенный URI является пространстовм имён XML. ID: yang:ietf-segment-routing URI: urn:ietf:params:xml:ns:yang:ietf-segment-routing Registrant Contact: The IESG. XML: N/A, запрошенный URI является пространстовм имён XML. ID: yang:ietf-segment-routing-mpls URI: urn:ietf:params:xml:ns:yang:ietf-segment-routing-mpls Registrant Contact: The IESG. XML: N/A, запрошенный URI является пространстовм имён XML.
Этот документ регистрирует указанные ниже модули YANG в реестре YANG Module Names [RFC6020].
Name: ietf-segment-routing-common Maintained by IANA: N Namespace: urn:ietf:params:xml:ns:yang:ietf-segment-routing-common Prefix: sr-cmn Reference: RFC 9020 Name: ietf-segment-routing Maintained by IANA: N Namespace: urn:ietf:params:xml:ns:yang:ietf-segment-routing Prefix: sr Reference: RFC 9020 Name: ietf-segment-routing-mpls Maintained by IANA: N Namespace: urn:ietf:params:xml:ns:yang:ietf-segment-routing-mpls Prefix: sr-mpls Reference: RFC 9020
11. Литература
11.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>.
[RFC6991] Schoenwaelder, J., Ed., “Common YANG Data Types”, RFC 6991, DOI 10.17487/RFC6991, July 2013, <https://www.rfc-editor.org/info/rfc6991>.
[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>.
[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>.
[RFC8294] Liu, X., Qu, Y., Lindem, A., Hopps, C., and L. Berger, “Common YANG Data Types for the Routing Area”, RFC 8294, DOI 10.17487/RFC8294, December 2017, <https://www.rfc-editor.org/info/rfc8294>.
[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>.
[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>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, “Segment Routing Architecture”, RFC 8402, DOI 10.17487/RFC8402, July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[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>.
[RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., Decraene, B., Litkowski, S., and R. Shakir, “Segment Routing with the MPLS Data Plane”, RFC 8660, DOI 10.17487/RFC8660, December 2019, <https://www.rfc-editor.org/info/rfc8660>.
[RFC8661] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., Decraene, B., and S. Litkowski, “Segment Routing MPLS Interworking with LDP”, RFC 8661, DOI 10.17487/RFC8661, December 2019, <https://www.rfc-editor.org/info/rfc8661>.
[RFC8665] Psenak, P., Ed., Previdi, S., Ed., Filsfils, C., Gredler, H., Shakir, R., Henderickx, W., and J. Tantsura, “OSPF Extensions for Segment Routing”, RFC 8665, DOI 10.17487/RFC8665, December 2019, <https://www.rfc-editor.org/info/rfc8665>.
[RFC8667] Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C., Bashandy, A., Gredler, H., and B. Decraene, “IS-IS Extensions for Segment Routing”, RFC 8667, DOI 10.17487/RFC8667, December 2019, <https://www.rfc-editor.org/info/rfc8667>.
[RFC8669] Previdi, S., Filsfils, C., Lindem, A., Ed., Sreekantiah, A., and H. Gredler, “Segment Routing Prefix Segment Identifier Extensions for BGP”, RFC 8669, DOI 10.17487/RFC8669, December 2019, <https://www.rfc-editor.org/info/rfc8669>.
[RFC8814] Tantsura, J., Chunduri, U., Talaulikar, K., Mirsky, G., and N. Triantafillis, “Signaling Maximum SID Depth (MSD) Using the Border Gateway Protocol – Link State”, RFC 8814, DOI 10.17487/RFC8814, August 2020, <https://www.rfc-editor.org/info/rfc8814>.
[W3C.REC-xml11-20060816] Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., Yergeau, F., and J. Cowan, “Extensible Markup Language (XML) 1.1 (Second Edition)”, World Wide Web Consortium Recommendation REC-xml11-20060816, 16 August 2006, <https://www.w3.org/TR/2006/REC-xml11-20060816>.
11.2. Дополнительная литература
[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>.
[RFC8792] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu, “Handling Long Lines in Content of Internet-Drafts and RFCs”, RFC 8792, DOI 10.17487/RFC8792, June 2020, <https://www.rfc-editor.org/info/rfc8792>.
Приложение A. Примеры конфигурации
В примерах ниже символ \ служит для разрыва длинных строк, как описано в [RFC8792].
A.1. SR-MPLS м IPv4
Ниже представлен пример XML [W3C.REC-xml11-20060816], использующий модули YANG SR-MPLS с адресами IPv4.
<routing xmlns="urn:ietf:params:xml:ns:yang:ietf-routing">
<segment-routing
xmlns="urn:ietf:params:xml:ns:yang:ietf-segment-routing">
<sr-mpls
xmlns="urn:ietf:params:xml:ns:yang:ietf-segment-routing-mpls">
<bindings>
<mapping-server>
<policy>
<name>mapping 1</name>
<entries>
<mapping-entry>
<prefix>198.51.100.0/24</prefix>
<algorithm xmlns:sr-cmn="urn:ietf:params:xml:ns:yang\
:ietf-segment-routing-common">\
sr-cmn:prefix-sid-algorithm-shortest-path\
</algorithm>
<start-sid>200</start-sid>
<range>100</range>
</mapping-entry>
</entries>
</policy>
</mapping-server>
<connected-prefix-sid-map>
<connected-prefix-sid>
<prefix>192.0.2.0/24</prefix>
<algorithm xmlns:sr-cmn="urn:ietf:params:xml:ns:yang:\
ietf-segment-routing-common">\
sr-cmn:prefix-sid-algorithm-strict-spf</algorithm>
<start-sid>100</start-sid>
<range>1</range>
<last-hop-behavior>php</last-hop-behavior>
</connected-prefix-sid>
</connected-prefix-sid-map>
</bindings>
<srgb>
<srgb>
<lower-bound>45000</lower-bound>
<upper-bound>55000</upper-bound>
</srgb>
</srgb>
</sr-mpls>
</segment-routing>
</routing>
Ниже тот же пример представлен в формате JSON.
{
"ietf-routing:routing": {
"ietf-segment-routing:segment-routing": {
"ietf-segment-routing-mpls:sr-mpls": {
"bindings": {
"mapping-server": {
"policy": [
{
"name": "mapping 1",
"entries": {
"mapping-entry": [
{
"prefix": "198.51.100.0/24",
"algorithm": "ietf-segment-routing-common:\
prefix-sid-algorithm-shortest-path",
"start-sid": 200,
"range": 100
}
]
}
}
]
},
"connected-prefix-sid-map": {
"connected-prefix-sid": [
{
"prefix": "192.0.2.0/24",
"algorithm": "ietf-segment-routing-common:\
prefix-sid-algorithm-strict-spf",
"start-sid": 100,
"range": 1,
"last-hop-behavior": "php"
}
]
}
},
"srgb": {
"srgb": [
{
"lower-bound": 45000,
"upper-bound": 55000
}
]
}
}
}
}
}
A.2. SR-MPLS с IPv6
Ниже представлен пример XML [W3C.REC-xml11-20060816], использующий модули YANG SR-MPLS с адресами IPv6.
<routing xmlns="urn:ietf:params:xml:ns:yang:ietf-routing">
<segment-routing
xmlns="urn:ietf:params:xml:ns:yang:ietf-segment-routing">
<sr-mpls
xmlns="urn:ietf:params:xml:ns:yang:ietf-segment-routing-mpls">
<bindings>
<mapping-server>
<policy>
<name>mapping 1</name>
<entries>
<mapping-entry>
<prefix>2001:db8:aaaa:bbbb::/64</prefix>
<algorithm xmlns:sr-cmn="urn:ietf:params:xml:ns:yang\
:ietf-segment-routing-common">\
sr-cmn:prefix-sid-algorithm-shortest-path\
</algorithm>
<start-sid>200</start-sid>
<range>100</range>
</mapping-entry>
</entries>
</policy>
</mapping-server>
<connected-prefix-sid-map>
<connected-prefix-sid>
<prefix>2001:db8:aaaa:cccc::/64</prefix>
<algorithm xmlns:sr-cmn="urn:ietf:params:xml:ns:yang:\
ietf-segment-routing-common">\
sr-cmn:prefix-sid-algorithm-strict-spf</algorithm>
<start-sid>100</start-sid>
<range>1</range>
<last-hop-behavior>php</last-hop-behavior>
</connected-prefix-sid>
</connected-prefix-sid-map>
</bindings>
<srgb>
<srgb>
<lower-bound>45000</lower-bound>
<upper-bound>55000</upper-bound>
</srgb>
</srgb>
</sr-mpls>
</segment-routing>
</routing>
Ниже тот же пример представлен в формате JSON.
{
"ietf-routing:routing": {
"ietf-segment-routing:segment-routing": {
"ietf-segment-routing-mpls:sr-mpls": {
"bindings": {
"mapping-server": {
"policy": [
{
"name": "mapping 1",
"entries": {
"mapping-entry": [
{
"prefix": "2001:db8:aaaa:bbbb::/64",
"algorithm": "ietf-segment-routing-common:\
prefix-sid-algorithm-shortest-path",
"start-sid": 200,
"range": 100
}
]
}
}
]
},
"connected-prefix-sid-map": {
"connected-prefix-sid": [
{
"prefix": "2001:db8:aaaa:cccc::/64",
"algorithm": "ietf-segment-routing-common:\
prefix-sid-algorithm-strict-spf",
"start-sid": 100,
"range": 1,
"last-hop-behavior": "php"
}
]
}
},
"srgb": {
"srgb": [
{
"lower-bound": 45000,
"upper-bound": 55000
}
]
}
}
}
}
}
Благодарности
Авторы благодарны Derek Yeung, Greg Hankins, Hannes Gredler, Uma Chunduri, Jeffrey Zhang, Shradda Hedge, Les Ginsberg за их вклад в работу.
Спасибо Ladislav Lhotka и Tom Petch за подробные рецензии и полезные комментари.
Авторы признательны Benjamin Kaduk, Alvaro Retana, and Roman Danyliw за рецензию IESG и комментарии.
Адреса авторов
Перевод на русский язык
Николай Малых
1Internet Engineering Task Force – комиссия по решению инженерных задач Internet.
2Internet Engineering Steering Group – комиссия по инженерным разработкам Internet.
3Denial-of-Service – отказ в обслуживании.