Oui, j’allais un peu dire la même chose. Le monde financier aussi a tout passé en algorithmes. On voit le résultat, et encore, il nous a pas pété à la gueule. Je me pose des questions sur la stabilité long-terme d’un réseau géré par du code « intelligent » .
Le 25 juin 2015 à 11:42, Julien Schafer <j.scha...@actilogie.com> a écrit : > C'est bien cela qui me fait peur. > > Je n'irai pas jusqu'à dire qu'il n'y a jamais de bugs sur du matériel réseau, > mais franchement ce que j'ai pu vivre et voir chez mes différents clients est > de la rigolade au regard des problèmes que génèrent les OS, BDD, applis mal > codées etc > > Si c'est pour appliquer le même modèle au monde des réseaux (qui globalement > tourne bien) je suis pas sur du réel intérêt ;) > > -----Message d'origine----- > De : frnog-requ...@frnog.org [mailto:frnog-requ...@frnog.org] De la part de > Michel Moriniaux > Envoyé : jeudi 25 juin 2015 11:30 > À : Romain De Rasse > Cc : Olivier Cochard-Labbé; Thomas Barandon; Jérôme Nicolle; Liste FRnoG > Objet : Re: [FRnOG] [TECH] SDN chez Google > > Bonjour, > ce n'est qu'une question de s'y mettre, il y a énormément d'outils libres sur > lesquels on peut se baser aujourd'hui. > > la CLI est un dinosaure qu'il faut laisser s’éteindre mais malheureusement > c'est la seule "API" universellement disponible. (bon, peut-être pas vu que > beaucoup d'APIs constructeurs ne sont que des wrappers XML de CLI) > > https://github.com/criteo/netcompare > netcompare est une des premières briques que nous publions d'un framework > complet d'automatisation développé chez nous qui nous permet de gérer nos DC > et WAN programmatiquement, nous allons bientôt publier d'autres modules pour > équipements a commit non-atomiques qui s'intègrent dans Ansible et qui > pourront étendre Napalm. > > le SDN est un acronyme galvaudé qui comme le "cloud" veut tout et rien dire. > Pour nous le SDN ce n'est pas programmer un dataplane mais gérer tous les > aspects d'un réseau par des algorithmes. > > > 2015-06-25 6:59 GMT+02:00 Romain De Rasse <rom...@de-rasse.fr>: > >> Bonjour, >> >> Je n'ai pas testé mais il y a l'air d'y avoir des pistes niveau "devops" >> réseau par exemple : >> https://github.com/spotify/napalm/blob/master/README.md qui vient avec >> un plugin ansible. >> >> RDR >> >> Le 25 juin 2015 06:33:31 GMT+10:00, "Olivier Cochard-Labbé" < >> oliv...@cochard.me> a écrit : >>> 2015-06-24 21:01 GMT+02:00 Thomas Barandon <t.baran...@gmail.com>: >>> >>>> Hi, >>>> >>>> >>>> Bref, le SDN c'est bon. Mangez en. De toute façon il faudra >>>> composer >>> avec. >>>> >>>> >>> Juste un «détail» qui me chiffonne avec les solutions SDN du moment: >>> Ou >>> est passé le principe KISS ? >>> Prenons l'exemple de Juniper Contrail (je prends cet exemple >>> uniquement car la solution fonctionne pas mal et la doc bien foutue): >>> >>> cf le white paper "CONTRAIL ARCHITECTURE", Figure 1 "Contrail system >>> overview": >>> http://www.juniper.net/us/en/local/pdf/whitepapers/2000535-en.pdf >>> >>> Donc sur ce schéma d'introduction simplifié (car réduire OpenStack à >>> un seul bloc, j'appelle cela de la simplification) je découvre un >>> joli mélange >>> de: >>> - XMPP, pour que routeur fasse des échanges multimédias ou du chat >>> entre eux et le contrôleur ? :-) >>> - BGP, normal c'est du réseau >>> - Netconf, tiens… enfin! >>> - API Rest, car c'est la mode de tout encapsuler dans HTTP… quelle >>> connerie d'avoir prévus 65535 ports pour TCP, alors qu'il en >>> suffisait de trois: >>> 53, >>> 80 et 443. >>> - Une couche d'overlay MPLS over GRE/UDP ou d'overlay VXLAN… >>> - Pourquoi absolument du MPLS over quelques chose et pas le faire >>> nativement ? >>> - VXLAN: quel intérêt en 2015, dans un monde IP, d'ajouter une >>> couche supplémentaire pour maintenir l'existence de domaines de >>> broadcast Ethernet entre serveurs ? >>> - hyperviseur >>> - Comment garantir le jitter minimum lorsque l'on doit traverser >>> plusieurs hyperviseurs ? (chainage de VMs) >>> >>> Et le pire: C'est que ça fonctionne. >>> Par contre le jour il y aura un problème: Qui est capable de >>> maitriser et comprendre l'ensemble des technos mis en œuvre dans une >>> telle solution ? >>> >>> >>> Cela me donne l'impression que la révolution SDN va vraiment trop vite. >>> J'aurai aimé une étape intermédiaire plus simple avant, comme par >>> exemple juste trouver une solution de déploiement automatisée de >>> configuration d'un réseau hétérogène. Netconf, après des années de >>> réflexions et je ne sais plus combien de RFC n'est toujours pas >>> utilisable à grande échelle dans un environnement vraiment >>> multi-constructeurs. >>> Le monde de l'IT n'ont pas perdus leur temps en discussion: Ils >>> disposent désormais de plusieurs solutions éprouvées qui leur permet >>> de gérer leur énormes parc de serveurs (ansible, puppet, chef, salt, >>> etc...). Et pendant ce temps là, nous au réseau: Que dalle! Pourtant >>> un serveur est autrement plus complexe à gérer qu'un simple >>> switch/routeur. >>> Cela nous aurai permis de commencer tranquillement notre migration en >>> mode "devops" au lieu de nous prendre la grosse claque SDN d'un coup. >>> >>> My two cents, >>> >>> Olivier >>> >>> --------------------------- >>> 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/ > > __________ Information provenant d'ESET NOD32 Antivirus, version de la base > des signatures de virus 11840 (20150625) __________ > > Le message a t v rifi par ESET NOD32 Antivirus. > > http://www.eset.com > > > > > --------------------------- > Liste de diffusion du FRnOG > http://www.frnog.org/ --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
