Re: [FRnOG] [TECH] Buzz autour du SD-WAN

2017-08-18 Par sujet Philippe Bourcier 


Hello,

Je suis totalement d'accord avec le mail d'Olivier, il n'y a vraiment 
rien à jeter :
Faire une solution réseau basée sur un mélange de technos à la mode et 
de trucs moisis, sans regarder ce qui fonctionne déjà dans le domaine en 
question et en s'affranchissant des règles élémentaire de sécurité et 
d'archi logicielle (le coup de la db qui sert à la conf et à la data, 
c'est juste ENORME... je croyais que seuls les stagiaires mal aiguillés 
pouvaient encore faire ça). XMPP, XML... j'ai bien ri et ça laisse 
rêveur (ça me fait penser à pas mal de startups que je rencontre qui ont 
oubliées que les RDBMS existent et scalent aussi très bien).
T'as intérêt à avoir quelques ingés un peu pointu en système et en Java 
le jour où le cluster Cassandra part dans les choux et que tu ne peux pu 
admin ton réseau. Après, l'avantage quand on part de tout en bas, c'est 
qu'on ne peut que remonter :)


Et en grande partie avec Jérôme, mais je rajouterais bien mes 0.2c plus 
sur l'aspect "opportunité marché" :


Aujourd'hui le Mb/s reste plus cher à produire en WAN MPLS qu'en 
Internet... ne serait-ce que parce qu’il y en a moins (volume), que le 
transit ne coûte plus rien, qu'il y a plus de conf et que les GTR ne 
sont généralement pas les mêmes.
Ensuite, on sait bien que le VPN sur Internet, ça fonctionne bien... 
jusqu'au jour où tu remplies le lien ADSL/SDSL... donc sur sites isolés 
le lien dédié à encore de beaux jours devant lui car, comme le dit la 
légende : la meilleure QoS, c'est celle que tu n'as pas à appliquer.


Cela étant dit, deux choses viendront briser (chatouiller plutôt pour 
l'instant) cet état de fait :
1) le déploiement généralisé et global de la fibre optique (et l'offre 
bitstream qui va avec, pour se faire plus de marge...)
2) les technos d'aggreg de liens qui fonctionnent enfin vraiment : OVH 
OTB


Je vois donc un use-case qui peut vraiment booster le SD-WAN non pas 
chez les gros fournisseurs de WAN MPLS existants, mais plutôt pour des 
nouveaux entrants petits et moyens SP :
Combien d'opérateurs FR ont une offre MPLS sur toute l'Europe et toute 
la planète ?

Assez peu, finalement...

Avec le SD-WAN, un hébergeur, qui n'a que peu ou même pas du tout 
d'infra de collecte, genre OVH, Amazon, MS Azure, ou même n'importe quel 
SP FR un peu sérieux, peut lancer une offre WAN international pour 
entreprise, sans avoir à se taper la partie collecte et pour 
l'international les kilomètres de config de VPNs et avec un prix très 
attractif.
Le résultat c'est que pour s'aligner, notamment sur les prix, tout le 
monde va se mettre au SD-WAN et au final tout finira en VPN sur 
Internet. La loi du clodo computing dit que c'est toujours le truc 
facialement le moins cher et le plus simple pour le client qui s'impose.


Donc en dehors du bullshit marketing et des solutions moisis (il y en 
aura toujours), je vois cela comme :
 - une belle opportunité pour une startup de sortir un produit 
open-source qui ne ferait QUE CELA, MAIS BIEN

==> donc modèle freemium avec support pour gagner des $$$
 - une belle opportunité pour tous les hébergeurs et petit/moyens 
acteurs d'enfin pouvoir facilement et rapidement proposer une nouvelle 
couche de service à leurs clients : une offre WAN internationale, 
multi-technos (ie: 4G au Kenya, fibre à Seoul et N x SDSL dans la 
Creuse)
 - une opportunité de fournir rapidement et simplement du cloud privé 
en mode "coop", par exemple pour monter un serveur de fichier partagé 
entre N entreprises, pour un projet donné et un temps donné par ex... 
tout en gardant un niveau de sécurité bien plus élevé qu'en cloud pub ou 
SaaS... et puis les users préfèrent un partage à du web... surtout si 
c'est pour bosser sur des gros fichiers (genre projets archi/CAD).
 - une opportunité pour les opérateurs WAN régionaux, nationaux, 
