Bonjour Gregory, Merci de contribuer a ce fil un vendredi, cette année a cruellement manqué de vendredis.
Attention, entre David et Michel, un océan les sépare. Oui, les jolies interfaces ( enfin, les moches ) ne datent pas d'hier, c'est sûr. Et elles sont sans doute plus jolies et plus performantes aujourd'hui, mais nous ne sommes pas là pour dénoncer le non-respect de la console en 80 colonnes, on est intégristes, mais pas trop. Le SDN, enfin, plutôt son époque emmène avec elle un changement radical de philosophie, sous le couvert de produits mieux finis et plus léchés, nous sommes attirés vers le vendor lock-in, comme hier, mais en plus, nous n'achetons plus de produits aujourd'hui, mais des boites-a-a-service. Alors sans doute, il y a le bon et le mauvais SDN, mais j'aimerais bien qu'on arrête de me vendre un concept magique et qu'on explique quelles solutions apporte à quel problème un produit donné, et qu'on arrête les management centralisés obligatoires et autre abonnement si-tu-le-prends-pas-je-route-plus-tes-paquets, je veux avoir le choix d'arrêter de payer le vendeur si le service n'est pas rendu, car j'ai déja payé le produit. Au final, certaines solutions pourtant pertinentes technologiquement se font éconduire a la porte car apportant plus de restrictions que d'avancées. Ouaip, c'est bien de faire du CI/CD et de lâcher la CLI, mais l'obliger, je veux que ce soit ma décision et pas celle du vendeur alors que rien ne le justifie technologiquement. Moi, j'aime bien openvSwitch, en plus y'a pas SDN dans le titre, ni dans la description, c'est open, c'est virtual, c'est un switch. même le titre apporte une réponse a une problématique donnée, Soyons polis, arrêtons les gros mots, et ne parlons plus de ces Satanés Devices Novateurs. Kévin Le ven. 28 mai 2021 à 16:17, Gregory CAUCHIE <greg.cauc...@gmail.com> a écrit : > Bonjour, > > au risque d’être vu pour ce que je ne suis pas, je reprend ci-dessous un > extrait d’une autre discussion FRnOG de ce jour en lien avec l’objet de > cette discussion. > > > Le 28 mai 2021 à 08:59, David Ponzone <david.ponz...@gmail.com> a écrit > : > > > > > >> Le 28 mai 2021 à 08:23, Michel Py <mic...@arneill-py.sacramento.ca.us> > a écrit : > >> > >> > >> Yàkà acheter la solution SD-WAN et laisser le clickodrome automagique > tout faire :P C'est démodé, ton modèle : laisser l'ingénieur réseau faire > de la configuration ? pfff. > >> > > > > Ouais et avec un peu de chance, ça fait comme Kosc: ça pousse une > mauvaise conf sur tout le backbone et tu dois envoyer des techs dans la > nuit pour restaurer :) > > > > Il y a deux choses qui me donnent envie de réagir à cet extrait. > > La première chose nest pas d’être contre David ni Michel, je ne les > connais pas d'ailleurs et ces échanges me font dire que je prendrais bien > une bière avec eux, dès qu’on pourra, pour faire connaissance et alimenter > la discussion :). C’est plutôt de tenter de comprendre d’où vient cette > croyance que dans SDx (pour faire court) il n’y a plus de gens du réseau > réseau qui contrôlent, font des choix, debug ni tordent le truc au plus > proche de ce qu’ils souhaitent ? > Pour ma part en tout cas, je n’ai jamais vu d’offre d’IA capable de > générer toute seule une configuration réseau capable de répondre à la > demande du DSI, métier, ou autre réseau-phobe… donc il est et reste > toujours besoin d'au moins un(e) barbu(e) qui s’y colle quoi qu’il arrive, > de l’étape de design au troubleshooting. Si l’on fait une archi SDN à base > de netbox + jenkins|AWX + ansible, comme la contribution récente de Jerikan > par exemple, impossible de la réaliser sans personnes du réseau. Idem si > l’on fait du SDN à la mode OpenFlow, ou en SD-WAN, faut bien des > connaissances réseau pour gérer la configuration du système de > connectivité. Et puis les clickodrome qui génèrent de la config datent de > bien avant le SDN, par exemple sur les ASA et catalyst pour ne citer qu’eux. > Est-ce au final une « peur » de ne plus avoir d’accès CLI ? Le SDN > n’implique pourtant pas la fin complète et définitive du CLI mais pousse, > comme le monde des admin-sys l'a adopté en majorité, à un CLI restreint à > l’accès en lecture et avec une poussée des config via le CI/CD pour tracer > les changements et éviter au maximum de pousser une connerie (car dans SDN > il n’y a pas de fonction auto-magique de prévention des bêtises, cette > pseudo-fonction est le résultat de l’expérience des gens mise sous code > pour jouer des tests de non-régression de façon systématique). Comment > l’expliquez-vous ? > > La deuxième chose qui me donne envie de réagir, c’est que pendant ce temps > là on ne parle pas de tout le lot de problèmes et de questions qui restent > ouverts avec le SDN « d’aujourd’hui ». On a un peu évoqué le vendor-lock… > sujet qui ne date pas du SDN/SD-WAN et qui reste un sujet important. On ne > parle pas de nos outils de management et leurs IHM qui, d’aussi loin que ma > mémoire remonte (i.e. HP-NM), nous font râler au quotidien. Le SD-WAN n’en > est pas exempt. Etc. Bref on ne parle pas, du moins je ne le vois pas et je > suis preneur de correction si je me trompe, de comment on arrive à se > simplifier la tâche au quotidien pour un réseau qui donne plus de > satisfaction qu’il ne le faisait hier… et qui arrête d’être le coupable > tout désigné dès que ça toussote quelque-part. Vous partagez cet avis ? > > -- > Grégory > > --------------------------- > Liste de diffusion du FRnOG > http://www.frnog.org/ > --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
