Bonjour à tous, Vos avis sont très intéressants.
Je profite de ce thread pour savoir si quelqu'un aurait entendu parlé de la société Sayse ? Ils sont spécialisés dans le SD-WAN et se revendiquent comme étant le premier opérateur SD-WAN français. Si certains ont des retours, je serai intéressé de les lire. De plus, savez-vous si il y a aujourd'hui beaucoup d'intégrateur SDN en France ? Ca a l'air d'être à la mode aux USA, mais chez nous j'ai l'impression que ça tarde à décoller. Cordialement, Quentin Envoyé de mon iPhone > Le 16 août 2017 à 16:34, Christophe LUCAS <christo...@lucas.fr.eu.org> a > écrit : > > Bonsoir, > > Je vais sans doute dire des bêtises, mais pour moi SD-WAN n’est juste que > l’aboutissement de ce qui se fait depuis longtemps avec DMVPN. Les avantages > que j’y vois. Faire du PFR sur plusieurs liens. Si on souhaite ne pas > investir sur du WAN, on peut facilement faire du VPN client meshé over IPSEC > avec DMVPN phase 3 (sans avoir x VTI de configurés). QOS par tunnel. Mais > DMVPN n’est pas nouveau. > > Si vous avez une autre vision de la chose, je suis preneur aussi d’avoir > votre vision. > > Cordialement, > --------------------------------------------------------------- > Christophe LUCAS > christo...@lucas.fr.eu.org <mailto:christo...@lucas.fr.eu.org> > --------------------------------------------------------------- > > > > > >> Le 14 août 2017 à 15:07, Jérémy RIZZOLI <jeremy.rizz...@gmail.com> a écrit : >> >> Hello, >> >> Merci pour ces retours constructifs, je rejoins le point de vue sur >> l'aspect "c'est pas nouveau", ça, je l'avais bien vu aussi. >> >> De ce que j'en comprend, il n'y a rien qui se fait en SD-WAN qui ne >> puisse pas se faire en "classique". >> >> Cela me parait être un package de technos adapté à quelqu'un qui monte >> un backbone/business from scratch et qui veut aller très vite, mais pas >> vraiment à quelqu'un qui a déjà une infra IP/MPLS en place, puisque le >> seul intérêt serait peut être pour de l'extension de réseau en mode >> Quick&Dirty ? >> >> Dans tous les cas, tout se repose sur Internet, et un ou plusieurs >> transits, et tu montes toute la logique au niveau applicatif en réalité >> et c'est bien fondamentalement ce qui me gène, je m'explique: >> >> On me demande actuellement dans un contexte d'opérateur télécom pur, de >> pousser vers du SD-WAN pour pouvoir se déployer plus rapidement à >> l'étranger. La cible qui est visée par mes chefs, c'est en gros de tout >> déployer directement dans AWS, dans une instance locale et d'y déployer >> complétement toute la panoplie en quelques clics. >> >> On a déjà notre backbone IP/MPLS, et clairement déjà les pieds dans le >> "SDN/NFV" pour le moment par des solutions qui nous sont propres en >> Cloud privé. >> >> Ma première idée était de déployer en DC un bête switch SDN + quelques >> hyperviseurs et de tout monter dessus avec des liens IP/MPLS tout ce >> qu'il y a de plus classique et dont on maitrise le coût (certe cher) et >> les latences, surtout qu'on saurait le faire sans trop de difficultés, >> mais voilà .. monter du physique, même si peu, ça prend du temps (trop >> de temps). >> >> En regardant de plus près le déploiement de ce type de solution, le truc >> intéressant serait notamment de déployer directement dans AWS ou autre, >> or je me suis vite rendu compte qu'on perdrait clairement en maitrise de >> l'infra, à savoir: >> >> Obligé de respecter les contraintes d'interco poussées par le/les >> fournisseurs de Cloud AWS, et autres, notamment sur l'entrée/sortie: >> passage obligé L3 par les routeurs du Fournisseur de Cloud qui font ce >> qu'ils veulent sur le trafic de leurs clients.., utilisation de LEURs IP >> publiques, etc etc .. >> >> Obligé au final de déployer en "overlay" de l'infra de tes fournisseurs >> de Cloud ou d'Internet, souvent à grands renforts d'IPSec dans tous les >> cas.. automatisé ou non, ça reste une couche en plus. >> >> Perte de la maitrise de la réalité physique du lien on ne sait plus >> finalement ce qui se passe exactement entre le point A et B, même pas un >> début d'idée, alors certes, certains répondront "on s'en care" mais pas >> complétement quand même .. si c'était si simple ça se saurait.. >> >> Perte de la maitrise du routage sous une certaine forme, puisque >> l'automatisation du ControlPlane SD-WAN fait que beaucoup de choses ne >> sont plus vraiment "prévisibles" à force d'empiler les couches .. >> certaines décisions pouvant être prises par l'applicatif en lui-même .. >> A noter que ça devient aussi une misère à analyser en cas de crash pour >> analyser toute la chaîne .. >> >> De façon générale, ça revient pour moi à déplacer des fonctions du >> réseau dans les couches hautes: L5/L6/L7 et à broder autour de ce qui >> existe chez les fournisseurs d'infra/Cloud aux couches L2/L3/L4 en leur >> faisant confiance à 100%.. ce qui sous une certaine forme peut >> apparaitre comme une sorte de déléguation / externalisation complète de >> "tout le merdier de l'infra, réseau compris". >> >> Au final, en dehors du fait de perdre en maîtrise globale sur les >> couches basses, chose qui apparait de plus en plus comme acceptable en >> 2017, j'ai comme l'impression que c'est surtout un débat entre "on prend >> la solution sur étagère qui s'appelle X-SD-WAN et qui fait papa/maman >> (et le café) ou on prend 2 ingés réseaux qui vont nous automatiser cela >> maison avec un outil qu'ils maitrisent. Je me trompe ? >> >> Est-ce que au moins les solutions sur étagère tiennent leur promesses ? >> Car de ce que j'en ai vu jusque là, il faudra toujours des ingés pour >> les mettre en route et les configurer .. et ça prend pas forcément moins >> de temps surtout vu le caractère quelque peu expérimental pour le moment >> de certaines .. contrairement à ce que nous vantent les prospectus. >> >> Quant à l'aspect coût global, j'ai tout de même un doute énorme sur la >> pérennité financière de ce genre de solutions... c'est peut-être plus >> avantageux à déployer en termes d'investissements initiaux, mais par >> contre les frais récurrents explosent dès qu'il s'agit de passer à >> l'échelle .. notamment à cause du fait que tu vas tout baser sur tes X >> fournisseurs de Cloud public qui vont bien entendu se gaver largement au >> passage .. et je parle même pas du support associé .. >> >> Bref, ça fait clairement se poser des questions sur ce qui est attendu >> du taff de l'ingé réseau en 2017 .. >> >> >> Jérémy >> >> >> >> Le 14/08/2017 à 12:13, Guillaume Barrot a écrit : >>>> "Néanmoins, j'ai quand même du mal à voir à qui s'adresse en terme >>> de cible, ce type de technos." >>> >>> Cible directe : service provider >>> Cible indirecte (les clients du service provider) : retail étendu >>> (grosse distrib, grosse distrib de carburant, etc.), multinationales >>> avec des agences à l'étranger (ex : boites de com' / pub', gros cabinets >>> d'avocats Paris / NY, agences de presse) >>> >>> Deux choses que tu fais en SD-WAN que tu peux faire en classique mais en >>> investissant du temps et des devs : >>> - aggregation de liens sur critère layer 7 (mptcp + DPI pour classifier >>> et envoyer le trafic dans tel ou tel tunnel) >>> - créer des VPN facilement, avec des points de terminaisons qui peuvent >>> être dans des clouds publics tiers (= s'affranchir des offres de type >>> cloud connect qui sont vendues un bras, et ne pas avoir à monter un >>> IPSEC à la main sur une VM Junisco ou PfSense). >>> >>> Donc gain pour le SP : offrir des accès en redondance actif-actif + >>> critères, et étendre son offre VPN en dehors de son backbone MPLS, sans >>> les couts de "je fais du DMVPN qui finit dans une VRF, et j'y crois à >>> mort, ça va marcher" >>> >>> C'est pas révolutionnaire du tout, c'est un package de technos déjà >>> existantes depuis des années. >>> Chez Cisco c'est l'aboutissement d'une stratégie qui a démarré avec PFR >>> il y a presque 10 ans, c'est dire. >>> >>> Après à l'usage, à part le MPTCP qui a un usage concret démontré (cf : >>> OTB OVH), le reste est un enrobage bullshitomarketing pour ne pas avoir >>> à monter son Ansible soit même. >>> Mais ça a l'avantage de fonctionner, contrairement à vouloir réintégrer >>> ça soit même dans une Debian + Quagga + DPDK (faisable, ceci dit, mais >>> au combien casse gueule). >>> >>> Le 14 août 2017 à 11:29, Richard Klein <varicap....@gmail.com >>> <mailto:varicap....@gmail.com>> a écrit : >>> >>> Voir : >>> >>> http://www.zdnet.fr/actualites/sd-lan-et-sd-wan-deux-approches-differentes- >>> pour-le-software-defined-networking-39841794.htm >>> >>> <http://www.zdnet.fr/actualites/sd-lan-et-sd-wan-deux-approches-differentes- >>> pour-le-software-defined-networking-39841794.htm> >>> >>> Ou plus proche des clients GP la Livebox décentralisé. .. >>> >>> C est assurément une bonne idée mais mon principe à moi c est de >>> garder mes >>> données chez moi et de rester indépendant ( a 99%) d'une infra que je ne >>> maîtrise pas. >>> >>> Question il se passe quoi quand votre chaîne à le maillont faible >>> qui est >>> cassé ? >>> >>> Et sur la sécurité les experts en pensent quoi ? Le jour où il y a une >>> faille tous tombe ? >>> Principe de base d'un grand penseur de l'internet : tous ce qui >>> passe sur >>> internet est susceptible d'être publique >>> >>> Richard >>> >>> Le 14 août 2017 11:08, "David Ponzone" <david.ponz...@gmail.com >>> <mailto:david.ponz...@gmail.com>> a écrit : >>> >>> C'est rigolo, pour moi, le SD-WAN c'était l'inverse: plus d'intelligence >>> dans le CPE pour s'affranchir de la dépendance à un carrier. >>> >>> David Ponzone >>> >>> >>> >>>> Le 14 août 2017 à 17:01, Solarus <sola...@ultrawaves.fr >>> <mailto:sola...@ultrawaves.fr>> a écrit : >>>> >>>> Le 2017-08-14 09:48, Jérémy RIZZOLI a écrit : >>>> >>>>> Néanmoins, j'ai quand même du mal à voir à qui s'adresse en terme de >>>>> cible, ce type de technos. >>>> >>>> Salut Jérémy. >>>> >>>> Le principal intérêt que je vois au SD-WAN c’est de pouvoir >>> envoyer chez >>> les clients des boitiers moins «intelligents» et donc moins chers, >>> l’intelligence étant gérée en cœur de réseau. >>>> L’avantage c’est que le boitier n’a plus qu’à gérer le lien physique >>> (ADSL, SDSL, FO), la couche IP étant gérée au niveau du backbone, ce qui >>> limite le risque d’erreur de conf sur les routeurs distants. >>>> Les configurations sont récupérées depuis le cœur de réseau, ce qui >>> facilite les déploiements. >>>> >>>> L’autre avantage c’est qu’on centralise l’intelligence réseau et la >>> puissance nécessaire sur les contrôleurs SDN et les PE, ce qui >>> facilite les >>> upgrades puisqu’il y a moins de matériel à changer chez les clients. >>>> Sinon oui, le principe c’est équivalent à celui de puppet ou >>> ansible, il >>> s’agit de tout «masteriser» à distance à partir d’un contrôleur. >>>> >>>> De toute façon c’est le modèle poussé par Juniper et Cisco qui se >>> font la >>> guerre sur ce secteur donc on risque d’y passer bon gré,mal gré. >>>> >>>> Cordialement. >>>> Solarus. >>>> >>>> >>>> --------------------------- >>>> 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/ >>> >>> >>> >>> >>> -- >>> Cordialement, >>> >>> Guillaume BARROT >> >> >> --------------------------- >> 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/
