Bonjour Eugène, Je vais être très très cynique, mais bon nombre de réseaux où déjà du mal à pousser un template de config paramétrique et d'avoir une source de vérité qui fait foie sur le déploiement des configurations.
Le mot CI/CD est aujourd'hui un gros mot pour beaucoup d'équipes. Je ne peux clairement que partager ton avis :) Je veux bien éventuellement présenter mon travail en amateur sur yang et pouvoir en décrire de façon plus formelle. C'est un sujet qui est aujourd'hui beaucoup discuté coté RIPE, mais on ne vois pas trop ce sujet dans notre nog préféré ! Cordialement Alexis Lameire PS : j'ai changé le titre pour pas flooder ;) Le mar. 15 juil. 2025 à 16:18, Eugène NGONTANG <[email protected]> a écrit : > *Objet : [FRnOG 42.0] Proposition de talk – YANG, Netconf et > l’industrialisation de l’automatisation réseau* > > Bonjour à tous, > > Les échanges récents sur YANG, Netconf et l’agnosticité des modèles m’ont > beaucoup parlé — notamment les retours d’Alexis et Julien sur la difficulté > d’avoir des modèles réellement transverses, et sur la complexité de > l’automatisation au-delà des templates. > > Chez *SPITZKOP*, on accompagne des opérateurs (notamment dans les > télécoms) dans l’*industrialisation de leurs opérations réseau*. Et ce > qu’on observe, c’est que : > > - *YANG est sous-utilisé* comme levier de validation et de > standardisation > - Beaucoup d’équipes restent bloquées sur des scripts maison, sans > pipeline de validation > - L’*intégration de YANG dans une chaîne CI/CD réseau* est encore > rare, mais possible > > 🎤 *Je proposerais bien un talk pour FRnOG 42.0* autour du sujet suivant : > > *“YANG dans un pipeline GitOps : de la modélisation à la validation > continue”* > > Avec un retour d’expérience structuré : > > - 📐 Comment intégrer YANG dans une chaîne CI/CD réseau > - ✅ Validation de config *a priori* (avant push) via les modèles > - 🔁 Gestion multi-constructeurs : abstraction pragmatique vs > agnosticité idéale > - 🧪 Démo live ou replay d’un pipeline GitLab CI avec validation YANG > + déploiement Netconf > > L'idée c'est d'aborder le sujet par le prisme d'un retour terrain, sans > bullshit, avec des cas concrets > > Si le sujet vous intéresse, je suis partant pour le construire avec la > communauté. > Mais j'ai bien d'autres sujets relevant de notre expertise que sur > lesquels je veux/peux bien échanger avec @[email protected] > <[email protected]>. Je te contacterai en privé comme demandé, pour en > savoir plus sur les modalités de participation, notamment le sponsoring. > > Bien cordialement, > Eugène NG > > > > On Tue, Jul 15, 2025 at 3:43 PM Julien LE CAM <[email protected]> wrote: > >> Ce que tu dis est intéressant et peut faire un débat, les modèles ietf >> sont >> censés être transverses donc simplifié d'une certaine façon >> l'automatisation. Ensuite c'est pas parce que le modèle est agnostique que >> cela implique changement ou abandon d'un constructeur au profit d'un >> autre, >> il y aura probablement toujours un use case qui impose un juniper plutôt >> qu'un Cisco ou arista. >> >> Le mar. 15 juil. 2025 à 13:56, Alexis Lameire <[email protected]> >> a >> écrit : >> >> > Pour le coup je fais énormément d'automation, >> > >> > Je ne demande clairement pas d'être agnostic au constructeur, ce n'est >> pas >> > dans l'intérêt d'un constructeur de se rendre remplaçable as is en >> termes >> > de configuration. >> > >> > J'ai eu plusieurs fois à faire des conversions d'un os A à un os B. au >> > final quand la configuration est bien abstraite le travail d'écriture >> des >> > templates est souvent assez minime. C'est moins de 10% du travail >> > d'automation. >> > Ce qui est complexe c'est d'avoir un OS bien foutu pour être réellement >> > transactionnel Dans l'état de mes test : arista, juniper, nokia, la >> gamme >> > en ios XR de chez cisco sont compliant. Huawei, cisco nxos/xe/ios ne le >> > sont pas (ceci dit j'ai pas vérifié en version 10 sur nxos). Chez Huawei >> > j'ai été surprise mais je pense que yang peut être une solution ici. >> > >> > Ce qui est ennuyeux dans l'approche fichier (CF un précédent FRnOG) >> c'est >> > qu'il faut pousser la config sur le switch pour être sur que celle-ci >> est >> > valide. Avec yang, on peut le vérifier à priori en validant la >> > configuration contre le modèle. >> > >> > Bonne journée >> > Alexis Lameire >> > >> > Le mar. 15 juil. 2025 à 12:20, Julien LE CAM <[email protected]> a >> écrit : >> > >> >> Hello, >> >> >> >> Oui bien sur netconf n'est pas yang, netconf est la protocole qui >> >> transfert des blocs là où yang est un data model. De mon point de vue >> yang >> >> n'a pas encore atteint un de ses objectifs d'être "agnostique", pas >> assez >> >> de modèle ietf (rfc8299, 9181...), pour avoir joué avec sur xe, xr, >> junos >> >> et sros, il y a toujours des bouts à modifier. >> >> https://github.com/YangModels/yang/tree/main/vendor >> >> >> >> Le mar. 15 juil. 2025 à 11:53, Alexis Lameire < >> [email protected]> >> >> a écrit : >> >> >> >>> Hello Julien, >> >>> YANG != NETCONF. >> >>> >> >>> Clairement, netconf c'est de la merde et ça doit être remplacé. Par >> >>> contre yang c'est ni plus ni moin qu'un langage de description de >> grammaire >> >>> de configuration réseau. C'est assez proche de antlr ou yacc au >> final. Ce >> >>> qu'il est intéressant c'est qu'il est possible de transformer >> >>> cette grammaire en objet fortement typé permettant de manipuler une >> >>> configuration réseau. >> >>> >> >>> De plus, le format yang impose d'avoir des OS >> >>> réellement transactionnels ce qui manque sur l'automation réseau. >> >>> Si tu veux en voir plus : >> https://www.youtube.com/watch?v=CM3sT55zwt0 >> >>> : un bon tuto >> >>> >> >>> Si tu veux j'ai tenté une implémentation en lab d'une fabrique evpn. >> >>> J'arrive à déployer une fabrique entière en moins de 5s. les technique >> >>> classique basé sur ansible c'est de l'ordre de la minute :) >> >>> >> >>> Alexis >> >>> >> >>> >> >>> Le mar. 15 juil. 2025 à 11:24, Julien LE CAM <[email protected]> a >> >>> écrit : >> >>> >> >>>> Yep pour Yang mais il semble que la tendance aille plutôt vers une >> >>>> généralisation des api plutôt que yang. Je sais que chez juniper, >> fortinet >> >>>> et autres il y a plus de demande pour api que yang, chez cisco >> j'arrive pas >> >>>> à savoir. >> >>>> Il y a aussi l'ia, orchestration et gestion des réseaux par ia, qqun >> à >> >>>> déjà fait la proposition. >> >>>> Les avancées du segment routing >> >>>> Réseaux quantique et classique=>rfc8784, rfc9370.... >> >>>> >> >>>> Le mar. 15 juil. 2025 à 11:04, Alexis Lameire < >> [email protected]> >> >>>> a écrit : >> >>>> >> >>>>> Hello Julien, >> >>>>> Pour le coup j'ai un peu toucher à yang récamment ;) et il y a des >> >>>>> trucs à en dire :) >> >>>>> >> >>>>> Alexis >> >>>>> >> >>>>> Le mar. 15 juil. 2025 à 07:28, Julien LE CAM <[email protected]> a >> >>>>> écrit : >> >>>>> >> >>>>>> Hello, >> >>>>>> >> >>>>>> Pour le programme, pourquoi pas l'automatisation des réseau, par >> >>>>>> exemple, >> >>>>>> yang versus api, un autre sujet comme le multicast en srv6, cad >> >>>>>> tree-sid, >> >>>>>> mldp ou bierv6, ou en est on, etc... >> >>>>>> >> >>>>>> Julien >> >>>>>> >> >>>>>> Le mar. 15 juil. 2025 à 01:26, Philippe Bourcier < >> [email protected]> >> >>>>>> a >> >>>>>> écrit : >> >>>>>> >> >>>>>> > >> >>>>>> > Bonjour, >> >>>>>> > >> >>>>>> > La prochaine réunion FRnOG sera le 24 Octobre 2025. >> >>>>>> > >> >>>>>> > Je suis à la recherche de sponsors et de sujets pour le programme >> >>>>>> alors >> >>>>>> > n'hésitez pas à me contacter (off list). >> >>>>>> > >> >>>>>> > >> >>>>>> > Cordialement, >> >>>>>> > Philippe Bourcier >> >>>>>> > >> >>>>>> > --------------------------- >> >>>>>> > Liste de diffusion du FRnOG >> >>>>>> > http://www.frnog.org/ >> >>>>>> > >> >>>>>> >> >>>>>> --------------------------- >> >>>>>> Liste de diffusion du FRnOG >> >>>>>> http://www.frnog.org/ >> >>>>>> >> >>>>> >> >> --------------------------- >> Liste de diffusion du FRnOG >> http://www.frnog.org/ >> > > > -- > [image: This is Eugène Ngontang's card. Their email is > [email protected]. Their phone number is +33 7 60 59 77 44.] > <https://hihello.me/p/bb1ee419-e82f-484e-83f9-aea032b7c130> > --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
