Il est clair que l'Open Networking Summit est un organisme de standardisation reconnu. Parce que Fuck les RFC, c'est ça ?
http://www.1-4-5.net/~dmm/talks/sdn_is_an_architecture_wtc2012.pdf Slide "programmable network architecture" : les propositions d'extensions pour des protocoles existants sont TRES nombreuses pour le coup ... Le 28 mars 2013 22:46, Adrien Pestel <pestoui...@gmail.com> a écrit : > Et toi tu confonds un concept et un standard... > > Bonne lecture : > > https://www.opennetworking.org/images/stories/downloads/white-papers/wp-sdn-newnorm.pdf > > Adrien > > > Le 28 mars 2013 11:58, Gunther Ozerito <gozer...@gmail.com> a écrit : > > Toujours pas ... >> >> Tu confonds SDN, Openflow, et les networks overlay ... c'est pas de bol >> quand même, suffit juste de lire les docs pour pas les confondre. >> >> *SDN* : possibilité donné dans un réseau de modifier les comportements >> de routing et de forwarding sur des critères normalement pas pris en compte >> par les protocoles standard. >> Ex : par defaut, on route sur la destination, BGP me donne des >> informations de reach de destination, qu'il compile pour alimenter la RIB, >> laquelle elle même impacte la FIB pour savoir par quelle interface vont >> sortir les paquets. Je veux faire du routage différencié en fonction de la >> source (toutes les IPs venant de mon DC01 : next-hop = toto, pour tout le >> reste, conforme à la RIB, next-hop = tata), avec au hasard du Policy Based >> Routing. >> Si en plus je pilote les ACLs de mon PBR avec un script qui par exemple >> va modifier ces entrées en fonction de la latence mesurée sur les liens = >> SDN. >> >> *application* : backbone, datacenter, ... >> >> *Openflow *: protocole en cours de standardisation pour échanger des >> infos entre un control plane externe, et un dataplane d'équipement réseau >> standard. Evite d'avoir à scripter pour passer des commandes en SSH sur les >> routeurs, et permet aussi de faire des trucs que les commandes CLI ne >> permettent pas (au hasard, injecter des infos directement dans la RIB ou la >> FIB, sans avoir de protocole dynamique). >> >> *application* : backbone, datacenter, ... >> >> SDN - openflow interop lab <http://incntre.iu.edu/SDNlab> : lancé en >> 2011 pour voir comment accoster les deux technos entre elles. >> >> Openstack Quantum, Nicira, etc : type de collecteurs partiellement ou >> totalement compatible Openflow, mais aussi avec des fonctionnalités >> propriétaires ou d'autres protocoles (netconf). >> VXLAN, NVGRE et nicira stt : techno de network overlay, consistant à >> encapsuler les trames ethernets dans des trames de niveau 3 (GRE ou UDP). >> Aucun rapport avec SDN, ce sont des technos qu'on peut éventuellement >> mettre en concurrence avec VPLS, L2TPv3, OTV, etc... >> >> Donc non le SDN c'est pas que pour de la virtualisation, et ce depuis >> longtemps, et c'est une notion qui existe depuis très longtemps dans le >> backbone (Performance Routing chez Cisco, Path Computation >> Element<http://en.wikipedia.org/wiki/Path_computation_element>depuis des >> années à l'IETF). >> >> Juste pour bien comprendre, sans SDN, vous me direz comment vous injectez >> du trafic purement voix dans un MPLS TE entre deux sites distants, en >> assurant que le trafic non classifié voix au niveau DSCP ne passe pas dans >> le tunnel... Et non, ce n'est pas du tout compatible avec la "neutralité du >> net", mais on s'en fout car on est dans la vraie vie, pas à Standford, et y >> a des contraintes réelles qui font qu'on doit bosser. >> >> Aller encore deux bullshits marketing pour bien se mélanger les pinceaux >> : trill et lisp. SDN ou pas ? >> >> >> Le 28 mars 2013 09:55, Adrien Pestel <pestoui...@gmail.com> a écrit : >> >> Je reprend pour être plus clair (il faut être vigilant quand on poste sur >>> FrNog les experts ont vite fait de nous rabaisser :)) >>> >>> Problématique : >>> - Dans un environnement virtualisé (machine virtuelle) les >>> caractéristiques réseaux (QoS, ACL, VLAN...) doivent pouvoir dynamiquement >>> se déplacer dans le Datacanter (au grès de l'hyperviseur) >>> >>> Concept : >>> - Rendre les équipements réseaux (virtual switch, switch physique, >>> routeurs) plus "bêtes" (commutation, application de règles en remontant les >>> flows) piloté par un composant applicatif plus intelligent / centralisé >>> >>> Implementation : >>> - Nicira >>> - Chaîne Openflow / Openvswitch / NOX | Beacon >>> - ... >>> >>> Si tu prends les éléments de manière individuelle ou atomique cela ne >>> constitue pas du SDN, c'est l'ensemble de la chaîne qui le constitue. >>> >>> Je te rejoins sur le fait que c'est un terme Marketing (Cloud ?) mais >>> derrière cela adresse des contraintes de sécurité, de QoS et surtout, >>> surtout d'exploitation. >>> >>> On peut toujours tout faire maison mais : >>> 1) ce sera peut être plus coûteux >>> 2) ce sera peut être plus difficile à maintenir et moins industrialisé >>> >>> Cela revient au débat, moi j'utilise un routeur Quagga parce que je me >>> sens capable d'aller modifier le code du daemon BGP alors que je ne fais >>> pas confiance au support et dans les produits des équipementiers (Juniper, >>> Cisco...). >>> >>> Une question me vient à l'esprit, comment adresses tu ces problématiques >>> (récentes ?) depuis plus de 10 ans ? >>> Sachant que pour mener à bien ce genre de mission il faut aller taper >>> dans le code du Virtual switch de l'hyperviseur (les switchs virtuels >>> distribués n'ont pas 10 ans d'existences) ... >>> >>> Le sujet n'est pas simple quand tu es à l'interieur d'un DC maintenant >>> si tu l'étend à plusieurs... >>> >>> -- >>> Adrien >>> >>> >>> Le 28 mars 2013 00:18, Gunther Ozerito <gozer...@gmail.com> a écrit : >>> >>>> Et encore faux. >>>> Encapsuler du niveau 2 dans du niveau 3 n'est pas du SDN. Openflow et >>>> openstack non plus. Nvgre et vxlan non plus... Nexus 1000v et Openvswitch, >>>> toujours pas... >>>> >>>> Cloudstack quantum ? Non mais a la limite on se rapproche un peu si on >>>> scripte un peu autour de cet outil. >>>> >>>> Une machine sous Linux qui collecte les resultats de sondes ipsla, de >>>> stats netflow, les lsa ospf, les annonces bgp, qui mouline tout ca et qui >>>> se connecte en ssh sur des routeurs pour changer des ACL pour du PBR, ou >>>> des metriques de routage, la oui. >>>> Si en plus cette meme machine surveille des applications et change les >>>> politiques de routage en fonction du fonctionnement des ces applis, polée >>>> en SNMP par exemple, alors la on est tres proche du SDN. >>>> >>>> Encore une fois, c'est un terme marketing pour faire peur, mais c'est >>>> des technos connues depuis des années ! >>>> Le 25 mars 2013 21:42, "Adrien Pestel" <pestoui...@gmail.com> a écrit : >>>> >>>> Salut, >>>>> >>>>> Je ne l'ai pas forcément compris comme ça ou tout du moins ce n'est >>>>> pas ce >>>>> que j'en ai retenu. >>>>> Je crois que la finalité c'est de dire aujourd'hui votre sécurité et >>>>> plus >>>>> largement le control plane est traité localement (dans votre switch >>>>> physique, dans votre switch virtuel, vos routeurs...). >>>>> >>>>> Demain on vous propose de remonter le control plane dans des >>>>> appliances et >>>>> de gérer de manière transverse a à votre/vos DC la QoS et la sécurité. >>>>> >>>>> Ce sont principalement les problématiques liés à la >>>>> virtualisation/cloud >>>>> qui ont amené à ce genre de réflexion, car le réseau LAN gérer de >>>>> manière >>>>> traditionnelle trouve ses limites. >>>>> >>>>> Nicira (racheté par VMWare) propose une implémentation de ce type de >>>>> modèle >>>>> (des tunnels GRE de ce que j'en ai compris entres les hyperviseurs). >>>>> >>>>> Adrien >>>>> >>>>> >>>>> Le 25 mars 2013 19:19, Olivier Cochard-Labbé <oliv...@cochard.me> a >>>>> écrit : >>>>> >>>>> > Bonjour, >>>>> > >>>>> > Il y a un truc qui semble être de plus en plus à la mode: le >>>>> > software-defined networking (SDN). >>>>> > J'ai donc regardé de plus prêt la solution OpenFlow et le concept du >>>>> > «flow» me fait tiquer. >>>>> >>>>> > Si j'ai bien compris, dans un SDN on ne route plus un paquet en >>>>> > fonction de son IP de destination mais en fonction de plusieurs >>>>> > paramètres tel que: IP source, IP dest, TCP source, TCP dest, etc… >>>>> > >>>>> > Or la définition de la neutralité du réseau «exclut ... toute >>>>> > discrimination à l'égard de la source, de la destination ou du >>>>> contenu >>>>> > de l'information transmise sur le réseau» (Wikipedia). >>>>> > >>>>> > J'ai donc comme l'impression qu'un SDN ne peut, par nature, être un >>>>> > réseau neutre. >>>>> > Est-ce que je me trompe ? >>>>> > >>>>> > Merci >>>>> >>>>> > >>>>> > >>>>> > --------------------------- >>>>> > 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/