d'étendre leur offre au-delà de leurs frontières actuelles

 - une chance pour les netops de se taper moins de conf

A terme on pourrait même imaginer une solution totalement "infraless", 
côté client, où chaque end-user dans l'entreprise run un client VPN en 
autorun sur sa machine. Client dont la config est automatiquement 
déployée en fonction d'une SSO Web-based. Le end-user se log sur son PC, 
le client VPN va chercher sa config chez l'opérateur et se retrouve 
connecté uniquement avec le ou les sites et services avec lesquels il 
doit être connecté, avec le firewalling éventuel fait directement sur le 
client (tant qu'à faire). Le client final n'a plus qu'à définir une 
policy par groupe de users (et non plus par sites) dans une jolie 
interface et la magie opère... c'est beaucoup plus proche du vrai besoin 
client (les RH avec les RH, etc), il me semble.


Bref, c'est que du bon en fait.


Cordialement,
Philippe Bourcier


On 2017-08-17 23:09, Jérôme Nicolle wrote:

Bonsoir Jérémy,

Un grand merci pour ce thread. C'est l'occasion de remettre 2-3 trucs
d'équerre.

Le 14/08/2017 à 09:48, Jérémy RIZZOLI a écrit :

SD-WAN et toutes les technos

Re: [FRnOG] [TECH] Buzz autour du SD-WAN

2017-08-17 Par sujet Jérôme Nicolle 
Bonsoir Jérémy,

Un grand merci pour ce thread. C'est l'occasion de remettre 2-3 trucs
d'équerre.

Le 14/08/2017 à 09:48, Jérémy RIZZOLI a écrit :
> SD-WAN et toutes les technos afférentes.

#define SD-WAN, pour commencer, maybe ?

Le principe de base dans les bullshito-slidewares qui tournent, c'est
qu'utiliser des liens Internet pour monter des tunnels est moins cher
que d'utiliser des liens "privés" type MPLS-L3VPN.

En clair : parce que les GrozOpérateurs ont réussi à faire croire qu'un
Mbps ne vaut pas le même prix qu'un autre Mbps, on a besoin d'une
surcouche logicielle pour réduire les coûts.

Ces mêmes GroZopérateurs essayent encore de nous faire croire que le
Mbps a la moindre valeur d'ailleurs, et donc que le prix est
proportionnel au débit, ce qui ne correspond plus à aucune réalité
technologique sur les boucles locales en fibre optique.

Ces mêmes GroZopérateurs doivent donc suivre la hype pour garder un peu
plus de valeur ajoutée, et vont parfois aller jusqu'à des mensonges
éhontés pour dire que c'est encore mieux parce qu''il y a "le réseau
privé qui marche toujours" plus "l'internet qu'on maîtrise, parce qu'on
est gros".

Ces mêmes GroZopérateur ayant beaucoup de clients, ils ont été les
premiers à industrialiser (automatiser) tout ou partie de leur réseau
(on le leur souhaite en tout cas, mais ce n'est pas réellement le cas -
où ça a mal vieilli), car la clef du business d'un Network Service
Provider est bien là :

*** l'excellence opérationnelle repose sur un SI en béton qui intègre à
la perfection des process pragmatiques. ***

TL;DR : t'as pas de SI, t'es déjà mort. Et non, Excel n'est pas un IPAM.

> avec un risque non négligeable de voir apparaitre de
> plus en plus un conglomérat à la "Oracle bis" avec Amazon et les GAFA de
> façon générale.

Le trafic L3VPN interne des grosses boites est déjà tenu à 80% par la
somme des "incumbents", pour deux raisons :

- leur taille qui leur permet d'avoir la surface financière pour
encaisser les risques des contrats (Un WAN national d'un gros retailler
c'est en dizaines de M€/an, la PME de 10-100M€ de CA ne peut pas se
placer sur des marchés classiques)

- L'héritage de boucle locales plus capillaires que les concurrents, qui
permettent sur des marchés mal régulés comme en France (il y a pire
ailleurs, mais de nos jours l'ARCEP est un vrai boulet pour l'économie
et l'aménagement du territoire) d'avoir de meilleures marges sur les
couvertures à fournir.

DM-VPN et SD-WAN pourraient en réalité affaiblir sensiblement les vieux
GrozOpérateurs, eussent-ils un intérêt réel.

> N'empile t-on pas les couches de façon grotesque au final, au risque
> d'en perdre totalement la maitrise ? (l'abstraction totale du lien
> physique me choque) Est-ce que ces technos, finalement, ne contribuent
> pas au renforcement de la concentration du traffic chez les GAFA et donc
> au détriment de la neutralité du net ?

On  ne parle pas de neutralité du net ici : ils s'agit de réseaux
privés. SD-WAN n'a rien à foutre d'Internet, il ne peut
qu'éventuellement s'en servir comme support, peu importe qui opère les
concentrateurs éventuels.

Empiler les couches de façon grotesque, on fait ça depuis 20 ans avec
MPLS et ses héritiers.

Non pas que ça n'aie eu aucun sens à l'époque où les routeurs étaient
tous CPU based et qu'on avait besoin d'ASIC simples gravables en 350nm
pour commuter sur les labels plutôt que de faire du LPM.

Maintenant, en dehors des cas de "virtualisation" de réseau (pour
fournir des VPNs donc), ces over/under/whateverlay n'ont qu'un sens
qu'en terme d'efficacité énergétique et économique, fussent-ils
correctement implémentés et orchestrés.

Le reste, c'est juste parce qu'on est qu'une bande de vieux cons qui
tapent encore des commandes à la main sur des routeurs.

***

Pour en revenir à des fondamentaux, j'aurais quelques points à lister :

- Du trafic IP n'a pas un coût de production différent du fait qu'il
soit public ou privé. C'est le taux de mutualisation des ressources
sous-jacentes qui peut éventuellement avoir un impact, mais pas de
l'ordre de grandeur de ce que le marché essaye encore de faire passer.

- Un réseau efficace (i.e. survivable) passé une certaine échelle ne
peut être que complètement automatisé. La règle en vigueur sur mes
nouveaux designs est que si un ingénieur est tenté de shunter le SI pour
taper en CLI directement sur un routeur pour de la production (pas du
débug, et encore), c'est que le design est mauvais ou l'ingé mal formé.

(corollaire : ça exclue de-facto quasiment tous les vendors habituels,
donc c'est moins cher)

- RFC1925 doit être le document fondateur de toute spécification d'un
réseau. Donc une nouvelle couche d'abstraction auto-magique avec un joli
clicodrome ne peut être qu'une mauvaise chose.

Avec tout ça en tête, j'arrive à la conclusion que SD-WAN (dans les
formes que j'ai vues présentées) c'est de la merde en barre fraîchement
déféquée par des parasites marketeux, et qu'on a plus intérêt à remettre
en question

Re: [FRnOG] [TECH] Buzz autour du SD-WAN

2017-08-17 Par sujet Olivier Cochard-Labbé 
2017-08-17 8:51 GMT+02:00 Xavier Beaudouin :

> Ceci dit, attention à l'eugénisme software si on veux pas avoir les mêmes
> emmerdes futures comme le leap seconds qui ont foutu la grouille avec les
> Java et Linux.
>
>
​Ha ben là c'est trop tard :-(
Il suffit de regarder le choix des technos​ utilisés dans les contrôleurs
SDN pour s'apercevoir que ces solutions ont été pensées par le stagiaire
Web 2.0 qui n'avais pas grande notion des technos télécoms/réseau ni de la
sécurité.

Exemple avec Juniper Contrail [1]:
1. Ils ne savaient pas ce qu'était BGP alors ils ont utilisé du XMPP à la
place.
2. Ils ne connaissaient pas les fichiers textes pour stocker la
configuration, alors ils ont déployé du Cassandra, oui le truc pour du big
data pour stocker la configuration de leur solution. Et comme cette base
était aussi utilisée pour collecter l'ensemble des netflows de la
plateforme, ben il suffisait qu'un client sur la plateforme génère un gros
nombre de flux (style un serveur DNS) pour remplir la base et bloquer
l'ensemble. :-)
3. Ils s’obstinent a vouloir que les VMs partagent le même domaine de
broadcast de niveau 2 entre-elles (on devrait leur expliquer que les applis
sont essentiellement en IP), donc ils utilisent des technos d'overlay de
VLAN (VXLAN ou autre). Va falloir leur expliquer que pour le cloisonnement
large-scale, MPLS a fait ses preuves et que la mise au point d'un
MPLS-over-Ethernet (et pas over-GRE ou over-UDP) aurait peut-être était
plus judicieux et surtout plus simple?
Le seul intérêt potentiel que je vois a garantir ce domaine de broadcast de
niveau 2, est pour le VM-motion entre différents DC (garder la même MAC/IP
de la VM). Mais le VM-motion n'est utile que dans un cas très particulier:
Le déplacement d'applications interactives (style serveur TSE ou gateway
VoIP) qui ne permettent pas de simplement démarrer une nouvelle instance et
d'éteindre l'ancienne instance de façon transparente pour l'utilisateur.
C'est quand même très limité comme cas pour toute cette complexité.
4. Pour la gestion des configurations, c'est du NETCONF qui est utilisé… le
truc tellement simple qu'il faut plus de 35 RFC pour l'expliquer. Comment
cela se fait qu'il existe depuis longtemps de nombreuses solutions de
gestion de configuration des serveurs, qui pourtant sont beaucoup plus
compliqués à gérer qu'un routeur/switch, et qu'aucune de ces solutions
n'ait été réutilisée ici ?
5. À la place de netflow ils utilisent du Sandesh, ben oui c'est plus
simple de tout mettre dans du XML;
6. Ils ont découvert l'existence d'IPv6 très très tard;
7. Le tout est validé pour fonctionner sur de l'Ubuntu, car le stagiaire
n'avait que cela sur son poste ?
8. Et ne pas oublier que comme c'est du réseau, c'est à faire
installer/administrer/débugger par vos équipes réseaux… sauf que bien sûr
vous n'avez pas pensé à la leur reconversion professionnelle en devops
(compter 6-mois minimum). ATT semble être l'unique exception sur ce sujet
[2]. Ailleurs (dans les grosses boites de taille identique) je ne suis pas
sur que ce soit le cas.

Donc pourquoi les opérateurs font du SDN ? Car Gartner a dit que c'était
l'avenir, donc il faut rapidement sortir une offre comme les concurrents,
même si on a aucune idée de ce que cela va donner.
Les solutions actuelles sont d'une complexité hallucinante et tombent
miraculeusement en marche. Je ne souhaite pas être dans le coin le jour ou
il faudra déboguer cette usine à gaz: L'empilement énorme des différentes
technologies rend ingérables ces solutions. Il n'y a qu'a regarder la
figure n°1 (page 9) de la doc Juniper qui se permet de résumer OpenStack à
un seul bloc pour avoir un aperçu de l'ensemble. J'aurais bien aimé
calculer le nombre de ligne de code de l'ensemble des éléments d'une
solution complète pour rigoler ainsi que le nombre de technos/langages
différents utilisés.

Au final c'est quand même positif: enfin les équipes réseau vont, forcées,
découvrir l'ensemble des technos matures (et en majorité open source)
utilisées par les équipes devops et du coup cela permettra d'accélérer des
sujets comme l'automatisation des configurations, tests de régression et
intégration continue, d'envisager d'utiliser des solutions à base de x86
pour remplacer des routeurs Cisco/Juniper et de tester des switchs ONIE.

Olivier

[1] http://www.juniper.net/us/en/local/pdf/whitepapers/2000535-en.pdf
[2] https://networkingexchangeblog.att.com/wp-content/uploads/2017/
04/ATT-Tech-Dev-Transformation-Whitepaper-FINAL.pdf

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Buzz autour du SD-WAN

2017-08-17 Par sujet Sébastien Lesimple 
On 17/08/2017 12:08, Guillaume Barrot wrote:
> "Bref. Je pense qu'en tant que mec qui fait du reseau, qu'il faut quand
> même avoir un oeil sur la qualité du software de base qui a l'air de
> s'effriter..."
>
> Pensez juste qu'au départ, les mecs qui faisaient du réseau étaient de pur
> ingé sys.
> Typiquement, il y a longtemps eu une histoire comme quoi Cisco s'était
> monté sur la base du boulot (hardware et software) que faisait Andy
> Bechtolsheim dans le labo d'à coté, avant d'aller monter Sun.
>
> Donc c'est fondamentalement poreux ces deux domaines normalement.
> Après quand on voit comme les purs ingés réseaux sont perdus sur un
> Cumulus, effectivement, en pratique ...
Punaise, si ca bloque sur Cumulus, comment ca doit faire une crise de
nerfs sur un OpenDayLight!?!?

Sérieusement, c'est si complexe que ca de se projetter dans ces solutions?

Proprement formé (aie!) et avec une planification cohérente (re aie!) et
un vrai projet géré intelligeament (aie, aie, aie!), ce sont des
solutions qui me semblent tout à fait cohérentes pour optimiser,
automatiser et mettre de la flexibilité dans les approches réseaux,
quelque soit l'usage que l'on puisse en avoir, FAI, Cloud, Service
provider de tout poil...

Parfois (frequement) je trouve que le plus gros probleme, c'est une
etrange guerre de clochers entre SI et Réseau!
Avec, et là je le constate sans arrets, un obscurantisme coté réseau qui
me semble d'un autre age.
Mais bon, c'est un avis perso.

Seb.
> Le 17 août 2017 à 11:03, Christophe LUCAS  a
> écrit :
>
>> Bonjour,
>>
>>> Le 17 août 2017 à 08:51, Xavier Beaudouin  a écrit :
>>>
>>> Hello,
>>>
>>> Je lurke ce topic et je me fait quelques remarques.
>>>
> 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.
>>> Enfin y a un moment il vas devoir avoir besoin que quelqu'un investisse
>> sur le WAN, ne serait-ce que pour avoir de la BP de dispo... (Après de la
>> QOS sur du VPN over IP, j'veux bien, mais si le tuyau du gars qui as
>> investit est saturé, la QOS OSEF…)
>>
>> Ca n’empêche pas de voir ce qu’on peut faire avec cette technologie. De
>> plus, DMVPN peut être utilisé par des entités sur un WAN dédié (je dis bien
>> dédié), où donc il est possible de faire de la QOS. Cet exemple provient
>> d’expérience pas de l’imaginaire ;-)
>> Néanmoins d’un point de vue plus commun, je suis d’accord que la QOS ne
>> fait pas passer deux paquets où il ne peut en passer qu’un, mais elle
>> prioriser certains types de trafic qui doivent être moins impactés par le
>> tail drop. Mais ce n’est pas de la magie, j’en conviens parfaitement.
>>
>>
>> Christophe
>>
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
>>
>
>


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Buzz autour du SD-WAN

