Je vous propose de venir en parler a un meetup que nous organisons ce soir dans nos locaux 32 rue Blanche a Paris à partir de 17h00 nous couvrirons les sujets des DC L3, l'automatisation et l'urbanisation industrielle des DC.
L'artisanat dans les réseaux à vécu son temps, à la scale à laquelle nous opérons nous ne pouvons plus nous permettre de faire de l'artisanat. Qu'on le veuille ou non le métier de plombier réseau va s'orienter vers le rôle de dev réseau dans les 5 prochaines années. 2015-06-25 11:47 GMT+02:00 David Ponzone <david.ponz...@gmail.com>: > 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/
