Openflow n'est pas encore un standard, mais c'est une interface générique.
Le mot standard en Français n'est pas équivalent à standard en anglais. Cette phrase doit se traduire : " Open est la première interface générique pour les SDN". OpenFlow set considéré comme une des solutions possible pour le SDN et il y'a eu à ce sujet un BoF meeting à l'IETF en 2011. Pour une analyse plus complète de l'état de standardisation IETF d'openflow et des SDNs voir http://networkstatic.net/new-ietf-sdn-drafts/ Ceci dit le concept même de SDN c'est d'être capable d'implémenter sur son routeur des solutions non standard, voir de faire co-exister sur une même plateforme matérielle des approches compatible IPv4/v6 et des approches clean-slates (genre CCN). Kv Le 28 mars 2013 à 22:56, Adrien Pestel <pestoui...@gmail.com> a écrit : > "OpenFlow is the first standard interface designed specifically for SDN" > > > > Le 28 mars 2013 22:53, Kavé Salamatian <kave.salamat...@univ-savoie.fr> a > écrit : > Et vous un standard et une proposition de norme … :-) > 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/ > > --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