2017-08-17 Par sujet Guillaume Barrot 
"Bref. Je pense qu'en tant que mec qui fait du reseau, qu'il faut quand
même avoir un oeil sur la qualité du software de base qui a l'air de
s'effriter..."

Pensez juste qu'au départ, les mecs qui faisaient du réseau étaient de pur
ingé sys.
Typiquement, il y a longtemps eu une histoire comme quoi Cisco s'était
monté sur la base du boulot (hardware et software) que faisait Andy
Bechtolsheim dans le labo d'à coté, avant d'aller monter Sun.

Donc c'est fondamentalement poreux ces deux domaines normalement.
Après quand on voit comme les purs ingés réseaux sont perdus sur un
Cumulus, effectivement, en pratique ...

Le 17 août 2017 à 11:03, Christophe LUCAS  a
écrit :

> Bonjour,
>
> > Le 17 août 2017 à 08:51, Xavier Beaudouin  a écrit :
> >
> > Hello,
> >
> > Je lurke ce topic et je me fait quelques remarques.
> >
> >>> 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.
> >
> > Enfin y a un moment il vas devoir avoir besoin que quelqu'un investisse
> sur le WAN, ne serait-ce que pour avoir de la BP de dispo... (Après de la
> QOS sur du VPN over IP, j'veux bien, mais si le tuyau du gars qui as
> investit est saturé, la QOS OSEF…)
>
> Ca n’empêche pas de voir ce qu’on peut faire avec cette technologie. De
> plus, DMVPN peut être utilisé par des entités sur un WAN dédié (je dis bien
> dédié), où donc il est possible de faire de la QOS. Cet exemple provient
> d’expérience pas de l’imaginaire ;-)
> Néanmoins d’un point de vue plus commun, je suis d’accord que la QOS ne
> fait pas passer deux paquets où il ne peut en passer qu’un, mais elle
> prioriser certains types de trafic qui doivent être moins impactés par le
> tail drop. Mais ce n’est pas de la magie, j’en conviens parfaitement.
>
>
> Christophe
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>



