Hello Alexis, Je ne sais pas si je dois te prendre au second degré 😁😂, mais j'ai l'impression que ton propos illustre et justifie bien la nécessité de passer à un autre niveau de standardisation et d'automatisation, non?
Ton "cynisme" pousse plutôt ma curiosité et donne envie de dire que si en effet c'est exactement la situation dans ton équipe, on a clairement de quoi partir d'un use case concret. Ou alors je n'ai pas bien compris? Si non qu'est ce qui te dérange dans ma proposition? Suis-je totalement à côté de la plaque selon toi ? Si oui à quel niveau/sujet? Merci pour ta contribution. Eugène NG On Tue, Jul 15, 2025 at 4:44 PM Alexis Lameire <[email protected]> wrote: > 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> >> > -- [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/
