From bc1d70343807104ccf64b6bde9b2db54270203ff Mon Sep 17 00:00:00 2001 From: neodarz Date: Fri, 10 Mar 2017 11:58:22 +0100 Subject: Initiale release --- RFC_7950_The_YANG_11_Data_Modeling_Language.txt | 324 ++++++++++++++++++++++++ 1 file changed, 324 insertions(+) create mode 100644 RFC_7950_The_YANG_11_Data_Modeling_Language.txt (limited to 'RFC_7950_The_YANG_11_Data_Modeling_Language.txt') diff --git a/RFC_7950_The_YANG_11_Data_Modeling_Language.txt b/RFC_7950_The_YANG_11_Data_Modeling_Language.txt new file mode 100644 index 0000000..9a8a47e --- /dev/null +++ b/RFC_7950_The_YANG_11_Data_Modeling_Language.txt @@ -0,0 +1,324 @@ +Titre: RFC 7950: The YANG 1.1 Data Modeling Language +Auteur: +Date: Mon 10 Oct 2016 02:00:00 +0200 +Lien: https://www.bortzmeyer.org/7950.html + +Le protocole standard Netconf (normalisé dans le RFC 6241) permet de configurer +un équipement réseau (par exemple un commutateur) à distance. Netconf +fonctionne par des RPC dont les paramètres sont des actions à faire effectuer +par l'équipement configuré, ou bien les nouvelles valeurs que peut prendre +telle ou telle des variables de configuration de cet équipement. Mais comment +savoir quelles actions sont possibles, quelles variables existent, et quelles +valeurs elles peuvent prendre ? Jusqu'à présent, cela pouvait se spécifier +uniquement dans une documentation en langue naturelle fournie avec +l'équipement. Désormais, il est possible de spécifier ces informations dans un +langage formel, YANG. La première version de YANG était normalisée dans RFC +6020, ce nouveau RFC normalise la nouvelle version, la 1.1, qui a peu de +changements, mais certains cassent la compatibilité ascendante. + +Ce RFC 7950 est très détaillé, plus de deux cents pages. Et je n'ai pas +personnellement d'expérience pratique avec YANG. Donc, je ne donne ici qu'un +très bref résumé. Un tel survol se trouve également dans la section 4 du RFC : +YANG modélise les données (configuration et état) qui seront utilisées par +Netconf. Ces données sont représentées sous forme arborescente. YANG est +modulaire (section 5.1 du RFC), un module YANG pouvant se référer à d'autres +modules. YANG définit un ensemble de types pour décrire les données (section 9 +et RFC 6991). Il permet également d'indiquer les contraintes que doivent +respecter les données. YANG, langage de haut niveau, ne décrit pas l'encodage +utilisé sur le câble. + +Notez que YANG peut être utilisé avec d'autres protocoles que Netconf, comme +RESTCONF (décrit dans le RFC 8040). + +YANG a donc bien des points communs avec le SMI des RFC 2578 et RFC 2579. Avant +Netconf, beaucoup de gens pensaient que toute la gestion des équipements réseau +se ferait en SNMP, en s'appuyant sur ce modèle SMI. Si, pour la lecture des +variables, SNMP s'est largement imposé, force est de constater que, pour +l'écriture de variables et pour les actions, SNMP reste très peu utilisé, au +profit de toute une galaxie de mécanismes privés (Web, REST, SSH + CLI, etc), +galaxie que Netconf vise à remplacer. Une MIB du SMI peut donc être traduite en +YANG, l'inverse n'étant pas vrai (YANG étant plus riche). + +La syntaxe de YANG utilise des groupes emboîtés, délimités par des accolades. +Mais une syntaxe équivalente, en XML, existe, sous le nom de Yin. Tout module +YANG peut être traduit en Yin sans perte et réciproquement (voir la section 13 +pour plus de détails sur Yin). + +Donc, un engin donné, routeur ou autre équipement qu'on veut gérer, est décrit +par des modules YANG. Lorsqu'un serveur Netconf à bord dudit engin met en œuvre +un module YANG, cela veut dire qu'il permet de modifier, via Netconf, les +variables décrites dans le module (le serveur typique met en œuvre plusieurs +modules). Voici le début d'un module possible : + + // Only an example, not a real module. + module acme-system { + namespace "http://acme.example.com/system"; + prefix "acme"; + + organization "ACME Inc."; + contact "joe@acme.example"; + description + "The module for entities implementing the ACME system."; + + revision 2010-08-05 { + description "Initial revision."; + } +... + +On l'a dit, YANG est arborescent. Les feuilles de l'arbre (section 4.2.2.1 du +RFC) contiennent une valeur particulière, par exemple, ici, le nom de l'engin +géré : + + leaf host-name { + type string; + description "Hostname for this system"; + } +Ici, leaf est un mot-clé de YANG qui indique une feuille de l'arbre (plus de +nœuds en dessous), host-name est le nom que l'auteur du module a donné à une +variable, de type « chaîne de caractères ». Lorsqu'un serveur Netconf enverra +cette information à un client (ou réciproquement), elle sera encodée en XML +ainsi (Netconf utilise XML pour l'encodage des messages mais d'autres encodages +sont possibles, cf. RFC 7951) : + + + <>host-name>my-router.example.com<>/host-name> +Donc, pour résumer, YANG modélise ce qu'on peutlire ou modifier, Netconf permet +de le lire ou de le modifier effectivement. + +Par contre, si un nœud de l'arbre YANG n'est pas une feuille, il est désigné +par le mot-clé container. Par exemple, il y a ici deux containers emboîtés et +une feuille : + + container system { + container login { + leaf message { + type string; + description + "Message given at start of login session"; + } + } + } +Lorsque Netconf utilise cette donnée, cela ressemblera, sur le câble, à ceci : + + + <>system> + <>login> + <>message>Good morning<>/message> + <>/login> + <>/system> + +YANG dispose d'un certain nombre de types pour représenter les données (section +4.2.4 et RFC 6991), mais on peut aussi créer ses types (sections 4.2.5 et 7.3) +par exemple ainsi : + + typedef percent { + type uint8 { + range "0 .. 100"; + } + description "Percentage"; + } + + leaf completed { + type percent; + } +On a ajouté un intervalle de validité au type prédéfini uint8. Autre exemple, +en indiquant une valeur par défaut, et en dérivant d'un type défini dans le +module inet[1] : + + typedef listen-ipv4-address { + type inet:ipv4-address; + default "0.0.0.0"; + } + +YANG a bien d'autres possibilités, décrites en détail dans les sections +suivantes. Par exemple, dans un monde idéal, tous les engins mettant en œuvre +un module YANG donné géreraient la totalité des variables du module. Mais, +comme ce n'est pas forcément le cas, YANG permet des déviations (sections 5.6.3 +et 7.20.3). Prenons l'exemple du RFC, un routeur BGP qui suit un module YANG +BGP. Le module ne donne pas de limite au nombre de pairs BGP mais un routeur +bas de gamme pourrait avoir une limite, disons à 16 pairs. Un client Netconf +qui tenterait de configurer un dix-septième pair recevrait donc une erreur. Le +mot-clé YANG deviationpermettrait audit client de savoir à l'avance en quoi ce +routeur particulier dévie du modèle BGP général. Le client Netconf n'aurait +donc pas à essayer pour voir, il pourrait savoir à l'avance que l'opération de +configuration du dix-septième pair ne marchera pas. + +La syntaxe formelle de YANG est décrite en section 6. Elle ressemble à celle de +langages de programmation comme C ou à celle de SMIng du RFC 3780 (RFC qui n'a +pas eu de succès). Cette syntaxe favorise la lisibilité par des humains, le +cahier des charges étant de privilégier les lecteurs, pas les auteurs de +modules, ni les programmeurs d'outils YANG. À noter que, comme dans toutes les +normes modernes, YANG n'est pas limité à l'ASCII et peut utiliser tout Unicode. + +Bien que YANG n'utilise pas XML, il réutilise un langage de ce monde, XPath +(sections 6.4 et 7.5.3). XPath sert à indiquer les dépendances entre nœuds de +l'arbre. + +YANG permet en effet de définir des contraintes (section 8) que doivent +respecter les variables, avec la directive must. Par exemple : + + must "ifType != 'ethernet' or " + + "(ifType = 'ethernet' and ifMTU = 1500)" { + error-message "An ethernet MTU must be 1500"; + } + +Voici un exemple de requête Netconf complète, correspondant à une variable +YANG. Soit un équipement muni d'un serveur SSH et d'un serveur Netconf pour sa +configuration. Disons que le serveur Netconf met en œuvre la variable YANG port +, définie ainsi : + + leaf port { + type inet:port-number; + default 22; + description "The port which the SSH server listens to" + } +La requête Netconf <>edit-config> (RFC 6241, section 7.2) qui configure le +serveur SSH pour écouter sur le port 2022 serait : + + + <>rpc message-id="101" + xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" + xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"> + <>edit-config> + <>target> + <>running/> + <>/target> + <>config> + <>system xmlns="http://example.com/schema/config"> + <>services> + <>ssh> + <>port>2022<>/port> + <>/ssh> + <>/services> + <>/system> + <>/config> + <>/edit-config> + <>/rpc> + +Le choix de YANG comme langage standard pour la description des capacités d'un +serveur Netconf ne s'était pas fait sans mal. Plusieurs concurrents avaient été +envisagés notamment Relax NG, un choix logique puisque Netconf utilise XML. Un +langage de description de schémas comme Relax NG semblait donc un choix +raisonnable. Parmi les discussions à ce sujet, citons par exemple le débat qui +avait eu lieu sur la liste du secteur Applications de l'IETF[2]. Les raisons du +choix de YANG, telles que vues par les concepteurs de YANG, sont décrites sur +le site officiel du projet[3] mais je trouve cette comparaison très +unilatérale. + +Un bon tutoriel Netconf, couvrant également YANG, est disponible en +http://www.aims-conference.org/issnsm-2008/06-netconf-yang.pdf[4]. + +Quelles sont les mises en œuvre de YANG ? Il en existe une liste sur le site +officiel[5]. Voyons par exemple l'outil pyang[6], qui sert à valider des +schémas YANG (y compris de la nouvelle version 1.1 décrite dans ce RFC) et à +les convertir dans d'autres formats. Il ne semble pas trop maintenu mais, bon, +il marche. Il peut produire du XSD et du RelaxNG - enfin du DSDL mais c'est +presque pareil. Voici un exemple de test d'un schéma invalide (leaf a été tapé +laf) : + + +% pyang test.yang +test.yang:11: error: unexpected keyword "laf" +Et, si on corrige : + +% pyang test.yang +% +Maintenant, convertissons en Yin : + + +% cat test.yang + module acme-foo { + namespace "http://acme.example.com/foo"; + prefix "acfoo"; + + list interface { + key "name"; + leaf name { + type string; + } + + leaf mtu { + type uint32; + description "The MTU of the interface."; + } + } + } + +% pyang -fyin test.yang +<>?xml version="1.0" encoding="UTF-8"?> +<>module name="acme-foo" + xmlns="urn:ietf:params:xml:ns:yang:yin:1" + xmlns:acfoo="http://acme.example.com/foo"> + <>namespace uri="http://acme.example.com/foo"/> + <>prefix value="acfoo"/> + <>list name="interface"> + <>key value="name"/> + <>leaf name="name"> + <>type name="string"/> + <>/leaf> + <>leaf name="mtu"> + <>type name="uint32"/> + <>description> + <>text>The MTU of the interface.<>/text> + <>/description> + <>/leaf> + <>/list> +<>/module> +Et voici une conversion du même code en DSL : + + +% pyang -fdsdl test.yang +<>?xml version='1.0' encoding='UTF-8'?> +<>grammar datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes" + ns="http://acme.example.com/foo" + xmlns="http://relaxng.org/ns/structure/1.0" + xmlns:a="http://relaxng.org/ns/compatibility/annotations/1.0" + xmlns:acfoo="http://acme.example.com/foo" + xmlns:dc="http://purl.org/dc/terms" + xmlns:dsrl="http://purl.oclc.org/dsdl/dsrl" + xmlns:nm="urn:ietf:params:xml:ns:netmod:dsdl-attrib:1" + xmlns:sch="http://purl.oclc.org/dsdl/schematron"> + <>dc:source>YANG module 'acme-foo' (automatic translation)<>/dc:source> +<>start> + <>zeroOrMore> + <>element name="interface" nm:key="name"> + <>element name="name"> + <>data type="string"/> + <>/element> + <>optional> + <>element name="mtu"><>a:documentation>The MTU of the interface.<>/a:documentation> + <>data type="unsignedInt"/> + <>/element> + <>/optional> + <>/element> + <>/zeroOrMore> +<>/start> +<>/grammar> + +Outre pyang, il y a bien entendu même un mode Emacs, yang-mode[7]. + +Le site officiel du projet, http://www.yang-central.org/[8], contient beaucoup +d'autre information sur YANG. + +Notez que l'ancien YANG, 1.0, décrit dans le RFC 6020, n'est pas abandonné. +L'ancien RFC reste d'actualité pour décrire la version 1.0, qui restera en +usage un certain temps. Les principaux changements apportés par la version 1.1 +de YANG sont décrits dans la section 1.1 du RFC. La liste est très longue, mais +la plupart ne sont que des points de détail. Parmi les changements qui peuvent +rendre illégaux des modèles YANG qui étaient légaux avant, il y a par exemple +le changement d'interprétation des échappements dans les chaînes de caractères, +ou bien le fait qu'une chaîne de caractères qui n'est pas encadrée par des +apostrophes ou des guillemets n'a plus le droit de contenir des apostrophes ou +guillemets (section 6.1.3). De même, les clés (identificateurs uniques) ne +peuvent plus être conditionnelles (instructions when ou if-feature) ce qui est +logique, mais rend également invalide certains anciens modèles YANG. + +Liens: +[1]: http://www.netconfcentral.com/modulereport/ietf-inet-types (lien) +[2]: http://www.ietf.org/mail-archive/web/discuss/current/msg00987.html (lien) +[3]: http://www.yang-central.org/twiki/bin/view/Main/ComparingYang (lien) +[4]: http://www.aims-conference.org/issnsm-2008/06-netconf-yang.pdf (lien) +[5]: http://www.yang-central.org/twiki/bin/view/Main/YangTools (lien) +[6]: http://code.google.com/p/pyang/ (lien) +[7]: http://www.yang-central.org/twiki/pub/Main/YangTools/yang-mode.el (lien) +[8]: http://www.yang-central.org/ (lien) -- cgit v1.2.1