-- 
Cordialement,

Guillaume BARROT

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Buzz autour du SD-WAN

2017-08-17 Par sujet Christophe LUCAS 
Bonjour,

> Le 17 août 2017 à 08:51, Xavier Beaudouin  a écrit :
> 
> Hello,
> 
> Je lurke ce topic et je me fait quelques remarques.
> 
>>> 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.
> 
> Enfin y a un moment il vas devoir avoir besoin que quelqu'un investisse sur 
> le WAN, ne serait-ce que pour avoir de la BP de dispo... (Après de la QOS sur 
> du VPN over IP, j'veux bien, mais si le tuyau du gars qui as investit est 
> saturé, la QOS OSEF…)

Ca n’empêche pas de voir ce qu’on peut faire avec cette technologie. De plus, 
DMVPN peut être utilisé par des entités sur un WAN dédié (je dis bien dédié), 
où donc il est possible de faire de la QOS. Cet exemple provient d’expérience 
pas de l’imaginaire ;-)
Néanmoins d’un point de vue plus commun, je suis d’accord que la QOS ne fait 
pas passer deux paquets où il ne peut en passer qu’un, mais elle prioriser 
certains types de trafic qui doivent être moins impactés par le tail drop. Mais 
ce n’est pas de la magie, j’en conviens parfaitement.


