"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/

Répondre à