RFC 8675 A YANG Data Model for Tunnel Interface Types

Опубликовано 20.11.2019 автором Nikolai Malykh 
Internet Engineering Task Force (IETF)                      M. Boucadair
Request for Comments: 8675                                        Orange
Category: Standards Track                                      I. Farrer
ISSN: 2070-1721                                      Deutsche Telekom AG
                                                                R. Asati
                                                     Cisco Systems, Inc.
                                                           November 2019

A YANG Data Model for Tunnel Interface Types

Модель данных YANG для типов туннельных интерфейсов

PDF

Аннотация

Этот документ задаёт первую версию модуля YANG iana-tunnel-type, включающую набор поддерживаемых IANA идентификаторов YANG, служащих для указания типов туннельных интерфейсов. Модуль отражает реестр tunnelType, поддерживаемый IANA. Последнюю версию этого модуля YANG можно найти на web-сайте IANA.

Значения типов туннелей не добавляются напрямую в модуль YANG и должны сначала включаться в реестр tunnelType. После регистрации в IANA новой схемы туннелирования или даже существующей схемы, которая ещё не включена в реестр (например LISP, NSH) агентство IANA будет соответствующим образом обновлять модуль YANG.

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

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

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

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

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

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

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

К документу применимы права и ограничения, указанные в BCP 78 и IETF Trust Legal Provisions и относящиеся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно. Фрагменты программного кода, включённые в этот документ, распространяются в соответствии с упрощённой лицензией BSD, как указано в параграфе 4.e документа IETF Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).

1. Введение

Этот документ задаёт исходную версию модуля YANG iana-tunnel-type, содержащую набор поддерживаемых IANA идентификаторов YANG, указывающих типы туннельных интерфейсов. Модель отражает реестр IANA tunnelType в реестре SMI Numbers [TUNNELTYPE-IANA-REGISTRY]. Последняя версия модуля доступна на web-сайте IANA.

В модуль Interface [RFC8343] можно добавить расширения в зависимости от типа туннеля. Пример такого добавления приведён в Приложении A. В задачи документа не входит задание связанных с туннелями расширений для каждой технологии инкапсуляции, они рассматриваются в отдельных документах, например, [RFC8676]. Обновление имеющегося реестра IANA tunnelType [TUNNELTYPE-IANA-REGISTRY] с указанием полного списка туннельных технологий также не является задачей этого документа. Рекомендации и процедуры регистрации для типов и субтипов интерфейсов приведены в [IFTYPE-REG].

Этот документ использует базовые типа YANG, определённые в [RFC6991], и следует архитектуре хранилищ данных управления сетью (Network Management Datastore Architecture или NMDA) [RFC8342].

Терминология для описания модулей YANG определена в [RFC7950], значения символов в диаграммах деревьев – в [RFC8340].

2. Модуль YANG для типов туннелей IANA

Модуль iana-tunnel-type импортирует модуль iana-if-type, заданный в [RFC7224].