Christophe

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Buzz autour du SD-WAN

2017-08-17 Par sujet Xavier Beaudouin 
Hello,

Je lurke ce topic et je me fait quelques remarques.

>> 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.

Enfin y a un moment il vas devoir avoir besoin que quelqu'un investisse sur le 
WAN, ne serait-ce que pour avoir de la BP de dispo... (Après de la QOS sur du 
VPN over IP, j'veux bien, mais si le tuyau du gars qui as investit est saturé, 
la QOS OSEF...).

>>> 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 ..

La dessus c'est quasi obligatoire. Et je vois largement le besoin, ceci dit, il 
faut penser que c'est une surcouche d'une autre surcouche (le clowd), donc on 
peux avoir de la QOS mais il reste quand même une incertitude en terme de 
garantie...

Après les SD-XYZ qu'on voit a droite a gauche sont que l'évolution des choses 
basées via DPDK qui permettent enfin d'utiliser le hardware actuel a fond. Ceci 
dit, attention à l'eugénisme software si on veux pas avoir les mêmes emmerdes 
futures comme le leap seconds qui ont foutu la grouille avec les Java et Linux.

D'ailleurs, je suis de plus en plus inquiet du fait que Linux soit omnipresent 
sur tous les équipements réseaux avec les lénarteries et autres délirium des 
distrib linux en mousse dessus comme :
- /dev/md0 sur de l'usb
- un nfsd qui tourne dessus (faites un show process ou equivalent sur du nexus 
7k, ou des brocade/extreme vdx...)
- du kvm sur ios-xe
- des consoles series qui empêchent de rebooter (coucou systemd)...