Исходная версия этого модуля включает типы туннелей, определённые в [RFC4087], [RFC7856], [RFC7870], [RFC6346].

   <CODE BEGINS> file "iana-tunnel-type@2019-11-16.yang"
   module iana-tunnel-type {
     yang-version 1.1;
     namespace "urn:ietf:params:xml:ns:yang:iana-tunnel-type";
     prefix iana-tunnel-type;

     import iana-if-type {
       prefix ift;
       reference
         "RFC 7224: IANA Interface Type YANG Module";
     }

     organization
       "IANA";
     contact
       "Internet Assigned Numbers Authority

        Postal: ICANN
             12025 Waterfront Drive, Suite 300
             Los Angeles, CA  90094-2536
             United States of America
        Tel:    +1 310 301 5800
        <mailto:iana@iana.org>";
     description
       "Этот модуль содержит набор идентификаторов YANG, заданных 
        IANA и используемых как типы туннельных интерфейсов.

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

        Распространение и применение модуля в исходной или двоичной 
        форме с изменениями или без таковых разрешено в соответствии с
        лицензией Simplified BSD License, изложенной в параграфе 4.c
        IETF Trust's Legal Provisions Relating to IETF Documents
        (https://trustee.ietf.org/license-info). 

        Эта версия модуля YANG является частью RFC 8675, где правовые
        аспекты приведены более полно.";

     revision 2019-11-16 {
       description
         "Исходный выпуск.";
       reference
         "RFC 8675: A YANG Data Model for Tunnel Interface Types";
     }

     identity other {
       base ift:tunnel;
       description
         "Ни один из указанных ниже типов.";
       reference
         "RFC 4087: IP Tunnel MIB";
     }

     identity direct {
       base ift:tunnel;
       description
         "Нет промежуточного заголовка.";
       reference
         "RFC 2003: IP Encapsulation within IP
          RFC 4213: Basic Transition Mechanisms for IPv6 Hosts
                    and Routers";
     }

     identity gre {
       base ift:tunnel;
       description
         "Инкапсуляция GRE.";
       reference
         "RFC 1701: Generic Routing Encapsulation (GRE)
          RFC 1702: Generic Routing Encapsulation over IPv4 networks
          RFC 7676: IPv6 Support for Generic Routing Encapsulation
                    (GRE)";
     }

     identity minimal {
       base ift:tunnel;
       description
         "Минимальная инкапсуляция.";
       reference
         "RFC 2004: Minimal Encapsulation within IP";
     }

     identity l2tp {
       base ift:tunnel;
       description
         "Инкапсуляция L2TP.";
       reference
         "RFC 2661: Layer Two Tunneling Protocol 'L2TP'";
     }

     identity pptp {
       base ift:tunnel;
       description
         "Инкапсуляция PPTP.";
       reference
         "RFC 2637: Point-to-Point Tunneling Protocol (PPTP)";
     }

     identity l2f {
       base ift:tunnel;
       description
         "Инкапсуляция L2F.";
       reference
         "RFC 2341: Cisco Layer Two Forwarding (Protocol) 'L2F'";
     }

     identity udp {
       base ift:tunnel;
       description
         "Инкапсуляция UDP.";
       reference
         "RFC 1234: Tunneling IPX Traffic through IP Networks,
          RFC 8085: UDP Usage Guidelines, Section 3.1.11";
     }

     identity atmp {
       base ift:tunnel;
       description
         "Инкапсуляция ATMP.";
       reference
         "RFC 2107: Ascend Tunnel Management Protocol - ATMP";
     }

     identity msdp {
       base ift:tunnel;
       description
         "Инкапсуляция MSDP.";
       reference
         "RFC 3618: Multicast Source Discovery Protocol (MSDP)";
     }

     identity sixtofour {
       base ift:tunnel;
       description
         "Инкапсуляция 6to4.";
       reference
         "RFC 3056: Connection of IPv6 Domains via IPv4 Clouds";
     }

     identity sixoverfour {
       base ift:tunnel;
       description
         "Инкапсуляция 6over4.";
       reference
         "RFC 2529: Transmission of IPv6 over IPv4 Domains without
                    Explicit Tunnels";
     }

     identity isatap {
       base ift:tunnel;
       description
         "Инкапсуляция ISATAP.";
       reference
         "RFC 5214:  Intra-Site Automatic Tunnel Addressing Protocol
                    (ISATAP)";
     }

     identity teredo {
       base ift:tunnel;
       description
         "Инкапсуляция Teredo.";
       reference
         "RFC 4380: Teredo: Tunneling IPv6 over UDP through
                    Network Address Translations (NATs)";
     }

     identity iphttps {
       base ift:tunnel;
       description
         "Туннельный протокол IP через HTTPS (IP-HTTPS).";
       reference
         "Microsoft Corporation, IP over HTTPS (IP-HTTPS) Tunneling
          Protocol Specification,
          https://msdn.microsoft.com/en-us/library/dd358571.aspx";
     }

     identity softwiremesh {
       base ift:tunnel;
       description
         "Сеть из мягких проводов (softwire mesh tunnel).";
       reference
         "RFC 5565: Softwire Mesh Framework";
     }

     identity dslite {
       base ift:tunnel;
       description
         "Туннель DS-Lite.";
       reference
         "RFC 6333: Dual-Stack Lite Broadband Deployments Following
                    IPv4 Exhaustion";
     }

     identity aplusp {
       base ift:tunnel;
       description
         "Инкапсуляция A+P.";
       reference
         "RFC 6346: The Address plus Port (A+P) Approach to the IPv4
                    Address Shortage";
     }
   }
   <CODE ENDS>

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

Заданный этим документом модуль YANG определяет схему для данных, предназначенную для доступа через сеть с использованием протоколов управления, таких как NETCONF [RFC6241] или RESTCONF [RFC8040]. Нижним уровнем NETCONF служит защищённый транспорт с обязательной поддержкой SSH (Secure Shell) [RFC6242]. Нижним уровнем RESTCONF служит протокол HTTPS с обязательной поддержкой защиты на транспортном уровне (TLS) [RFC8446].

Модель контроля доступа к настройкам сети (Network Configuration Access Control Model или NACM) [RFC8341] обеспечивает возможность разрешить доступ лишь определённых пользователей NETCONF или RESTCONF к заранее заданному подмножеству операций NETCONF или RESTCONF и содержимого.

Заданный здесь модуль YANG указывает реестр iana-tunnel-types. Эти идентификаторы предназначены для применения в других модулях YANG и сами по себе не раскрывают каких-либо узлов, доступных для записи, только для чтения или RPC. Поэтому с заданным здесь модулем не связано каких-либо новых вопросов безопасности.

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

4.1. Модуль YANG

Агентство IANA зарегистрировало URI в субреестре ns реестра IETF XML Registry [RFC3688]

   URI:  urn:ietf:params:xml:ns:yang:iana-tunnel-type
   Registrant Contact:  IANA
   XML:  N/A; запрошенный URI является пространством имён XML.

Агентство IANA зарегистрировало модуль YANG в субреестре YANG Module Names [RFC7950] реестра YANG Parameters

   Name:  iana-tunnel-type
   Namespace:  urn:ietf:params:xml:ns:yang:iana-tunnel-type
   Prefix:  iana-tunnel-type
   Reference:  RFC 8675

Документ определяет исходную версию поддерживаемого IANA модуля YANG iana-tunnel-type. Агентство IANA добавило в реестр примечание:

Значения типов туннелей недопустимо напрямую добавлять в модуль YANG iana-tunnel-type. Они должны добавляться в субреестр tunnelType (внутри реестра ifType definitions) [IANA registry smi-numbers].

При добавлении нового типа туннеля в субреестр tunnelType в модуль YANG iana-tunnel-type должен добавляться оператор identity. Имя identity является приведённым к нижнему регистру вариантом соответствующего перечисляемого значения из IANAifType-MIB (т. е. IANAtunnelType). В оператор identity следует включать указанные ниже субоператоры.

base

ift:tunnel.

description

Копия описания из реестра.

reference

Копия ссылки из реестра с указанием названия документа.

Невыделенные и резервные значения не включаются в модуль.

При обновлении модуля YANG iana-tunnel-type в него должен добавляться новый оператор revision перед имеющимися одноименными операторами.

Агентство IANA добавило в реестр tunnelType примечание:

При обновлении реестра должен обновляться модуль YANG iana-tunnel-type, как указано в RFC 8675.

4.2. Обновления таблицы IANA tunnelType

Агентство IANA обновило показанные в таблице 1 записи субреестра tunnelType внутри реестра SMI Numbers [TUNNELTYPE-IANA-REGISTRY], в соответствии с таблицей 2.

Таблица 1. Старая таблица.

 

Десятичное значение

Имя

Описание

Документ

2

direct

Нет промежуточного заголовка

[RFC4087]

3

gre

Инкапсуляция GRE

[RFC4087]

4

minimal

Минимальная инкапсуляция

[RFC4087]

5

l2tp

Инкапсуляция L2TP

[RFC4087]

6

pptp

Инкапсуляция PPTP

[RFC4087]

7

l2f

Инкапсуляция L2F

[RFC4087]

8

udp

Инкапсуляция UDP

[RFC4087]

9

atmp

Инкапсуляция ATMP

[RFC4087]

10

msdp

Инкапсуляция MSDP

[RFC4087]

11

sixToFour

Инкапсуляция 6to4

[RFC4087]

12

sixOverFour

Инкапсуляция 6over4

[RFC4087]

13

isatap

Инкапсуляция ISATAP

[RFC4087]

14

teredo

Инкапсуляция Teredo

[RFC4087]

16

softwireMesh

Туннель softwire mesh

[RFC7856]

17

dsLite

Туннель DS-Lite

[RFC7870]

 

Таблица 2. Новая таблица.

 

Десятичное значение

Имя

Описание

Документ

2

direct

Нет промежуточного заголовка

[RFC2003][RFC4213]

3

gre

Инкапсуляция GRE

[RFC1701][RFC1702][RFC7676]

4

minimal

Минимальная инкапсуляция

[RFC2004]

5

l2tp

Инкапсуляция L2TP

[RFC2661]

6

pptp

Инкапсуляция PPTP

[RFC2637]

7

l2f

Инкапсуляция L2F

[RFC2341]

8

udp

Инкапсуляция UDP

[RFC8085]

9

atmp

Инкапсуляция ATMP

[RFC2107]

10

msdp

Инкапсуляция MSDP

[RFC3618]

11

sixToFour

Инкапсуляция 6to4

[RFC3056]

12

sixOverFour

Инкапсуляция 6over4

[RFC2529]

13

isatap

Инкапсуляция ISATAP

[RFC5214]

14

teredo

Инкапсуляция Teredo

[RFC4380]

16

softwireMesh

Туннель softwire mesh

[RFC5565]

17

dsLite

Туннель DS-Lite

[RFC6333]

 

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

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

[RFC3688] Mealling, M., “The IETF XML Registry”, BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, <https://www.rfc-editor.org/info/rfc3688>.

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

[RFC7224] Bjorklund, M., “IANA Interface Type YANG Module”, RFC 7224, DOI 10.17487/RFC7224, May 2014, <https://www.rfc-editor.org/info/rfc7224>.

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

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

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

[TUNNELTYPE-IANA-REGISTRY] IANA, “Structure of Management Information (SMI) Numbers (MIB Module Registrations)”, <https://www.iana.org/assignments/smi-numbers>.

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

[IFTYPE-REG] Thaler, D. and D. Romascanu, “Guidelines and Registration Procedures for Interface Types and Tunnel Types”, Work in Progress, Internet-Draft, draft-thaler-iftype-reg-06, 2 November 2019, <https://tools.ietf.org/html/draft-thaler-iftype-reg-06>.

[RFC1701] Hanks, S., Li, T., Farinacci, D., and P. Traina, “Generic Routing Encapsulation (GRE)”, RFC 1701, DOI 10.17487/RFC1701, October 1994, <https://www.rfc-editor.org/info/rfc1701>.

[RFC1702] Hanks, S., Li, T., Farinacci, D., and P. Traina, “Generic Routing Encapsulation over IPv4 networks”, RFC 1702, DOI 10.17487/RFC1702, October 1994, <https://www.rfc-editor.org/info/rfc1702>.

[RFC2003] Perkins, C., “IP Encapsulation within IP”, RFC 2003, DOI 10.17487/RFC2003, October 1996, <https://www.rfc-editor.org/info/rfc2003>.

[RFC2004] Perkins, C., “Minimal Encapsulation within IP”, RFC 2004, DOI 10.17487/RFC2004, October 1996, <https://www.rfc-editor.org/info/rfc2004>.

[RFC2107] Hamzeh, K., “Ascend Tunnel Management Protocol — ATMP”, RFC 2107, DOI 10.17487/RFC2107, February 1997, <https://www.rfc-editor.org/info/rfc2107>.

[RFC2341] Valencia, A., Littlewood, M., and T. Kolar, “Cisco Layer Two Forwarding (Protocol) “L2F””, RFC 2341, DOI 10.17487/RFC2341, May 1998, <https://www.rfc-editor.org/info/rfc2341>.

[RFC2529] Carpenter, B. and C. Jung, “Transmission of IPv6 over IPv4 Domains without Explicit Tunnels”, RFC 2529, DOI 10.17487/RFC2529, March 1999, <https://www.rfc-editor.org/info/rfc2529>.

[RFC2637] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W., and G. Zorn, “Point-to-Point Tunneling Protocol (PPTP)”, RFC 2637, DOI 10.17487/RFC2637, July 1999, <https://www.rfc-editor.org/info/rfc2637>.

[RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., and B. Palter, “Layer Two Tunneling Protocol “L2TP””, RFC 2661, DOI 10.17487/RFC2661, August 1999, <https://www.rfc-editor.org/info/rfc2661>.

[RFC3056] Carpenter, B. and K. Moore, “Connection of IPv6 Domains via IPv4 Clouds”, RFC 3056, DOI 10.17487/RFC3056, February 2001, <https://www.rfc-editor.org/info/rfc3056>.

[RFC3618] Fenner, B., Ed. and D. Meyer, Ed., “Multicast Source Discovery Protocol (MSDP)”, RFC 3618, DOI 10.17487/RFC3618, October 2003, <https://www.rfc-editor.org/info/rfc3618>.

[RFC4087] Thaler, D., “IP Tunnel MIB”, RFC 4087, DOI 10.17487/RFC4087, June 2005, <https://www.rfc-editor.org/info/rfc4087>.

[RFC4213] Nordmark, E. and R. Gilligan, “Basic Transition Mechanisms for IPv6 Hosts and Routers”, RFC 4213, DOI 10.17487/RFC4213, October 2005, <https://www.rfc-editor.org/info/rfc4213>.

[RFC4380] Huitema, C., “Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)”, RFC 4380, DOI 10.17487/RFC4380, February 2006, <https://www.rfc-editor.org/info/rfc4380>.

[RFC5214] Templin, F., Gleeson, T., and D. Thaler, “Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)”, RFC 5214, DOI 10.17487/RFC5214, March 2008, <https://www.rfc-editor.org/info/rfc5214>.

[RFC5565] Wu, J., Cui, Y., Metz, C., and E. Rosen, “Softwire Mesh Framework”, RFC 5565, DOI 10.17487/RFC5565, June 2009, <https://www.rfc-editor.org/info/rfc5565>.

[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, “Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion”, RFC 6333, DOI 10.17487/RFC6333, August 2011, <https://www.rfc-editor.org/info/rfc6333>.

[RFC6346] Bush, R., Ed., “The Address plus Port (A+P) Approach to the IPv4 Address Shortage”, RFC 6346, DOI 10.17487/RFC6346, August 2011, <https://www.rfc-editor.org/info/rfc6346>.

[RFC7676] Pignataro, C., Bonica, R., and S. Krishnan, “IPv6 Support for Generic Routing Encapsulation (GRE)”, RFC 7676, DOI 10.17487/RFC7676, October 2015, <https://www.rfc-editor.org/info/rfc7676>.

[RFC7856] Cui, Y., Dong, J., Wu, P., Xu, M., and A. Yla-Jaaski, “Softwire Mesh Management Information Base (MIB)”, RFC 7856, DOI 10.17487/RFC7856, May 2016, <https://www.rfc-editor.org/info/rfc7856>.

[RFC7870] Fu, Y., Jiang, S., Dong, J., and Y. Chen, “Dual-Stack Lite (DS-Lite) Management Information Base (MIB) for Address Family Transition Routers (AFTRs)”, RFC 7870, DOI 10.17487/RFC7870, June 2016, <https://www.rfc-editor.org/info/rfc7870>.

[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, “UDP Usage Guidelines”, BCP 145, RFC 8085, DOI 10.17487/RFC8085, March 2017, <https://www.rfc-editor.org/info/rfc8085>.

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

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

[RFC8676] Farrer, I., Ed. and M. Boucadair, Ed., “YANG Modules for IPv4-in-IPv6 Address plus Port (A+P) Softwires”, RFC 8676, DOI 10.17487/RFC8676, November 2019, <https://www.rfc-editor.org/info/rfc8676>.

Приложение A. Пример использования

Приведённый ниже пример иллюстирует добавление (augment) в модуль YANG Interface связанных с туннелем параметров. В примере добавляется remote-endpoint для туннеля. Дерево модуля имеет вид

   module: example-iftunnel-extension
     augment /if:interfaces/if:interface:
       +--rw remote-endpoint?   inet:ipv6-address

Модуль example-iftunnel-extension импортирует модули из [RFC6991] и [RFC8343] в дополнение к модулю iana-tunnel-type, заданному в этом документе.

   module example-iftunnel-extension {
     yang-version 1.1;

     namespace "urn:ietf:params:xml:ns:yang:example-iftunnel-extension";
     prefix example;

     import ietf-inet-types {
       prefix inet;
       reference
         "RFC 6991: Common YANG Data Types, Section 4";
     }

     import ietf-interfaces {
       prefix if;
       reference
         "RFC 8343: A YANG Data Model for Interface Management";
     }

     import iana-tunnel-type  {
       prefix iana-tunnel-type;
       reference
         "RFC 8675:  A Tunnel Extension to the Interface Management
                     YANG Module";
     }

     organization "IETF Softwire Working Group";

     contact

       "WG Web:   <https://datatracker.ietf.org/wg/softwire/>
        WG List:  <mailto:softwire@ietf.org>

        Author:  Mohamed Boucadair
                 <mailto:mohamed.boucadair@orange.com>";

      description
         "Это пример модуля, расширяющего модуль YANG Interface связанными
          с туннелем параметрами.

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

          Распространение и применение модуля в исходной или двоичной 
          форме с изменениями или без таковых разрешено в соответствии с
          лицензией Simplified BSD License, изложенной в параграфе 4.c
          IETF Trust's Legal Provisions Relating to IETF Documents
          (https://trustee.ietf.org/license-info). 

          Эта версия модуля YANG является частью RFC 8675, где правовые
          аспекты приведены более полно.";

     revision 2019-10-21 {
       description
         "Исходный выпуск.";
       reference
         "RFC 8675:  Tunnel Interface Types YANG Module";
     }

     augment "/if:interfaces/if:interface" {
       when "derived-from(if:type, 'iana-tunnel-type:gre')";
       description
         "Дополняет модуль Interface конкретными параметрами туннеля.";

       leaf remote-endpoint {
         type inet:ipv6-address;
         description
           "Адрес IPv6 удалённой точки GRE.";
       }
     }
   }

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

Большое спасибо Tom Petch и Martin Bjorklund за подробные рецензии и предложения.

Спасибо Andy Bierman за рецензию Yangdoctors.

Спасибо Dale Worley, David Black, Yaron Sheffer за рецензии.

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

Mohamed Boucadair
Orange
35000 Rennes
France
Email: mohamed.boucadair@orange.com
 
Ian Farrer
Deutsche Telekom AG
CTO-ATI, Landgrabenweg 151
53227 Bonn
Germany
Email: ian.farrer@telekom.de
 
Rajiv Asati
Cisco Systems, Inc.
7025 Kit Creek Rd.
RTP, NC 27709
United States of America
Email: Rajiva@cisco.com
 

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

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

nmalykh@protokols.ru

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

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

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

Добавить комментарий