Bref. Je pense qu'en tant que mec qui fait du reseau, qu'il faut quand même 
avoir un oeil sur la qualité du software de base qui a l'air de s'effriter... 

My 0,02€.

Xavier


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Buzz autour du SD-WAN

2017-08-16 Par sujet Quentin Ritoul 
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  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 
> ---
> 
> 
> 
> 
> 
>> Le 14 août 2017 à 15:07, Jérémy RIZZOLI  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 ?
>> 
>> 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 /

Re: [FRnOG] [TECH] Buzz autour du SD-WAN

2017-08-16 Par sujet Christophe LUCAS 
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 
---





> Le 14 août 2017 à 15:07, Jérémy RIZZOLI  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 ?
> 
> 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

Re: [FRnOG] [TECH] Buzz autour du SD-WAN

2017-08-16 Par sujet Guillaume Barrot 
"ca permet aussi de simplifier les fonctions d'espionnage qu'il soit
prétendu légal ou a des fins publicitaires, en concentrant tous les flux
par le meme endroit"

Donc tu as un réseau sans route reflector, je suppose ?
Tu n'utilises pas non plus de téléphone mobile ?

Il y a une différence majeure entre centraliser le control plane et le
management plane (ce que tout le monde aime faire) et le forwarding plane
(ce que le 3GPP adore) qui peut effectivement concentrer les flux, et donc
poser des problèmes (de latence surtout. D'espionnage, t'as l'air malin
quand tu as concentré au même endroit tout ton flux dont 99% est du SSL).

Le 16 août 2017 à 07:44, Raphael Jacquot  a écrit :

>
>
> Le 14/08/2017 à 11:01, Solarus a écrit :
>
>> 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.
>>
>
> ca permet aussi de simplifier les fonctions d'espionnage qu'il soit
> prétendu légal ou a des fins publicitaires, en concentrant tous les flux
> par le meme endroit
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>



-- 
Cordialement,

Guillaume BARROT

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Buzz autour du SD-WAN

2017-08-15 Par sujet Raphael Jacquot 



Le 14/08/2017 à 11:01, Solarus a écrit :
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.


ca permet aussi de simplifier les fonctions d'espionnage qu'il soit 
prétendu légal ou a des fins publicitaires, en concentrant tous les flux 
par le meme endroit



---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Buzz autour du SD-WAN

2017-08-14 Par sujet Sébastien Lesimple 
On 14/08/2017 19:31, Michel Py wrote:
>> Richard Klein a écrit:
>> 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.
> +1
>
> Michel.
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/

Me 2...


---
Liste de diffusion du FRnOG
http://www.frnog.org/

RE: [FRnOG] [TECH] Buzz autour du SD-WAN

2017-08-14 Par sujet Michel Py 
> Richard Klein a écrit:
> 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.

+1

Michel.

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Buzz autour du SD-WAN

2017-08-14 Par sujet David Ponzone 
C'est quand même un peu bullshit comme article non ? :)
À part caser des mots savants et d'autres à la mode, ça explique quelque chose ?

David Ponzone



> Le 14 août 2017 à 17:29, Richard Klein  a écrit :
> 
> Voir :
> 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"  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  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/

Re: [FRnOG] [TECH] Buzz autour du SD-WAN

2017-08-14 Par sujet Guillaume Barrot 
"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, "

Oui c'est clairement un cas d'usage

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

Absolument pas, tu fais un procès d'intention.
A moins que tu saches terminer un MPLS VPN directement chez Azure ou AWS,
où que tu ais des portes de collecte partout dans le monde, des solutions
tunnelisées sont souvent la seule solution pour d'étendre vite. Quick oui,
Dirty c'est abusif.
Comme la majorité des services providers je suppose que tes routeurs
utilisent ta GRT comme control plane générique et que ton MPLS est monté en
overlay de tes routes publiques. Si tu as un PNI avec Amazon par exemple
quelle différence de qualité entre un IPSEC de chez toi à une IP AWS, une
option 10C en NNI ? De mon point de vue, aucun. Tu peux même tagguer tes
entêtes IPSEC avec une valeur de QOS qui matche un trafic critique, ou
faire de la copie de champs DSCP inner vers outer.

"Dans tous les cas, tout se repose sur Internet, et un ou plusieurs
transits"

Pas plus qu'une porte de collecte xDSL ou tués annonces tes blocs LNS a ton
opérateur tiers. Si tu montes des PNI direct et que tu annonces les blocs
de terminaisons, tu as la même qualité qu'en faisant une interco MPLS
10a/10c avec un opérateur tiers. Je prend l'exemple des LNS a dessein car
L2tp/PPP est un overlay, c'est même le premier et le plus déployé dans le
monde.

Le seul argument valable contre les overlay / tunnels IPSEC c'est le coût
en MTU et l'impact du temps de serialisation sur ta latence. Qui n'est pas
négligeable. Contrainte déjà connue depuis le L2TP / PPP sur le xDSL ...

Le 14 août 2017 3:07 PM, "Jérémy RIZZOLI"  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 ?

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

Re: [FRnOG] [TECH] Buzz autour du SD-WAN

2017-08-14 Par sujet Jérémy RIZZOLI 
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 ?

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
>

Re: [FRnOG] [TECH] Buzz autour du SD-WAN

2017-08-14 Par sujet Guillaume Barrot 
> "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  a écrit :

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

Re: [FRnOG] [TECH] Buzz autour du SD-WAN

2017-08-14 Par sujet Richard Klein 
Voir :
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"  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  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/

Re: [FRnOG] [TECH] Buzz autour du SD-WAN

2017-08-14 Par sujet David Ponzone 
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  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/

Re: [FRnOG] [TECH] Buzz autour du SD-WAN

2017-08-14 Par sujet Solarus 

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/

Re: [FRnOG] [TECH] Buzz autour du SD-WAN

2017-08-14 Par sujet Franck LABBE 
Bonjour Jérémy,

Pour ma part, je trouve que tu viens de lancer un très bon sujet!

Je suis en train d'explorer la piste du SD-WAN aussi, et je pense qu'il
faut la voir de deux angles différentes:
- la première vue d'un ingé réseau : ce n'est ni plus ni moins, qu'une
solution qui fait de l’agrégation de lien multi techno et dont le boitier
va "intelligemment" choisir le meilleur chemin (meilleur latence / débit /
etc) : sortie locale, VPN dynamique multipoint, etc)
- La deuxième vue plus "fonctionnelle" ou il n'y a plus de réseau mais des
applications qui vont / seront accédées avec une abstraction totale de
l'underlay depuis un point A vers un point B (datacenter, cloud, local)

Dans mon cas, nous souhaitons faire dy SD-WAN pour optimiser les coûts des
liaisons WAN de nombreux sites distants et utiliser ces boîtiers pour
agréger différentes sorties internet (2/3?) afin de s'affranchir de
liaisons MPLS coûteuses pour un débit moins bon.

Cependant, nous ne voulons pas de perte de qualité : utiliser internet
localement pour le besoin de débit, mais la meilleure qualité pour les flux
métier / voie / visio.

Pour l'instant, nous ne parlons pas d'applicatifs purs, mais cela va le
devenir avec les différents SaaS, IaaS, etc..

Le choix est compliqué, car les acteurs du SD-WAN utilisent le terme pour
tout et n'importe quoi : routage dynamique, VPN Multipoint dynamique,
Optimisation de flux, caching, sécurité, etc ,etc...

Je suis aussi preneur d'infos et de vos retours d'expériences.
A+


Franck Labbé

Le 14 août 2017 à 09:48, Jérémy RIZZOLI  a écrit :

> Bonjour à tous,
>
> Depuis un petit moment déjà j'essaye de suivre toutes les évolutions
> récentes qui changent un peu de façon radicale la façon de concevoir
> notre taff d'ingé réseau, et notamment les évolutions récentes autour du
> SD-WAN et toutes les technos afférentes.
>
> J'avoue que j'ai un peu de mal à y voir clair dans tout ce Buzz
> marketing autour du SD-WAN et ses technos, qui ne sont pour moi, que des
> technos de réseau overlay à grand renforts de tunnels over Internet dans
> 95% des cas.
>
> Du coup, je m'adresse à la mailing list pour receuillir vos avis,
> subjectifs ou objectifs, et des docs de techos sur le sujet, loin du
> blabla marketing associé.
>
> Ma perception actuelle du SD-WAN c'est que c'est poussé pour favoriser
> des fournisseurs de cloud publics, tels que AWS et leur amis, à
> concentrer la quasi totalité des réseaux d'entreprise (et leur traffic)
> à travers le monde, avec un risque non négligeable de voir apparaitre de
> plus en plus un conglomérat à la "Oracle bis" avec Amazon et les GAFA de
> façon générale.
>
> Pour moi, c'est n'est ni plus, ni moins que l'automatisation de
> tunneling à la volée le tout mis dans un joli Control Plane associé avec
> une belle interface Web qui déchire avec des graphes qui en jette et la
> promesse o combien absurde que tout est "auto-géré" et qu'on pourra
> alors se passer de l'OPEX qui coûte cher ..
>
> Néanmoins, j'ai quand même du mal à voir à qui s'adresse en terme de
> cible, ce type de technos.
>
> En effet, je vois mal comment un opérateur réseau, qui se doit de
> maitriser ses points d'entrée/sortie ainsi que ses tuyaux par définition
> et la Bande passante/latence associée (surtout en 2017) peut vouloir
> jongler avec des technos type SD-WAN, vu que tout ou presque passe alors
> over Internet, sur un réseau dont on ne contrôle donc, ni la latence, ni
> le routage, à contrario de son propre réseau IP/MPLS classique.
> Et pourtant, il semblerait que bon nombre d'opérateurs vont dans cette
> direction de façon [presque] aveugle, alors du coup je me pose aussi la
> question, histoire de pas mourir con:
>
> Comment font-il pour garder cette maitrise des points entrée/sortie et
> du Core quand on fait confiance à 100% à un/des fournisseur(s) tier(s)
> qui imposent leur règles (cf AWS) et à l'Internet (qui lui même repose
> sur des infrastructures plus traditionnelles de façon immuable pour
> certaines parties ..)
>
> N'empile t-on pas les couches de façon grotesque au final, au risque
> d'en perdre totalement la maitrise ? (l'abstraction totale du lien
> physique me choque) Est-ce que ces technos, finalement, ne contribuent
> pas au renforcement de la concentration du traffic chez les GAFA et donc
> au détriment de la neutralité du net ?
>
> Si vous avez des éclairages à m'apporter, je suis preneur, mais j'ai un
> peu peur de lancer le troll 2017 .. essayez de rester un poil objectif :)
>
>
> Jérémy
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/