Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[Gregory CAUCHIE]

Message de Julie : « il semble que je rencontre un petit problème avec ma 
messagerie. Peux-tu prévenir la liste ? »

La bonne nouvelle pour elle c’est qu’après un message encore vide j’ai enfin 
reçu du texte :)

--
Grégory


> Le 15 juin 2021 à 02:44, Michel Py  a 
> écrit :
> 
>> Michel Hostettler a écrit :
>> Le mail est si sécurisé qu'il ne porte aucune information nouvelle.
> 
> C'est comme les SMS : pour éviter que l'information ne fuite, on n'en met pas 
> :P
> 
> J'ai eu la même chose.
> 
> Michel.
> 
> - Mail original -
> De: "Julie" 
> À: "Gregory CAUCHIE" 
> Cc: "Michel Hostettler" , "frnog" 
> 
> Envoyé: Vendredi 11 Juin 2021 17:54:03
> Objet: Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou 
> réalité ?
> 
> Sent with ProtonMail Secure Email.
> 
> ‐‐‐ Original Message ‐‐‐
> 
> On Wednesday, June 9th, 2021 at 10:53 PM, Gregory CAUCHIE 
>  wrote:
> 
>> Bonsoir Michel,
>> 
>> serait-il possible de reformuler la nuance dans le terme « approche » ? 
>> désolé mais je n’ai pas bien saisi.
>> 
>> En tentative de réponse TL/DR, SASE de mon point de vue orthogonal à SD-WAN.
>> 
>> SASE c’est une vision d’architecture orientée sécurité, la « spécificité » 
>> de SASE étant de gérer la politique de sécurité de manière cohérente (i.e. 
>> avec une gestion centralisée et une orchestration) sur tous des différents 
>> points de connectivité WAN, y compris les nomades.
>> 
>> Les conférences de SD-WAN se sont mis à parler de SASE parce qu’à partir du 
>> moment où tu fais du local-breakout sur tes sites distants avec le SD-WAN, 
>> il te faut gérer la sécurité sur ces sites distants, non plus avec un simple 
>> FW pour n’autoriser que ton IPSec, mais comme tu le fais sur ton DC/GW 
>> Internet. À côté de cela, étaient offerts sur le marché les solution 
>> SD-Access/SD-LAN qui, sans parlé de marketing, mettaient en avant les 
>> notions sécurité dite « Zero-Trust » avec une gestion par orchestration dans 
>> les campus. De fil en aiguille, Gartner a créé en 2019 cette notion de SASE 
>> qui « package » tout cela, i.e. les concepts de Zero-Trust, de sorties WAN 
>> sur chaque site et utilisateur en remote (‘distributed doors’), et 
>> d’orchestration.
>> 
>> À lire la définition du Gartner, il y a forcément du SD-WAN dans 
>> l’architecture SASE… qui au final ressemble à un méga silo (pour ne pas dire 
>> vendor-lock) de quasi toutes tes briques de sécurité, voire potentiellement 
>> aussi de routage. Les trafics couverts par l’architecture sont l’Est-Ouest 
>> ainsi que la partie flux sortante vers l’Internet des flux Nord-Sud (i.e. 
>> les WAF, DMZ et autres flux entrants Nord-Sud hors VPN ne sont pas 
>> concernés).
>> 
>> Après, l’histoire se répétant, des offres constructeurs créent des « 
>> sous-types » d'architecture SASE. SASE (prononcé « sassy » pour celles/ceux 
>> qui se demanderaient) signifie ’Secure Access Service Edge’, et comme pour 
>> le SDN par exemple, on peut proposer bon nombre d’architecture rentrant dans 
>> ce terme sans pour autant suivre la vision du Gartner. Bilan de ce qu’on a 
>> pu voir par exemple à la dernier « SASE conference 2021 » de mai, les 
>> vendors se basent au f

RE: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[Michel Py via frnog]

> Michel Hostettler a écrit :
> Le mail est si sécurisé qu'il ne porte aucune information nouvelle.

C'est comme les SMS : pour éviter que l'information ne fuite, on n'en met pas :P

J'ai eu la même chose.

Michel.

- Mail original -
De: "Julie" 
À: "Gregory CAUCHIE" 
Cc: "Michel Hostettler" , "frnog" 

Envoyé: Vendredi 11 Juin 2021 17:54:03
Objet: Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou 
réalité ?

Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐

On Wednesday, June 9th, 2021 at 10:53 PM, Gregory CAUCHIE 
 wrote:

> Bonsoir Michel,
>
> serait-il possible de reformuler la nuance dans le terme « approche » ? 
> désolé mais je n’ai pas bien saisi.
>
> En tentative de réponse TL/DR, SASE de mon point de vue orthogonal à SD-WAN.
>
> SASE c’est une vision d’architecture orientée sécurité, la « spécificité » de 
> SASE étant de gérer la politique de sécurité de manière cohérente (i.e. avec 
> une gestion centralisée et une orchestration) sur tous des différents points 
> de connectivité WAN, y compris les nomades.
>
> Les conférences de SD-WAN se sont mis à parler de SASE parce qu’à partir du 
> moment où tu fais du local-breakout sur tes sites distants avec le SD-WAN, il 
> te faut gérer la sécurité sur ces sites distants, non plus avec un simple FW 
> pour n’autoriser que ton IPSec, mais comme tu le fais sur ton DC/GW Internet. 
> À côté de cela, étaient offerts sur le marché les solution SD-Access/SD-LAN 
> qui, sans parlé de marketing, mettaient en avant les notions sécurité dite « 
> Zero-Trust » avec une gestion par orchestration dans les campus. De fil en 
> aiguille, Gartner a créé en 2019 cette notion de SASE qui « package » tout 
> cela, i.e. les concepts de Zero-Trust, de sorties WAN sur chaque site et 
> utilisateur en remote (‘distributed doors’), et d’orchestration.
>
> À lire la définition du Gartner, il y a forcément du SD-WAN dans 
> l’architecture SASE… qui au final ressemble à un méga silo (pour ne pas dire 
> vendor-lock) de quasi toutes tes briques de sécurité, voire potentiellement 
> aussi de routage. Les trafics couverts par l’architecture sont l’Est-Ouest 
> ainsi que la partie flux sortante vers l’Internet des flux Nord-Sud (i.e. les 
> WAF, DMZ et autres flux entrants Nord-Sud hors VPN ne sont pas concernés).
>
> Après, l’histoire se répétant, des offres constructeurs créent des « 
> sous-types » d'architecture SASE. SASE (prononcé « sassy » pour celles/ceux 
> qui se demanderaient) signifie ’Secure Access Service Edge’, et comme pour le 
> SDN par exemple, on peut proposer bon nombre d’architecture rentrant dans ce 
> terme sans pour autant suivre la vision du Gartner. Bilan de ce qu’on a pu 
> voir par exemple à la dernier « SASE conference 2021 » de mai, les vendors se 
> basent au final sur leurs forces/stratégies pour décliner leurs offres de 
> SASE avec ou non des version Cloud, sur site, incluant tel ou tel lot de 
> fonctions de sécu (CASB, FWaaS, DLP, ZTNA, …) et du SD-

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[Michel Hostettler]

Le mail est si sécurisé qu'il ne porte aucune information nouvelle.
Michel

- Mail original -
De: "Julie" 
À: "Gregory CAUCHIE" 
Cc: "Michel Hostettler" , "frnog" 

Envoyé: Vendredi 11 Juin 2021 17:54:03
Objet: Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou 
réalité ?

Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐

On Wednesday, June 9th, 2021 at 10:53 PM, Gregory CAUCHIE 
 wrote:

> Bonsoir Michel,
>
> serait-il possible de reformuler la nuance dans le terme « approche » ? 
> désolé mais je n’ai pas bien saisi.
>
> En tentative de réponse TL/DR, SASE de mon point de vue orthogonal à SD-WAN.
>
> SASE c’est une vision d’architecture orientée sécurité, la « spécificité » de 
> SASE étant de gérer la politique de sécurité de manière cohérente (i.e. avec 
> une gestion centralisée et une orchestration) sur tous des différents points 
> de connectivité WAN, y compris les nomades.
>
> Les conférences de SD-WAN se sont mis à parler de SASE parce qu’à partir du 
> moment où tu fais du local-breakout sur tes sites distants avec le SD-WAN, il 
> te faut gérer la sécurité sur ces sites distants, non plus avec un simple FW 
> pour n’autoriser que ton IPSec, mais comme tu le fais sur ton DC/GW Internet. 
> À côté de cela, étaient offerts sur le marché les solution SD-Access/SD-LAN 
> qui, sans parlé de marketing, mettaient en avant les notions sécurité dite « 
> Zero-Trust » avec une gestion par orchestration dans les campus. De fil en 
> aiguille, Gartner a créé en 2019 cette notion de SASE qui « package » tout 
> cela, i.e. les concepts de Zero-Trust, de sorties WAN sur chaque site et 
> utilisateur en remote (‘distributed doors’), et d’orchestration.
>
> À lire la définition du Gartner, il y a forcément du SD-WAN dans 
> l’architecture SASE… qui au final ressemble à un méga silo (pour ne pas dire 
> vendor-lock) de quasi toutes tes briques de sécurité, voire potentiellement 
> aussi de routage. Les trafics couverts par l’architecture sont l’Est-Ouest 
> ainsi que la partie flux sortante vers l’Internet des flux Nord-Sud (i.e. les 
> WAF, DMZ et autres flux entrants Nord-Sud hors VPN ne sont pas concernés).
>
> Après, l’histoire se répétant, des offres constructeurs créent des « 
> sous-types » d'architecture SASE. SASE (prononcé « sassy » pour celles/ceux 
> qui se demanderaient) signifie ’Secure Access Service Edge’, et comme pour le 
> SDN par exemple, on peut proposer bon nombre d’architecture rentrant dans ce 
> terme sans pour autant suivre la vision du Gartner. Bilan de ce qu’on a pu 
> voir par exemple à la dernier « SASE conference 2021 » de mai, les vendors se 
> basent au final sur leurs forces/stratégies pour décliner leurs offres de 
> SASE avec ou non des version Cloud, sur site, incluant tel ou tel lot de 
> fonctions de sécu (CASB, FWaaS, DLP, ZTNA, …) et du SD-WAN ou

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[Gregory CAUCHIE]

Bonsoir Michel,

serait-il possible de reformuler la nuance dans le terme « approche » ? désolé 
mais je n’ai pas bien saisi.

En tentative de réponse TL/DR, SASE de mon point de vue orthogonal à SD-WAN. 

SASE c’est une vision d’architecture orientée sécurité, la « spécificité » de 
SASE étant de gérer la politique de sécurité de manière cohérente (i.e. avec 
une gestion centralisée et une orchestration) sur tous des différents points de 
connectivité WAN, y compris les nomades. 
Les conférences de SD-WAN se sont mis à parler de SASE parce qu’à partir du 
moment où tu fais du local-breakout sur tes sites distants avec le SD-WAN, il 
te faut gérer la sécurité sur ces sites distants, non plus avec un simple FW 
pour n’autoriser que ton IPSec, mais comme tu le fais sur ton DC/GW Internet. À 
côté de cela, étaient offerts sur le marché les solution SD-Access/SD-LAN qui, 
sans parlé de marketing, mettaient en avant les notions sécurité dite « 
Zero-Trust » avec une gestion par orchestration dans les campus. De fil en 
aiguille, Gartner a créé en 2019 cette notion de SASE qui « package » tout 
cela, i.e. les  concepts de Zero-Trust, de sorties WAN sur chaque site et 
utilisateur en remote (‘distributed doors’), et d’orchestration.

À lire la définition du Gartner, il y a forcément du SD-WAN dans l’architecture 
SASE… qui au final ressemble à un méga silo (pour ne pas dire vendor-lock) de 
quasi toutes tes briques de sécurité, voire potentiellement aussi de routage. 
Les trafics couverts par l’architecture sont l’Est-Ouest ainsi que la partie 
flux sortante vers l’Internet des flux Nord-Sud (i.e. les WAF, DMZ et autres 
flux entrants Nord-Sud hors VPN ne sont pas concernés).

Après, l’histoire se répétant, des offres constructeurs créent des « sous-types 
» d'architecture SASE. SASE (prononcé « sassy » pour celles/ceux qui se 
demanderaient) signifie ’Secure Access Service Edge’, et comme pour le SDN par 
exemple, on peut proposer bon nombre d’architecture rentrant dans ce terme sans 
pour autant suivre la vision du Gartner. Bilan de ce qu’on a pu voir par 
exemple à la dernier « SASE conference 2021 » de mai, les vendors se basent au 
final sur leurs forces/stratégies pour décliner leurs offres de SASE avec ou 
non des version Cloud, sur site, incluant tel ou tel lot de fonctions de sécu 
(CASB, FWaaS, DLP, ZTNA, …) et du SD-WAN ou pas nécessairement. 

Bref, la « réalité » est en pleine construction, et comme d’hab le marché fera 
juge de paix… la suite donc au prochain épisode :)

--
Grégory

> Le 7 juin 2021 à 15:35, Michel Hostettler 
>  a écrit :
> 
> Bonjour Gregory,
> 
> Faites-vous une différence entre une approche SASE et une approche SD-WAN.
> 
> Je préfère utiliser le terme "approche" comme une façon d'aborder la réalité 
> (les connectivités), plutôt que "technologie".
> 
> Michel
> 
> - Mail original -
> De: "Gregory CAUCHIE" 
> À: "Michel Hostettler" 
> Cc: "Benjamin CALLAR" , "GUILLAUME Cyrille" 
> , "frnog" 
> Envoyé: Lundi 31 Mai 2021 17:12:24
> Objet: Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou 
> réalité ?
> 
>> Le 31 mai 2021 à 16:34, Michel Hostettler 
>>  a écrit :
>> 
>> Bonjour,
>> 
>> Je suis toujours à la recherche de définitions, qu'elles soient techniques, 
>> managériales ou philosophiques.
>> 
>> Pour SD-WAN, je me suis construit cette définition (au sens du QUOI, et non 
>> du COMMENT).
>> 
>> "L’approche SD-WAN permet de gérer en local des connectivités internet 
>> globales, à l’aide de fonctions génériques, banalisées. Un réseau virtuel 
>> est créé, qui masque les détails du réseau physique, plus complexe. 
>> L’approche met à profit une couche logicielle intelligente, permettant à 
>> l’utilisateur de s’abstraire des contraintes matérielles sous-jacentes".
> 
> Je te proposerais :
> « Le SD-WAN est une technologie de gestion de la connectivité Internet et 
> inter-sites d'une entreprise, basée sur un ensemble hétérogène d'offres 
> opérateurs. Cette connectivité dispose a minima d'une classification de flux 
> par application, d’une mesure de performance des liens de connectivité, et 
> d’un routage des flux par application et par niveau de performance des liens 
> » 
> 
>> Une définition n'élime pas les difficultés pour la mettre en œuvre.
> 
> +1
> 
>> 
>> Michel
> 
> --
> Grégory


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

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[Michel Hostettler]

Bonjour Gregory,

Faites-vous une différence entre une approche SASE et une approche SD-WAN.

Je préfère utiliser le terme "approche" comme une façon d'aborder la réalité 
(les connectivités), plutôt que "technologie".

Michel

- Mail original -
De: "Gregory CAUCHIE" 
À: "Michel Hostettler" 
Cc: "Benjamin CALLAR" , "GUILLAUME Cyrille" 
, "frnog" 
Envoyé: Lundi 31 Mai 2021 17:12:24
Objet: Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou 
réalité ?

> Le 31 mai 2021 à 16:34, Michel Hostettler 
>  a écrit :
> 
> Bonjour,
> 
> Je suis toujours à la recherche de définitions, qu'elles soient techniques, 
> managériales ou philosophiques.
> 
> Pour SD-WAN, je me suis construit cette définition (au sens du QUOI, et non 
> du COMMENT).
> 
> "L’approche SD-WAN permet de gérer en local des connectivités internet 
> globales, à l’aide de fonctions génériques, banalisées. Un réseau virtuel est 
> créé, qui masque les détails du réseau physique, plus complexe. L’approche 
> met à profit une couche logicielle intelligente, permettant à l’utilisateur 
> de s’abstraire des contraintes matérielles sous-jacentes".

Je te proposerais :
« Le SD-WAN est une technologie de gestion de la connectivité Internet et 
inter-sites d'une entreprise, basée sur un ensemble hétérogène d'offres 
opérateurs. Cette connectivité dispose a minima d'une classification de flux 
par application, d’une mesure de performance des liens de connectivité, et d’un 
routage des flux par application et par niveau de performance des liens » 

> Une définition n'élime pas les difficultés pour la mettre en œuvre.

+1

> 
> Michel

--
Grégory


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

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[Alain Iltchev]

Bonjour,

Un point intéressant sur cet échange de SDWAN pour BGP  :

> Je change une local-pref sur mon BGP : est-ce du SD-Wan ?

> Si c'est toi qui la change à la main, non.
> Si c'est un soft qui analyse le trafic et qui change en fonction d'un
algorithme, oui.

Entre de mauvaises mains d'utilisateur/intégrateur, on en arrive à cela
parfois :
https://blog.cloudflare.com/how-verizon-and-a-bgp-optimizer-knocked-large-parts-of-the-internet-offline-today/

L'enfer est pavé de bonnes intentions.

Alain



Le lun. 31 mai 2021 à 17:48, Michel Py via frnog  a écrit :

> > Erwan David a écrit :
> > Je change une local-pref sur mon BGP : est-ce du SD-Wan ?
>
> Si c'est toi qui la change à la main, non.
> Si c'est un soft qui analyse le trafic et qui change en fonction d'un
> algorithme, oui.
>
>
> > Gregory CAUCHIE a écrit :
> > Salut Kévin, dans ce cas ce n’est pas le SDN que tu dois balayer, mais
> juste le commercial :).
>
> Plus facile à dire qu'à faire, car ce n'est pas seulement le commercial
> qui est enfermé dans le marketing des vendeurs, les circuits de
> distribution, les territoires géographiques, etc. C'est le système entier
> qui veut ça.
>
>
> > Malheureusement du Business As Usual dans beaucoup (trop) de boîtes, et
> ce pour
> > tout type de trucs à vendre, non ? jje vois en tout cas dans ton
> argument plutôt
> > une problématique entre tech et direction qu’une problématique de
> technologie.
>
> Je serais assez d'accord, mais c'est la calamité de toutes les grosses
> boites et des administrations. En haut, ça change pour des raisons qui
> n'ont rien à voir avec la technologie ou la compétence. Plus le temps
> passe, plus on fait du jetable qui change à chaque fois que ça valse plus
> haut. Bon pour ça j'ai pas de solution :-(
>
> Le bullshit ça existe depuis toujours, sauf que maintenant on l'encapsule
> dans un tunnel géré par une autre couche d'un bullshit différent, çà
> commence à devenir gonflant.
>
> Michel.
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

RE: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[Michel Py via frnog]

> Erwan David a écrit :
> Je change une local-pref sur mon BGP : est-ce du SD-Wan ?

Si c'est toi qui la change à la main, non.
Si c'est un soft qui analyse le trafic et qui change en fonction d'un 
algorithme, oui.


> Gregory CAUCHIE a écrit :
> Salut Kévin, dans ce cas ce n’est pas le SDN que tu dois balayer, mais juste 
> le commercial :).

Plus facile à dire qu'à faire, car ce n'est pas seulement le commercial qui est 
enfermé dans le marketing des vendeurs, les circuits de distribution, les 
territoires géographiques, etc. C'est le système entier qui veut ça.


> Malheureusement du Business As Usual dans beaucoup (trop) de boîtes, et ce 
> pour
> tout type de trucs à vendre, non ? jje vois en tout cas dans ton argument 
> plutôt
> une problématique entre tech et direction qu’une problématique de technologie.

Je serais assez d'accord, mais c'est la calamité de toutes les grosses boites 
et des administrations. En haut, ça change pour des raisons qui n'ont rien à 
voir avec la technologie ou la compétence. Plus le temps passe, plus on fait du 
jetable qui change à chaque fois que ça valse plus haut. Bon pour ça j'ai pas 
de solution :-(

Le bullshit ça existe depuis toujours, sauf que maintenant on l'encapsule dans 
un tunnel géré par une autre couche d'un bullshit différent, çà commence à 
devenir gonflant.

Michel.


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

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[Michel Hostettler]

Difficile de caser le terme "agnostique" dans une définition, car il faudrait, 
à son tour, le définir.

Il me semble que Grégory parvient à exprimer cette idée.
Michel

- Mail original -
De: "David Ponzone" 
À: "Gregory CAUCHIE" 
Cc: "Michel Hostettler" , "Benjamin CALLAR" 
, "GUILLAUME Cyrille" , 
"frnog" 
Envoyé: Lundi 31 Mai 2021 17:16:10
Objet: Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou 
réalité ?

Je rejoins Michel H., il faut qu’il y ait le mot « abstraction » dans la 
définition.
Et faudrait caser « agnostique » aussi, ça fait classe.

> Le 31 mai 2021 à 17:12, Gregory CAUCHIE  a écrit :
> 
> 
>> Le 31 mai 2021 à 16:34, Michel Hostettler 
>>  a écrit :
>> 
>> Bonjour,
>> 
>> Je suis toujours à la recherche de définitions, qu'elles soient techniques, 
>> managériales ou philosophiques.
>> 
>> Pour SD-WAN, je me suis construit cette définition (au sens du QUOI, et non 
>> du COMMENT).
>> 
>> "L’approche SD-WAN permet de gérer en local des connectivités internet 
>> globales, à l’aide de fonctions génériques, banalisées. Un réseau virtuel 
>> est créé, qui masque les détails du réseau physique, plus complexe. 
>> L’approche met à profit une couche logicielle intelligente, permettant à 
>> l’utilisateur de s’abstraire des contraintes matérielles sous-jacentes".
> 
> Je te proposerais :
> « Le SD-WAN est une technologie de gestion de la connectivité Internet et 
> inter-sites d'une entreprise, basée sur un ensemble hétérogène d'offres 
> opérateurs. Cette connectivité dispose a minima d'une classification de flux 
> par application, d’une mesure de performance des liens de connectivité, et 
> d’un routage des flux par application et par niveau de performance des liens 
> » 
>


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

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[Michel Hostettler]

Merci Grégory, je ferai une combinaison des 2 déclarations, sans complexifier 
le résultat de l'opération, et sans créer de redondances. Pas facile de 
synthétiser en quelques mots, sans emberlificoter.
Michel

- Mail original -
De: "Gregory CAUCHIE" 
À: "Michel Hostettler" 
Cc: "Benjamin CALLAR" , "GUILLAUME Cyrille" 
, "frnog" 
Envoyé: Lundi 31 Mai 2021 17:12:24
Objet: Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou 
réalité ?

> Le 31 mai 2021 à 16:34, Michel Hostettler 
>  a écrit :
> 
> Bonjour,
> 
> Je suis toujours à la recherche de définitions, qu'elles soient techniques, 
> managériales ou philosophiques.
> 
> Pour SD-WAN, je me suis construit cette définition (au sens du QUOI, et non 
> du COMMENT).
> 
> "L’approche SD-WAN permet de gérer en local des connectivités internet 
> globales, à l’aide de fonctions génériques, banalisées. Un réseau virtuel est 
> créé, qui masque les détails du réseau physique, plus complexe. L’approche 
> met à profit une couche logicielle intelligente, permettant à l’utilisateur 
> de s’abstraire des contraintes matérielles sous-jacentes".

Je te proposerais :
« Le SD-WAN est une technologie de gestion de la connectivité Internet et 
inter-sites d'une entreprise, basée sur un ensemble hétérogène d'offres 
opérateurs. Cette connectivité dispose a minima d'une classification de flux 
par application, d’une mesure de performance des liens de connectivité, et d’un 
routage des flux par application et par niveau de performance des liens » 

> Une définition n'élime pas les difficultés pour la mettre en œuvre.

+1

> 
> Michel

--
Grégory


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

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[Gregory CAUCHIE]

> Le 31 mai 2021 à 16:57, Erwan David  a écrit :
> 
> Le 31/05/2021 à 16:34, Michel Hostettler a écrit :
>> Bonjour,
>> Je suis toujours à la recherche de définitions, qu'elles soient techniques, 
>> managériales ou philosophiques.
>> Pour SD-WAN, je me suis construit cette définition (au sens du QUOI, et non 
>> du COMMENT).
>> "L’approche SD-WAN permet de gérer en local des connectivités internet 
>> globales, à l’aide de fonctions génériques, banalisées. Un réseau virtuel 
>> est créé, qui masque les détails du réseau physique, plus complexe. 
>> L’approche met à profit une couche logicielle intelligente, permettant à 
>> l’utilisateur de s’abstraire des contraintes matérielles sous-jacentes".
>> Une définition n'élime pas les difficultés pour la mettre en œuvre.
>> Michel
> 
> Je change une local-pref sur mon BGP : est-ce du SD-Wan ?

tout dépend de comment tu l’as changé.

option a : Tu te connectes en CLI, passe en mode config puis tu commit —> c’est 
pas du SDN

option b : t’as changé un truc dans un fichier ou une base de donnée, ça passe 
par l’usine logicielle de CI/CD puis si tout est ok ça part en prod —> c’est du 
SDN sauce CI/CD

option c : t’es passé par un truc genre playbook Ansible pour redéployer ta 
config —> moi je dirais que c’est le début du SDN, mais c’est perso, pas sûr 
qu’il y ait une démarcation claire là-dessus

—
Grégory


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

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[David Ponzone]

Je rejoins Michel H., il faut qu’il y ait le mot « abstraction » dans la 
définition.
Et faudrait caser « agnostique » aussi, ça fait classe.

> Le 31 mai 2021 à 17:12, Gregory CAUCHIE  a écrit :
> 
> 
>> Le 31 mai 2021 à 16:34, Michel Hostettler 
>>  a écrit :
>> 
>> Bonjour,
>> 
>> Je suis toujours à la recherche de définitions, qu'elles soient techniques, 
>> managériales ou philosophiques.
>> 
>> Pour SD-WAN, je me suis construit cette définition (au sens du QUOI, et non 
>> du COMMENT).
>> 
>> "L’approche SD-WAN permet de gérer en local des connectivités internet 
>> globales, à l’aide de fonctions génériques, banalisées. Un réseau virtuel 
>> est créé, qui masque les détails du réseau physique, plus complexe. 
>> L’approche met à profit une couche logicielle intelligente, permettant à 
>> l’utilisateur de s’abstraire des contraintes matérielles sous-jacentes".
> 
> Je te proposerais :
> « Le SD-WAN est une technologie de gestion de la connectivité Internet et 
> inter-sites d'une entreprise, basée sur un ensemble hétérogène d'offres 
> opérateurs. Cette connectivité dispose a minima d'une classification de flux 
> par application, d’une mesure de performance des liens de connectivité, et 
> d’un routage des flux par application et par niveau de performance des liens 
> » 
> 


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

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[Gregory CAUCHIE]

> Le 31 mai 2021 à 16:34, Michel Hostettler 
>  a écrit :
> 
> Bonjour,
> 
> Je suis toujours à la recherche de définitions, qu'elles soient techniques, 
> managériales ou philosophiques.
> 
> Pour SD-WAN, je me suis construit cette définition (au sens du QUOI, et non 
> du COMMENT).
> 
> "L’approche SD-WAN permet de gérer en local des connectivités internet 
> globales, à l’aide de fonctions génériques, banalisées. Un réseau virtuel est 
> créé, qui masque les détails du réseau physique, plus complexe. L’approche 
> met à profit une couche logicielle intelligente, permettant à l’utilisateur 
> de s’abstraire des contraintes matérielles sous-jacentes".

Je te proposerais :
« Le SD-WAN est une technologie de gestion de la connectivité Internet et 
inter-sites d'une entreprise, basée sur un ensemble hétérogène d'offres 
opérateurs. Cette connectivité dispose a minima d'une classification de flux 
par application, d’une mesure de performance des liens de connectivité, et d’un 
routage des flux par application et par niveau de performance des liens » 

> Une définition n'élime pas les difficultés pour la mettre en œuvre.

+1

> 
> Michel

--
Grégory

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

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[Erwan David]

Le 31/05/2021 à 16:34, Michel Hostettler a écrit :

Bonjour,

Je suis toujours à la recherche de définitions, qu'elles soient techniques, 
managériales ou philosophiques.

Pour SD-WAN, je me suis construit cette définition (au sens du QUOI, et non du 
COMMENT).

"L’approche SD-WAN permet de gérer en local des connectivités internet globales, à 
l’aide de fonctions génériques, banalisées. Un réseau virtuel est créé, qui masque les 
détails du réseau physique, plus complexe. L’approche met à profit une couche logicielle 
intelligente, permettant à l’utilisateur de s’abstraire des contraintes matérielles 
sous-jacentes".

Une définition n'élime pas les difficultés pour la mettre en œuvre.

Michel


Je change une local-pref sur mon BGP : est-ce du SD-Wan ?
Après tout j'ai changé une configuration pour qu'un algorithme décide de 
faire sortir un paquet plutôt sur une connexion WAN que sur une autre...


--
Erwan


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

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[Gregory CAUCHIE]

Bonjour,

> Le 28 mai 2021 à 17:15, Kévin CHAILLY  a écrit :
> 
> Alors sans doute, il y a le bon et le mauvais SDN, mais j'aimerais bien qu'on 
> arrête de me vendre un concept magique et qu'on explique quelles solutions 
> apporte à quel problème un produit donné, et qu'on arrête les management 
> centralisés obligatoires et autre abonnement 
> si-tu-le-prends-pas-je-route-plus-tes-paquets, je veux avoir le choix 
> d'arrêter de payer le vendeur si le service n'est pas rendu, car j'ai déja 
> payé le produit.


Salut Kévin, dans ce cas ce n’est pas le SDN que tu dois balayer, mais juste le 
commercial :). SDN n’implique pas de routage centralisé, quant au management 
centralisé faut rentrer plus dans le détail de ce qui changerait je pense car 
je trouve que le management des réseaux à toujours été en quelque-sorte 
centralisé dans la zone Syslog/SNMP/Bastion.

> Au final, certaines solutions pourtant pertinentes technologiquement se font 
> éconduire a la porte car apportant plus de restrictions que d'avancées. 
> Ouaip, c'est bien de faire du CI/CD et de lâcher la CLI, mais l'obliger, je 
> veux que ce soit ma décision et pas celle du vendeur alors que rien ne le 
> justifie technologiquement. 

Bah là pour le coup je veux bien une explication car je ne vois pas comment 
l’un peut fonctionner sans l’autre. Du moins, je ne vois pas comment tu peux 
faire de « Continuous Deployment » dans ce cas.
Si tu utilises CI/CD jusqu’au Continuous Delivery, effectivement tu n’est pas 
obligé de changer tes habitudes de prod en CLI. Mais pour le coup tu n’as rien 
gagné, et je dirais même que tu as surtout perdu ton temps, car ta phase 
d’ingénierie restera complètement décorrélée de la vie de ta prod… c’est 
d’ailleurs le cas de figure qui historiquement a fait émerger la culture 
DevOps, vu que les XP/Agile/etc sortaient très vite des trucs tout beau tout 
chaud mais qui ne pouvaient jamais aller en prod. Donc pour réussir in fine à 
faire du CI/CD jusqu’à la prod, faut respecter le concept de ‘cattle’ qui dit 
en gros qu’on ne touche à la config des équipements en CLI qu’en phase de 
développement (i.e. avant les tests).

> Moi, j'aime bien openvSwitch, en plus y'a pas SDN dans le titre, ni dans la 
> description, c'est open, c'est virtual, c'est un switch. même le titre 
> apporte une réponse a une problématique donnée, 

c’est marrant comme exemple car openvSwitch a une API pour faire du SDN, et 
notamment faire de l’openFlow avec OVSDB qui est donc du tout centralisé… mais 
on peut aussi y faire du SDN autrement (i.e. non centralisé), voire ne pas en 
faire du tout, comme quoi ce sujet de SDN n’est pas si « noir et blanc » que ça.



> Le 28 mai 2021 à 18:28, Michel Py  a 
> écrit :
> 
> C'est une bière très chère, mais quand tu veux !

Salut Michel, noté :)

> Fast-forward 3 mois plus tard, le vendeur de pompes usées évidemment ce n'est 
> plus son problème dès que la commande est passée, et qui c'est qui se 
> retrouve baisé à essayer de faire marcher la bouse très chère qui non 
> seulement ne sert à rien mais en plus double la complexité de l'usine à gaz ? 
> ben c'est David et Michel, entre autres.

Malheureusement du Business As Usual dans beaucoup (trop) de boîtes, et ce pour 
tout type de trucs à vendre, non ? je vois en tout cas dans ton argument plutôt 
une problématique entre tech et direction qu’une problématique de technologie.
Et en témoignage, je peux dire ne pas avoir vu de « double » complexité. Mais 
il y a bien une complexité à gérer, à savoir celle de pouvoir maîtriser 
l’ensemble des éléments de routage et de sécurité, voire également de 
virtualisation. Bref ce qu’on avait avant en plusieurs boîtes, voire réparti 
sur deux équipes, on l’a ici nécessaire chez une seule personne. Donc un sujet 
de compétence et donc de formation.



> Le 31 mai 2021 à 14:54, Benjamin CALLAR  a écrit :
> 
> Je suis d'ailleurs curieux (sans trahir de secret), de savoir quelles 
> solutions techniques sont mises en place ? Ça semble joli à voir :)
> 
> Je suis malheureusement forcé de constater que grand nombres de solutions 
> "SD-WAN" ne permettent uniquement que de faire du Policy-Based Routing 
> statique et manuel au dessus d'un VPN IPSec (parfois même, ce n'est pas 
> compris) ... mais le terme SD-WAN se vends plus cher ;)

Cyrille infirmera peut être mes propos, mais cela semble être en grande partie 
du « standard SD-WAN » avec du DPI pour la catégorisation du trafic, un 
mécanisme de mesure de SLA des tunnels (type BFD ad-hoc ou mesure OAM des 
paquets data), et une configuration par l'administrateur de « poids métier » + 
seuil de reroutage par application.
Là où il semble y avoir une fonction que tous n’ont pas, c’est la possibilité 
de rerouter via un site de transit (i.e. pas un autre provider pour aller de A 
à B mais de faire A-C-B, où C est un site SD-WAN).

--
Grégory

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

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[Michel Hostettler]

Bonjour,

Je suis toujours à la recherche de définitions, qu'elles soient techniques, 
managériales ou philosophiques.

Pour SD-WAN, je me suis construit cette définition (au sens du QUOI, et non du 
COMMENT).

"L’approche SD-WAN permet de gérer en local des connectivités internet 
globales, à l’aide de fonctions génériques, banalisées. Un réseau virtuel est 
créé, qui masque les détails du réseau physique, plus complexe. L’approche met 
à profit une couche logicielle intelligente, permettant à l’utilisateur de 
s’abstraire des contraintes matérielles sous-jacentes".

Une définition n'élime pas les difficultés pour la mettre en œuvre.

Michel


- Mail original -
De: "Benjamin CALLAR" 
À: "GUILLAUME Cyrille" , "frnog" 
Envoyé: Lundi 31 Mai 2021 14:54:06
Objet: Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou 
réalité ?

Bonjour Cyrille,

Je suis entièrement d'accord, et la solution que tu nous donnes est pour 
moi la définition la plus correcte de ce que serait le SD-WAN (vision 
globale, actions locales).

Je suis d'ailleurs curieux (sans trahir de secret), de savoir quelles 
solutions techniques sont mises en place ? Ça semble joli à voir :)

Je suis malheureusement forcé de constater que grand nombres de 
solutions "SD-WAN" ne permettent uniquement que de faire du Policy-Based 
Routing statique et manuel au dessus d'un VPN IPSec (parfois même, ce 
n'est pas compris) ... mais le terme SD-WAN se vends plus cher ;)

Merci de nous redonner la foi que du "vrai" SD-WAN semble exister :)

Bonne journée

Benjamin


Le 31/05/2021 à 12:58, GUILLAUME Cyrille a écrit :
> Pour travailler sur des technos dites SD-WAN, je nuancerais un petit peu.
> Si chez certains constructeurs c'est vraiment du pur marketing, il y a des 
> solutions qui permettent réellement d'avoir un WAN "intelligent"
> J'entends pas la des décisions de routage qui sont bien plus poussées que ce 
> que l'on fait traditionnellement.
>
> Chez nous on l'utilise pour interconnecter nos différentes plaques pays. Et 
> il nous offre la capacité de rerouter à la volée du traffic sur différents 
> lien en fonction des qualités mesurées, mais aussi de forcer des routages 
> inter pays via un troisieme pays. Exemple:
> En nominal les communications entre l'Inde et le Kazakhstan se font en 
> direct, il y a 2 opérateurs de chaque coté, ca vit sa vie. Si les mesures de 
> SLA se dégradent trop, il est tout a fait possible dans notre architecture de 
> forcer un rebond par notre site de Geneve parce que les liaisons KZ-CH et 
> IN-CH sont ok alors que le KZ-IN est de mauvaise qualité.
> Au final on a une solution tres resiliente qui tourne sur internet et qui 
> coute bien moins cher que ce que l'on aurait eu en passant par un opérateur.
> C'est surtout rendu possible par la présence d'un controleur central qui 
> modifie à la volée les poids des routes pour forcer les flux dans les bons 
> tunnels.
>
> Cyrille GUILLAUME
>


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


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

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[Benjamin CALLAR]

Bonjour Cyrille,

Je suis entièrement d'accord, et la solution que tu nous donnes est pour 
moi la définition la plus correcte de ce que serait le SD-WAN (vision 
globale, actions locales).


Je suis d'ailleurs curieux (sans trahir de secret), de savoir quelles 
solutions techniques sont mises en place ? Ça semble joli à voir :)


Je suis malheureusement forcé de constater que grand nombres de 
solutions "SD-WAN" ne permettent uniquement que de faire du Policy-Based 
Routing statique et manuel au dessus d'un VPN IPSec (parfois même, ce 
n'est pas compris) ... mais le terme SD-WAN se vends plus cher ;)


Merci de nous redonner la foi que du "vrai" SD-WAN semble exister :)

Bonne journée

Benjamin


Le 31/05/2021 à 12:58, GUILLAUME Cyrille a écrit :

Pour travailler sur des technos dites SD-WAN, je nuancerais un petit peu.
Si chez certains constructeurs c'est vraiment du pur marketing, il y a des solutions qui 
permettent réellement d'avoir un WAN "intelligent"
J'entends pas la des décisions de routage qui sont bien plus poussées que ce 
que l'on fait traditionnellement.

Chez nous on l'utilise pour interconnecter nos différentes plaques pays. Et il 
nous offre la capacité de rerouter à la volée du traffic sur différents lien en 
fonction des qualités mesurées, mais aussi de forcer des routages inter pays 
via un troisieme pays. Exemple:
En nominal les communications entre l'Inde et le Kazakhstan se font en direct, 
il y a 2 opérateurs de chaque coté, ca vit sa vie. Si les mesures de SLA se 
dégradent trop, il est tout a fait possible dans notre architecture de forcer 
un rebond par notre site de Geneve parce que les liaisons KZ-CH et IN-CH sont 
ok alors que le KZ-IN est de mauvaise qualité.
Au final on a une solution tres resiliente qui tourne sur internet et qui coute 
bien moins cher que ce que l'on aurait eu en passant par un opérateur.
C'est surtout rendu possible par la présence d'un controleur central qui 
modifie à la volée les poids des routes pour forcer les flux dans les bons 
tunnels.

Cyrille GUILLAUME




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

RE: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[GUILLAUME Cyrille]

Pour travailler sur des technos dites SD-WAN, je nuancerais un petit peu.
Si chez certains constructeurs c'est vraiment du pur marketing, il y a des 
solutions qui permettent réellement d'avoir un WAN "intelligent"
J'entends pas la des décisions de routage qui sont bien plus poussées que ce 
que l'on fait traditionnellement.

Chez nous on l'utilise pour interconnecter nos différentes plaques pays. Et il 
nous offre la capacité de rerouter à la volée du traffic sur différents lien en 
fonction des qualités mesurées, mais aussi de forcer des routages inter pays 
via un troisieme pays. Exemple:
En nominal les communications entre l'Inde et le Kazakhstan se font en direct, 
il y a 2 opérateurs de chaque coté, ca vit sa vie. Si les mesures de SLA se 
dégradent trop, il est tout a fait possible dans notre architecture de forcer 
un rebond par notre site de Geneve parce que les liaisons KZ-CH et IN-CH sont 
ok alors que le KZ-IN est de mauvaise qualité.
Au final on a une solution tres resiliente qui tourne sur internet et qui coute 
bien moins cher que ce que l'on aurait eu en passant par un opérateur.
C'est surtout rendu possible par la présence d'un controleur central qui 
modifie à la volée les poids des routes pour forcer les flux dans les bons 
tunnels.

Cyrille GUILLAUME

-Message d'origine-
De : frnog-requ...@frnog.org  De la part de Benjamin 
CALLAR
Envoyé : vendredi 21 mai 2021 12:42
À : frnog@frnog.org
Objet : Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou 
réalité ?

Hello la liste !

Bravo Cécile pour le débat, quel engouement

Pour moi le SDN, c'est une vraie évolution, mais qui malheureusement a été 
complètement pompée par le marketing et qui en a fait n'importe quoi. J'aime le 
comparer à d'autres tendances - et que j'ai eu l'occasion de voir plus tôt dans 
le thread - que sont le "Cloud" alors que c'est juste de la VM (ça doit mieux 
se vendre les termes anglais XD) ou encore le "AI" alors qu'il s'agit juste de 
statistiques sans aucun apprentissage (mais encore une fois, ça se vend 
vachement bien une solution qui fait de "l'intelligence artificielle" (=> un 
calcul de moyenne ? ) !).

Autant je suis 1000% pour l'esprit startup, mais il y a des niches qui ont été 
exploitées à en perdre leur sens .. Le SDN, SD-WAN, AI, Cloud, Cybersécurité en 
font partie...

Et je ne parle pas des écoles qui ont encore plus exploité la chose en vendant 
des formations "Ingénieur Cloud", "Ingénieur cybersécurité, "Ingénieur AI" ... 
alors que le programme corresponds à un titre d'ingénieur Systèmes et réseaux 
ou développeur d'il y a quelques années ...
Je ne mets pas tous les oeufs dans le même panier, il y a des écoles qui 
respectent leurs engagements, mais pour la majorité que j'ai eu l'occasion de 
voir ce n'est pas le cas ...

Malheureusement, cela donne une vision erronée du monde du travail aux jeunes 
qui souhaiteraient rejoindre le milieu.

Pour argumenter le débat, le SDN a tout a fait sa place dans un environnement 
complexe style Datacenter, et comme j'ai pu le voir plus tôt aussi, en séparant 
le controlplane du dataplane.
Imaginez un monde ou le broadcast ARP disparait, ce serait top non ? (ne me 
parlez pas d'IPv6 ...) Clairement, le SDN peut répondre à cela, le contrôleur 
ayant une connaissance globale du réseau, la requête peut être répondu 
localement par le premier saut sans avoir à traverser le réseau  !

Idem sur la gestion des tables CAM, où celle-ci peuvent être gérer de manière 
centralisée, et éviter l'auto-apprentissage de celles-ci, et pourquoi pas faire 
du switching intelligent (load balancing, ...) comme le permet à peu prêt le 
PBR que nous connaissons tous, mais au niveau 2.=> Adieu le spanning-tree

Et il y encore pleins d'autres exemple, les protocoles de NHRP, de LAGP, de 
PBR, peuvent tous être "SDN-isé" pour y ajouter les besoins liés à des 
contextes complexes, et surtout des règles spécifiques à l'entreprise.

Le problème des protocoles que je viens de citer, c'est qu'il faut que ça 
évolue et que ça arrive dans le firmware (qu'il faut mettre à jour), avec le 
SDN, chacun peut y mettre du sien, le contrôleur n'étant qu'un "programme" qui 
peut être mis à jour bien plus souvent qu'un firmware. 
(imaginez la puissance d'un contrôleur opensource combiné avec un bon
ingénieur)

C'est à ça que j'identifie le SDN, une entité qui a la connaissance globale du 
réseau et qui peut intervenir instantanément sur les flux en fonction 
d'évènements, besoins, etc.

J'ai eu la chance il y a quelques années de suivre une formation Coursera à ce 
sujet, qui est justement dans cette définition du SDN : 
https://www.coursera.org/learn/sdn?#about

En ce qui concerne le SD-WAN, simple Bullshit ... faire du routage intelligent, 
ce n'est pas nouveau, et ça ne se vends pas aussi cher ! Et quand je vois à 
quel point les solutions vendues sont fermées, bridée, ... ça me dé

RE: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[Michel Py via frnog]

> Gregory CAUCHIE a écrit :
> La première chose nest pas d’être contre David ni Michel, je ne les connais 
> pas d'ailleurs
> et ces échanges me font dire que je prendrais bien une bière avec eux, dès 
> qu’on pourra,

C'est une bière très chère, mais quand tu veux !

> Pour ma part en tout cas, je n’ai jamais vu d’offre d’IA capable de générer 
> toute seule une
> configuration réseau capable de répondre à la demande du DSI, métier, ou 
> autre réseau-phobe…

Le problème, c'est que la machine entière vente/marketing de Junisco et autres 
raconte exactement le contraire aux décideurs, plus ils sont incompétents plus 
on leur raconte de conneries; plus c'est gros, plus c'est vague, plus le 
bullshit est facile à vendre. Une bonne petite démo, le clickodrome qui fait 
tout en automagique et qui va résoudre un problème qui vient d'être inventé, et 
voilà. Fast-forward 3 mois plus tard, le vendeur de pompes usées évidemment ce 
n'est plus son problème dès que la commande est passée, et qui c'est qui se 
retrouve baisé à essayer de faire marcher la bouse très chère qui non seulement 
ne sert à rien mais en plus double la complexité de l'usine à gaz ? ben c'est 
David et Michel, entre autres.

Je n'ai rien (au contraire) contre la plupart des technologies SDN, ce qui me 
les gonfle c'est l'exploitation qui en est faite.

> Est-ce au final une « peur » de ne plus avoir d’accès CLI ?

Le problème c'est que les clickodromes produisent en général une config 
complètement illisible, et que le GUI est toujours en retard sur la 
fonctionnalité (merci Forti, par exemple), donc qu'il faut encore et toujours 
se taper du CLI, mais en plus maintenant c'est noyé dans une pile de bouse de 
dinosaure haute de 2 mètres.


> Kévin CHAILLY a écrit :
> Attention, entre David et Michel, un océan les sépare.

:-)

> mais j'aimerais bien qu'on arrête de me vendre un concept magique et qu'on 
> explique quelles
> solutions apporte à quel problème un produit donné, et qu'on arrête les 
> management centralisés
> obligatoires et autre abonnement 
> si-tu-le-prends-pas-je-route-plus-tes-paquets, je veux avoir le
> choix d'arrêter de payer le vendeur si le service n'est pas rendu, car j'ai 
> déjà payé le produit.

+1

Michel.


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

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[Kévin CHAILLY]

Bonjour Gregory,

Merci de contribuer a ce fil un vendredi, cette année a cruellement manqué
de vendredis.

Attention, entre David et Michel, un océan les sépare.

Oui, les jolies interfaces ( enfin, les moches ) ne datent pas d'hier,
c'est sûr. Et elles sont sans doute plus jolies et plus performantes
aujourd'hui, mais nous ne sommes pas là pour dénoncer le non-respect de la
console en 80 colonnes, on est intégristes, mais pas trop.

Le SDN, enfin, plutôt son époque emmène avec elle un changement radical de
philosophie, sous le couvert de produits mieux finis et plus léchés, nous
sommes attirés vers le vendor lock-in, comme hier, mais en plus, nous
n'achetons plus de produits aujourd'hui, mais des boites-a-a-service.

Alors sans doute, il y a le bon et le mauvais SDN, mais j'aimerais bien
qu'on arrête de me vendre un concept magique et qu'on explique quelles
solutions apporte à quel problème un produit donné, et qu'on arrête les
management centralisés obligatoires et autre abonnement
si-tu-le-prends-pas-je-route-plus-tes-paquets, je veux avoir le choix
d'arrêter de payer le vendeur si le service n'est pas rendu, car j'ai déja
payé le produit.

Au final, certaines solutions pourtant pertinentes technologiquement se
font éconduire a la porte car apportant plus de restrictions que
d'avancées. Ouaip, c'est bien de faire du CI/CD et de lâcher la CLI, mais
l'obliger, je veux que ce soit ma décision et pas celle du vendeur alors
que rien ne le justifie technologiquement.

Moi, j'aime bien openvSwitch, en plus y'a pas SDN dans le titre, ni dans la
description,

c'est open, c'est virtual, c'est un switch. même le titre apporte une
réponse a une problématique donnée,

Soyons polis, arrêtons les gros mots, et ne parlons plus de ces Satanés
Devices Novateurs.

Kévin

Le ven. 28 mai 2021 à 16:17, Gregory CAUCHIE  a
écrit :

> Bonjour,
>
> au risque d’être vu pour ce que je ne suis pas, je reprend ci-dessous un
> extrait d’une autre discussion FRnOG de ce jour en lien avec l’objet de
> cette discussion.
>
> > Le 28 mai 2021 à 08:59, David Ponzone  a écrit
> :
> >
> >
> >> Le 28 mai 2021 à 08:23, Michel Py 
> a écrit :
> >>
> >>
> >> Yàkà acheter la solution SD-WAN et laisser le clickodrome automagique
> tout faire :P C'est démodé, ton modèle : laisser l'ingénieur réseau faire
> de la configuration ? pfff.
> >>
> >
> > Ouais et avec un peu de chance, ça fait comme Kosc: ça pousse une
> mauvaise conf sur tout le backbone et tu dois envoyer des techs dans la
> nuit pour restaurer :)
>
>
>
> Il y a deux choses qui me donnent envie de réagir à cet extrait.
>
> La première chose nest pas d’être contre David ni Michel, je ne les
> connais pas d'ailleurs et ces échanges me font dire que je prendrais bien
> une bière avec eux, dès qu’on pourra, pour faire connaissance et alimenter
> la discussion :). C’est plutôt de tenter de comprendre d’où vient cette
> croyance que dans SDx (pour faire court) il n’y a plus de gens du réseau
> réseau qui contrôlent, font des choix, debug ni tordent le truc au plus
> proche de ce qu’ils souhaitent ?
> Pour ma part en tout cas, je n’ai jamais vu d’offre d’IA capable de
> générer toute seule une configuration réseau capable de répondre à la
> demande du DSI, métier, ou autre réseau-phobe… donc il est et reste
> toujours besoin d'au moins un(e) barbu(e) qui s’y colle quoi qu’il arrive,
> de l’étape de design au troubleshooting. Si l’on fait une archi SDN à base
> de netbox + jenkins|AWX + ansible, comme la contribution récente de Jerikan
> par exemple, impossible de la réaliser sans personnes du réseau. Idem si
> l’on fait du SDN à la mode OpenFlow, ou en SD-WAN, faut bien des
> connaissances réseau pour gérer la configuration du système de
> connectivité. Et puis les clickodrome qui génèrent de la config datent de
> bien avant le SDN, par exemple sur les ASA et catalyst pour ne citer qu’eux.
> Est-ce au final une « peur » de ne plus avoir d’accès CLI ? Le SDN
> n’implique pourtant pas la fin complète et définitive du CLI mais pousse,
> comme le monde des admin-sys l'a adopté en majorité, à un CLI restreint à
> l’accès en lecture et avec une poussée des config via le CI/CD pour tracer
> les changements et éviter au maximum de pousser une connerie (car dans SDN
> il n’y a pas de fonction auto-magique de prévention des bêtises, cette
> pseudo-fonction est le résultat de l’expérience des gens mise sous code
> pour jouer des tests de non-régression de façon systématique). Comment
> l’expliquez-vous ?
>
> La deuxième chose qui me donne envie de réagir, c’est que pendant ce temps
> là on ne parle pas de tout le lot de problèmes et de questions qui restent
> ouverts avec le SDN « d’aujourd’hui ». On a un peu évoqué le vendor-lock…
> sujet qui ne date pas du SDN/SD-WAN et qui reste un sujet important. On ne
> parle pas de nos outils de management et leurs IHM qui, d’aussi loin que ma
> mémoire remonte (i.e. HP-NM), nous font râler au quotidien. Le SD-WAN n’en
> est pas exempt. Etc. Bref on ne parle pas, 

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[Gregory CAUCHIE]

Bonjour,

au risque d’être vu pour ce que je ne suis pas, je reprend ci-dessous un 
extrait d’une autre discussion FRnOG de ce jour en lien avec l’objet de cette 
discussion. 

> Le 28 mai 2021 à 08:59, David Ponzone  a écrit :
> 
> 
>> Le 28 mai 2021 à 08:23, Michel Py  a 
>> écrit :
>> 
>> 
>> Yàkà acheter la solution SD-WAN et laisser le clickodrome automagique tout 
>> faire :P C'est démodé, ton modèle : laisser l'ingénieur réseau faire de la 
>> configuration ? pfff.
>> 
> 
> Ouais et avec un peu de chance, ça fait comme Kosc: ça pousse une mauvaise 
> conf sur tout le backbone et tu dois envoyer des techs dans la nuit pour 
> restaurer :)



Il y a deux choses qui me donnent envie de réagir à cet extrait.

La première chose nest pas d’être contre David ni Michel, je ne les connais pas 
d'ailleurs et ces échanges me font dire que je prendrais bien une bière avec 
eux, dès qu’on pourra, pour faire connaissance et alimenter la discussion :). 
C’est plutôt de tenter de comprendre d’où vient cette croyance que dans SDx 
(pour faire court) il n’y a plus de gens du réseau réseau qui contrôlent, font 
des choix, debug ni tordent le truc au plus proche de ce qu’ils souhaitent ?
Pour ma part en tout cas, je n’ai jamais vu d’offre d’IA capable de générer 
toute seule une configuration réseau capable de répondre à la demande du DSI, 
métier, ou autre réseau-phobe… donc il est et reste toujours besoin d'au moins 
un(e) barbu(e) qui s’y colle quoi qu’il arrive, de l’étape de design au 
troubleshooting. Si l’on fait une archi SDN à base de netbox + jenkins|AWX + 
ansible, comme la contribution récente de Jerikan par exemple, impossible de la 
réaliser sans personnes du réseau. Idem si l’on fait du SDN à la mode OpenFlow, 
ou en SD-WAN, faut bien des connaissances réseau pour gérer la configuration du 
système de connectivité. Et puis les clickodrome qui génèrent de la config 
datent de bien avant le SDN, par exemple sur les ASA et catalyst pour ne citer 
qu’eux.
Est-ce au final une « peur » de ne plus avoir d’accès CLI ? Le SDN n’implique 
pourtant pas la fin complète et définitive du CLI mais pousse, comme le monde 
des admin-sys l'a adopté en majorité, à un CLI restreint à l’accès en lecture 
et avec une poussée des config via le CI/CD pour tracer les changements et 
éviter au maximum de pousser une connerie (car dans SDN il n’y a pas de 
fonction auto-magique de prévention des bêtises, cette pseudo-fonction est le 
résultat de l’expérience des gens mise sous code pour jouer des tests de 
non-régression de façon systématique). Comment l’expliquez-vous ?

La deuxième chose qui me donne envie de réagir, c’est que pendant ce temps là 
on ne parle pas de tout le lot de problèmes et de questions qui restent ouverts 
avec le SDN « d’aujourd’hui ». On a un peu évoqué le vendor-lock… sujet qui ne 
date pas du SDN/SD-WAN et qui reste un sujet important. On ne parle pas de nos 
outils de management et leurs IHM qui, d’aussi loin que ma mémoire remonte 
(i.e. HP-NM), nous font râler au quotidien. Le SD-WAN n’en est pas exempt. Etc. 
Bref on ne parle pas, du moins je ne le vois pas et je suis preneur de 
correction si je me trompe, de comment on arrive à se simplifier la tâche au 
quotidien pour un réseau qui donne plus de satisfaction qu’il ne le faisait 
hier… et qui arrête d’être le coupable tout désigné dès que ça toussote 
quelque-part. Vous partagez cet avis ?

--
Grégory

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

RE: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[Michel Py via frnog]

> Kévin CHAILLY a écrit :
> Ben écoute, moi, SDN, je pense que ça veut dire Sac de Noeuds.
> SDN, SD-WAN, c'est pour appâter le chaland.
> Souvent, derrière, on a de la technologie propriétaire clicka-convi.
> Alors bon, le clicka-convi, c'est bien, mais quand ça marche hein.
> Au final, c'est peut être Sorcery Defined Networking.

:-D

Merci pour ce sourire.

Michel.


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

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[Kévin CHAILLY]

Ben écoute, moi, SDN, je pense que ça veut dire Sac de Noeuds.

SDN, SD-WAN, c'est pour appâter le chaland.

Souvent, derrière, on a de la technologie propriétaire clicka-convi. Alors
bon, le clicka-convi, c'est bien, mais quand ça marche hein.

Au final, c'est peut être Sorcery Defined Networking.



Le jeu. 20 mai 2021 à 12:54, Cécile MORANGE  a
écrit :

> Hello la liste ! Je commence à me renseigner sur le SDN et je me suis
> dit que ce serait sympa d'écrire un article sur mon blog
> (blog.ataxya.net) à propos de ça. Vu que sur internet je trouve beaucoup
> plus de présentations commerciales que d'avis réels sur la solution, je
> me suis dit que j'allais demander à mon groupe d'expert préféré ce qu'il
> pense de cette techno. Mes questions sont donc : - Pourquoi passer au
> SDN ? - Il y a-t-il un réel intérêt de passer au SDN ? (Hormis l'aspect
> commercial) - En avez-vous déjà mis en place ? Comment ça s'est passé ?
> Avez-vous remarqué un réel changement dans la façon de faire vos réseaux
> ? (et du gain de temps ?) - Pensez vous que dans 5,10,20 ans, tous les
> réseaux seront du SDN ? Je suis à l'écoute de tous vos retours, ça me
> permettra de mieux comprendre le SDN et l'intérêt (s'il y en a un) !
> (Je sens que je vais lancer un long thread plein de débats :D)
> Merci d'avance !
>
> Cordialement,
>
> --
> Cécile MORANGE
> cont...@cecilemorange.fr
> ataxya.net
> @AtaxyaNetwork
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[Fabien VINCENT FrNOG via frnog]

Le 21-05-2021 09:33, David Ponzone a écrit :

Chouette, une bataille d’acronyme.



Je ne crois pas avoir vu l'IBN :D



Et je crois que j’en ai un qui a été oublié……le vCPE!
Et le uCPE aussi.

Un bel article de 2019 bien bullshit avec des prospectives faites en 
2015:

https://blogdigital.beijaflore.com/vcpe-virtualisation-reseaux/


Le 21 mai 2021 à 09:22, Remi Desgrange  
a écrit :


Moi avec l'émergence du "edge computing" (aka, "le pc dans le placard, 
mais

géré par un cloud provider") j'attends le "SDN At The Edge" :-)

Tiens est-ce que les ROADM c'est du SDN ? Est-ce que des gens utilise 
ça en

vrais ?

On Fri, May 21, 2021 at 9:18 AM Nicolas Vuillermet 


wrote:




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


--
Fabien VINCENT
_@beufanet_


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

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[Gregory CAUCHIE]

Bonjour,

> Le 23 mai 2021 à 18:28, David Ponzone  a écrit :
> 
> Pour compléter ce que tout le monde dit, plein de choses pertinentes 
> d’ailleurs, j’ai un peu de mal avec l’aspect nécessairement centralisé du SDN.

De quelle centralisation parles-tu exactement David ? celle du « management » 
d'où on pousse les config ? celle de la connaissance et de la prise de décision 
du routage/switching à effectuer ? autre ?
Mis à part une utilisation d’openFLow, qui peut se justifier ci ou là, et donc 
une centralisation de la connaissance et du calcul du routage, je ne vois pas 
personnellement pas de relation bijective entre SDN et centralisation.


> Le 23 mai 2021 à 17:26, Hosman Beyrouti  
> a écrit :
> 
> Mais la question de pourquoi on appel cela SDN maintenant?
> 
> Personnellement j'appel cela une Infrastructure DevOps.

Un nouveau vaste sujet, quelle définition pour DevOps :)

Moi je vois le DevOps (et ses consorts NetOps, NetDevOps, SecOps, NetSecOps, …) 
comme une _culture_ qui utilise typiquement « Agile » comme méthodologie 
(Scrum, XP, …) de coordination et le CI/CD comme outillage de déploiement 
d’infrastructures As Code. Bref comme des principes de travail et 
d’organisation.
Le SDN pourrait être le pan réseau dans l’infrastructure as Code, mais comme on 
a pu le parcourir dans ce thread, le mot SDN est aussi utilisé dans des cas 
sans infra as code. Ce constat peut se décliner aussi d'ailleurs sur le 
stockage (Software Defined Storage) et les serveurs (Software Defined Compute).
Bon je suis pas mal niveau bingo d’acronyme, je vais m’arrêter là 

--
Grégory

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

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[Xavier Claude]

On Sun, May 23, 2021 at 06:28:34PM +0200, David Ponzone wrote:
> Pour compléter ce que tout le monde dit, plein de choses pertinentes 
> d’ailleurs, j’ai un peu de mal avec l’aspect nécessairement centralisé du SDN.
> 
> Pour moi un Mikrotik avec son language de scripting qui permet de faire un 
> paquet de choses, c’est du SDN.
> Et globalement, l’approche centralisée en réseau, ça me fait un peu flipper 
> (comme le HLR en mobile…).

Pour moi, c'est justement l'intérêt du SDN, c'est du software defined network,
pas du software defined router. L'intérêt d'avoir un point centralisé, c'est
justement d'éviter de devoir se connecter à chaque équipement pour le
configurer (sans forcément connaître toute la topologie du réseau, et avec les
problèmes de concurrence que ça entraîne). Un point centralisé permet d'avoir
des mises à jour cohérentes et (à peu près) atomiques.

Xavier.


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

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[David Ponzone]

Pour compléter ce que tout le monde dit, plein de choses pertinentes 
d’ailleurs, j’ai un peu de mal avec l’aspect nécessairement centralisé du SDN.

Pour moi un Mikrotik avec son language de scripting qui permet de faire un 
paquet de choses, c’est du SDN.
Et globalement, l’approche centralisée en réseau, ça me fait un peu flipper 
(comme le HLR en mobile…).

> Le 23 mai 2021 à 17:26, Hosman Beyrouti via frnog  a écrit :
> 
> Bonjour,
> 
> "
> C'est à ça que j'identifie le SDN, une entité qui a la connaissance
> globale du réseau et qui peut intervenir instantanément sur les flux en
> fonction d'évènements, besoins, etc.
> "
> 
> J'avoue la définition est vague et super marketing certainement pour vendre 
> des solutions constructeurs.
> 
> Si effectivement nous parlons de "Software Defined Networking" nous reprenons 
> donc un terme déjà utilisé depuis longtemps.
> 
> Bref si une Infra DevOps qui fait plus qu'ouvrir les portes aux IA. Le gain 
> de temps est juste énorme.
> Pour déployer une technologie cela devient un gain de temps énorme.
> En terme de consommation d'Energie et donc des ressources utilisées, c'est 
> juste incroyablement bien pensée.
> ...


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

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[Hosman Beyrouti via frnog]

Bonjour,

"
C'est à ça que j'identifie le SDN, une entité qui a la connaissance
globale du réseau et qui peut intervenir instantanément sur les flux en
fonction d'évènements, besoins, etc.
"

J'avoue la définition est vague et super marketing certainement pour vendre des 
solutions constructeurs.

Si effectivement nous parlons de "Software Defined Networking" nous reprenons 
donc un terme déjà utilisé depuis longtemps.

Bref si une Infra DevOps qui fait plus qu'ouvrir les portes aux IA. Le gain de 
temps est juste énorme.
Pour déployer une technologie cela devient un gain de temps énorme.
En terme de consommation d'Energie et donc des ressources utilisées, c'est 
juste incroyablement bien pensée.

Une Infra Ansible Prometheus Grafana donc TSDB couplé a GITLAB, Openstack pour 
le code et démarrer des VM ou dockers au besoin d'une action. Génial.
Tous cela commandé par API via une simple commande http et ce configurant via 
un fichier yaml ou jinja2 ou en faite un txt...

Bref tu finis par modifier toujours les mm types de fichiers sur 10 
technologies différentes qui s'intègrent facilement dans des dockers.
Voila l'arrivée de l'IA car on viens de lui donner une ossature maintenant il 
faut le cerveau qui n'a qu'a modifier un fichier txt sur un GITLAB du coup cela 
devient très simple.
Coupler a un systeme de LOG et de monitoring.

Déployez 1 000 000 machines en 30 secondes configurées est opérationnels en un 
clique...
Pouvoir revenir en arrière en un rien de temps ou appliquer une modification.
En faire un bouton dans un SI rendant la tache IT compliqué accessible a un 
simple technicien.
Qd tu voie le routeur sur ton SI tu clique configurer et hop tous est 
configurés en 15 secondes, Téléphonies complètes son monitoring, serveur web, 
serveur RDP etc en faite tous...

Déployer un réseau complet operateur MPLS par exemple et revenir en arrière en 
un clique...
Il est maintenant possible de le faire de façon graphique. Donc un directeur 
technique peut design son réseau de façon graphique et tester la solution sur 
un banc de test ou en production.
Sans être bloquer par un soucis d'oubli de tel ou tel options sur tel routeur 
ou tel switch ou tel serveur DNS etc etc.
Ca donne le pouvoir de mieux définir les architectures réseaux.

Tu fait un POP et tu le réplique c'est juste énorme en gain de temps.
Avec Centreon il était déjà possible d'automatiser des réponses a un PB sur un 
host ou un service. Du SDN dans ce cas?

J'ai vue du DHCP dans le lot des réponses exemple est ce que l'API de KEA-DHCP 
a lui seul est un gros module de SDN? :)
Si les technologies que je site sont du SDN dans ce cas pour nous cela est 
vital pour pouvoir allez a la plage le week-end et dormir la nuit...
Par contre on fait déjà tous des choses déjà très proches depuis de nombreuses 
années.

Je penses que maitriser son réseau justement rend la sécurité bien meilleur car 
tu dégage du temps pour la bichoter et tu as des rapports automatiser des 
changements sur des machines ou des switch. De type OSSEC pour linux.

Accessoirement ton IA fait le tour de ton infra régulièrement en cas de 
changement elle répare la configuration et t'avertis.
A tous les niveaux ce type d'infra est meilleur d'ailleurs adopter par tous 
ceux qui la test en ce moment.

Mais la question de pourquoi on appel cela SDN maintenant?

Personnellement j'appel cela une Infrastructure DevOps.

Cordialement Hosman.

- Mail original -
De: "Gregory CAUCHIE" 
À: frnog@frnog.org
Envoyé: Samedi 22 Mai 2021 17:34:52
Objet: Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou 
réalité ?

> Le 21 mai 2021 à 10:59, Xavier Beaudouin  a écrit :
> 
> Après le jour où le machin se fracasse ou que la license est venue a 
> expiration, on peux très vite sortir le camion a popcorn et attendre qu'on 
> appelle un dino pour réparer le merdier.
> 
> Le cote gênant, c'est surtout le coté privateur de cette mode aka vendor 
> locked.

Je suis en phase avec l’argument du vendor-lock. On peut argumenter 
qu’aujourd’hui on a déjà du vendor-lock quand on utilise des fonctions type 
MC-LAG ou HA dans le BNG (PPP, DHCP, …), mais c’est un périmètre moins étendu 
que toute la solution SD-WAN, i.e. la totalité des équipements et du 
manager/orchestrateur.
Aussi, il y a une solution OpenSource SD-WAN (cf. FLexiWAN) dont 
l’implémentation équipement est effectivement opensource mais dont le 
manager/orchestrateur est propriétaire. Le vendor lock est donc moindre du fait 
qu’on est dans un univers Linux où on peut compléter le SD-WAN « basique » avec 
ce qu’on veut d’autre. Reste toujours ce vendor-lock du manager/orchestrateur 
aujourd’hui inhérent au SD-WAN, sans de grosses chances que cela change dans le 
futur.

Pour la partie licence en revanche, beaucoup de constructeur ont une solution 
où l’expiration de la licences ne provoque pas l’arrêt de la solution. Il n’y a 
simplement plus de support dans ces cas là. Po

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[Gregory CAUCHIE]

> Le 21 mai 2021 à 10:59, Xavier Beaudouin  a écrit :
> 
> Après le jour où le machin se fracasse ou que la license est venue a 
> expiration, on peux très vite sortir le camion a popcorn et attendre qu'on 
> appelle un dino pour réparer le merdier.
> 
> Le cote gênant, c'est surtout le coté privateur de cette mode aka vendor 
> locked.

Je suis en phase avec l’argument du vendor-lock. On peut argumenter 
qu’aujourd’hui on a déjà du vendor-lock quand on utilise des fonctions type 
MC-LAG ou HA dans le BNG (PPP, DHCP, …), mais c’est un périmètre moins étendu 
que toute la solution SD-WAN, i.e. la totalité des équipements et du 
manager/orchestrateur.
Aussi, il y a une solution OpenSource SD-WAN (cf. FLexiWAN) dont 
l’implémentation équipement est effectivement opensource mais dont le 
manager/orchestrateur est propriétaire. Le vendor lock est donc moindre du fait 
qu’on est dans un univers Linux où on peut compléter le SD-WAN « basique » avec 
ce qu’on veut d’autre. Reste toujours ce vendor-lock du manager/orchestrateur 
aujourd’hui inhérent au SD-WAN, sans de grosses chances que cela change dans le 
futur.

Pour la partie licence en revanche, beaucoup de constructeur ont une solution 
où l’expiration de la licences ne provoque pas l’arrêt de la solution. Il n’y a 
simplement plus de support dans ces cas là. Pour d’autres en revanche, tout 
s’arrête et le hardware devient clairement inutilisable. Ce point licence se 
juge donc en fonction du constructeur.


> Le 21 mai 2021 à 13:04, Pierre Colombier via frnog  a écrit :
> 
> J'attends avec impatience le syndrome de la poule et de l'oeuf.
> Quand le déploiement automatisé du "software defined" reposera sur lui-même, 
> et qu'il faudra reseter l'ensemble parce que la manager s'est fait hacker, ça 
> promet d'être un spectacle amusant…

Rien de différent avec ce qui se fait actuellement non ? qui n’a jamais poussé 
une « grosse bêtise » dans un script appliqué à beaucoup de machines ? le SDN 
ce n’est pas de l’IA (avec tout ce qu’on pourrait en dire de pour et contre), 
donc reste toujours la qualité de ce qui est poussé, niveau 
architecture-ingénierie-configuration. L’avantage d’un SDN utilisant les 
concept de CI/CD, c’est de pouvoir détecter le plus possible d’erreurs avant 
déploiement, voire de faire très vite un retour arrière dès la première erreur 
poussée, et donc de limiter le plus possible la casse.


> Le 21 mai 2021 à 11:33, Marc Abel  a écrit :
> 
> Pardonnez ma méfiance envers la centralisation du control-plane mais j'ai 
> déjà subi des déboires à cause de technos censées fiabiliser le réseau...
> Certains d'entre vous ont-ils eu des serveurs injoignables parce que le HA 
> foirait ? ou avec HSRP/VRRP/load ballancer/ etc. quelle que soit la cause.


Oui. Le cas le plus simple est quand tu as un problème sur le Tx d’un des 
routeurs, amenant la situation où les deux passent en master. Dans ce cas pas 
de soucis sur les flux upstream serveur vers extérieur, mais problème sur les 
flux downstream, avec autant de différents impacts que d’ingénierie en place.


> Le 21 mai 2021 à 12:42, Benjamin CALLAR  a écrit :
> 
> En ce qui concerne le SD-WAN, simple Bullshit ... faire du routage 
> intelligent, ce n'est pas nouveau, et ça ne se vends pas aussi cher ! 

Certes le routage intelligent n’est pas nouveau, mais SD-WAN ne se résume pas à 
ça. Les Ipanéma, Riverbed, SilverPeak, Streamcore and Co ont du ajouter faire 
du dev a minima pour la montée de tunnels et pour mettre en place et coupler 
des mécanisme de mesure de bout-en-bout sur le tunnel pour prendre en compte 
les comportement du WAN et surtout des différents débits de l’accès distant.

--
Grégory

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

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[Emmanuel DECAEN]

Bonsoir,

Le 21/05/2021 à 18:48, aderum...@odiso.com a écrit :

Le vendredi 21 mai 2021 à 14:02 +0200, Emmanuel DECAEN a écrit :

Sur le principe oui, c'est sympa, mais à moins de changer toute
l'infrastructure, la suppression de l'ARP peut poser problème si elle se
fait par étape, en commençant par le coeur.

Cas concret: Infrastructure avec deux switchs clients A et B (L2)
connectés sur deux switchs de coeur "datacenter" (VXLAN + suppress ARP +
BGP-EVPN)
Ton client décide de basculer son serveur entre ses deux switchs (A->B)
=> le serveur devient injoignable.

Dans un réseau uniquement L2, à la première requête ARP, la réponse du
serveur permet de mettre à jour la table d'adresse MAC sur le chemin de
switchs (y compris le coeur).
Dans un réseau mixte L2 + VXLAN (avec suppress-arp), le requête ARP sera
filtrée (suppress-arp) et n'arrivera jamais au serveur, le serveur ne
sera plus joignable.

Il y a plusieurs solutions de contournement : timeout arp, retrait du
suppress-arp
Si quelqu'un a une meilleure solution, je suis preneur.

Mais en attendant, à diagnostiquer la première fois, c'est un peu 
coton ;-)





Je pense que le problème, c'est que tu ne fais pas de l'evpn de bout 
en bout, mais uniquement sur tes coeurs.


Oui, nous sommes d'accord, c'est bien le problème avec le suppress-arp 
dans ce contexte.
Et je ne me vois pas balancer tout le parc de switchs L2 d'extrémité 
parce qu'ils ne savent pas faire du VXLAN.
=> Le compromis du retrait du suppress-arp est acceptable en attendant 
le renouvèlement du parc :-)


Bon Week-End

--
*Emmanuel DECAEN*


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

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[aderumier]

Le vendredi 21 mai 2021 à 14:02 +0200, Emmanuel DECAEN a écrit :
> Bonjour,
> 
> Le 21/05/2021 à 12:42, Benjamin CALLAR a écrit :
> > Pour argumenter le débat, le SDN a tout a fait sa place dans un 
> > environnement complexe style Datacenter, et comme j'ai pu le voir
> > plus 
> > tôt aussi, en séparant le controlplane du dataplane.
> > Imaginez un monde ou le broadcast ARP disparait, ce serait top non
> > ? 
> > (ne me parlez pas d'IPv6 ...) Clairement, le SDN peut répondre à
> > cela, 
> > le contrôleur ayant une connaissance globale du réseau, la requête 
> > peut être répondu localement par le premier saut sans avoir à 
> > traverser le réseau  !
> 
> 
> Sur le principe oui, c'est sympa, mais à moins de changer toute 
> l'infrastructure, la suppression de l'ARP peut poser problème si elle
> se 
> fait par étape, en commençant par le coeur.
> 
> Cas concret: Infrastructure avec deux switchs clients A et B (L2) 
> connectés sur deux switchs de coeur "datacenter" (VXLAN + suppress
> ARP + 
> BGP-EVPN)
> Ton client décide de basculer son serveur entre ses deux switchs (A-
> >B) 
> => le serveur devient injoignable.
> 
> Dans un réseau uniquement L2, à la première requête ARP, la réponse
> du 
> serveur permet de mettre à jour la table d'adresse MAC sur le chemin
> de 
> switchs (y compris le coeur).
> Dans un réseau mixte L2 + VXLAN (avec suppress-arp), le requête ARP
> sera 
> filtrée (suppress-arp) et n'arrivera jamais au serveur, le serveur ne
> sera plus joignable.
> 
> Il y a plusieurs solutions de contournement : timeout arp, retrait du
> suppress-arp
> Si quelqu'un a une meilleure solution, je suis preneur.
> 
> Mais en attendant, à diagnostiquer la première fois, c'est un peu
> coton ;-)
> 
> 

Je pense que le problème, c'est que tu ne fais pas de l'evpn de bout en
bout, mais uniquement sur tes coeurs.
Au DC (on fait du hosting), on fait directement de l'evpn sur les
leafs/swich racks (et meme sur les hyperviseurs en direct pour les vms)
, et meme pas sur les coeurs.
Du coup, aucun soucis avec la suppression d'arp.



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

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[Emmanuel DECAEN]

Le 21/05/2021 à 12:42, Benjamin CALLAR a écrit :


Idem sur la gestion des tables CAM, où celle-ci peuvent être gérer de 
manière centralisée, et éviter l'auto-apprentissage de celles-ci, et 
pourquoi pas faire du switching intelligent (load balancing, ...) 
comme le permet à peu prêt le PBR que nous connaissons tous, mais au 
niveau 2.=> Adieu le spanning-tree



Oui, c'est un gros gain de supprimer le spanning-tree, on utilise tous 
les liens en même temps, et la bascule en cas de panne se fait en moins 
d'une seconde.
Pour éviter le risque de SPOF avec la centralisation, on a "stocké" les 
MAC + IP/MAC sur deux route-reflector.


Pour revenir à la partie configuration centralisée, pour moi, cela reste 
le point délicat.
Sur le papier c'est sympa, mais dans la réalité les modules ansible 
évoluent parfois avec des modifications critiques, il faut être attentif 
et prudent.
Par exemple la disparition du "switchport mode" dans une évolution : 
https://github.com/ansible/ansible/issues/65032


Je pense que la centralisation de la configuration est indispensable 
pour un réseau significatif en constante évolution, ça simplifie les 
configurations et limite les erreurs, mais il faut être très rigoureux 
dans le suivi du produit.
Si le produit est opensource (comme ansible), cela signifie passer du 
temps à suivre ses évolutions et bugs.
Si le produit est propriétaire, il faut non seulement suivre le produit, 
mais aussi l'évolution de l'éditeur (santé, rachats, etc.) pour 
s'assurer de la pérennité du produit.


--
*Emmanuel DECAEN*

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

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[Jérôme Marteaux]

Le 21/05/2021 à 11:46, Xavier Beaudouin a écrit :

Hello Jérôme,



Je ne suis pas tout à fait d'accord. Ce genre de produit permet:
  - de permettre à plus de gens (il n'y a pas tant que ça d'expert
réseau sur le marché de l'emploi) de mettre en prod des services sur
étagère:
 - donc d'accélérer la livraison du service;
 - de standardiser le déploiement, donc moins d'erreur, moins
d'échec de livraison, plus de satisfaction client;
 - plus d'homogénéité du réseau, une documentation à jour ? Donc
plus aisé de faire du troubleshooting dessus;
 - donc de diminuer le coût du service;
 - donc d'augmenter le nombre de service pour qu'il puisse profiter
à plus de gens. S'il fallait qu'un ingé télécom travaille 2 heures pour
activer une FTTO/FTTH il n'y aurai pas grand monde qui aurait la fibre à
son travail / à la maison.


Oui et non... C'est "pratique" pour mettre en place un service ou le déployer,
là dessus on est d'accord, mais laisser des gens qui ont peu ou pas d'expertise
a déployer des réseaux de prod, on arrive vite fait à un bordel sans nom,
des choix discutables, et aussi des problèmes de sécurité.
Allez demander au sysadmin quand ils se battent avec des devoups qui déploient
des dockers récupérés je ne sais où, avec des mises à jour de sécurité
inexistantes depuis 5 ans...
  


Effectivement le SDN a 2 cibles, autant tu décris un end-user qui va 
assembler des briques pour construire un service où il faut normalement 
des compétences d'architecte d'infrastructure. Je partage ton point de vue.
Mon argumentaire est vu d'un ISP qui livre des services télécom où le 
SDN est la base de l'usine télécom.


C'est vrai que l'usage que l'on peut en faire est bien différent.



   - le but ultime de ce genre de produit c'est d'arriver à standardiser
des pratiques (que contient le service, son déploiement, sa
configuration, son exploitation ...). Par exemple les emails, jusqu'aux
années 2010 il fallait gérer son serveur mail avec le smtp, l'imap/pop,
le webmail, les anti-spam, anti-virus, les quarantaines et c'était les
admin sys qui géraient le support des utilisateurs. Grâce à l'essor de
gmail, azure, 95% des boîtes mails sont maintenant dans le cloud avec
devant des clickodromes permettant de gérer ces boites mails. Depuis, je
ne gère plus cette partie ! Je peux me concentrer sur de l'admin sys qui
m'intéresse plus !


Et quand gmail ou azure t'as buté ton serveur, tu es aussi dans la merde,
pareil... vu le nombre de gens qui ne comprennent pas l'infra du mail et
qui pensent que ça doit être immédiat...

Je gère encore mon serveur, il y a des solutions qui le permette sans avoir
a se taper tout... ceci dit, ca apprends les protocoles et comment débugger
les choses quand ça part en couille... (aka expliquer aux devoups ce qu'ils
doivent mettre dans un mail pour pas qu'il soit jeté ).



C'est vrai, j'ai également encore mon serveur perso, mais c'est assez 
rare que gmail/azure perdent le serveur, sinon ils ne géreraient pas 
autant de boites mails.



Est-ce encore nécessaire d'être un expert SMTP pour réussir à envoyer un 
mail ?
Hier où la majorité des protocoles étaient encodés en binaire (pratique 
de faire un recv(fd, _structure, sizeof(ma_structure)) et pour parler 
avec ce protocole il fallait en devenir un expert. Où aujourd'hui 99% 
des protocoles sont du JSON/XML sur de l'HTTP où les lib HTTP/REST/SOAP 
(quel gros mot !) sont suffisamment bien faites pour ne pas avoir à 
connaître comment fonctionne HTTP 1.1.
Lorsque je vois toutes les difficultés qu'a HTTP 2 à émerger, seules les 
grosses boîtes de dév arrivent à faire de l'HTTP 2 car personne n'a 
envie de se replonger dans HTTP (en plus pour quel bénéfice ?).


Toutes ces expertises se perdent car elles ne sont plus nécessaires. 
Avant les années 2005 à chaque installation d'un linux je me recompilais 
le kernel pour l'adapter au hardware, combien de fois il fallait avoir 
le module xxx pour la carte raid, pour le chipset réseau ? Maintenant je 
ne sais même pas à quelle version de linux on en est, ma ubuntu boot sur 
n'importe quel serveur / desktop.
Est-ce que ça serait bien que je garde cette connaissance sur un usage 
qui est devenu obsolète ? Je ne pense pas.



Et pour finir, je ne pense pas que ni les gros acteurs ni les petits
utilisent ce genre d'outil marketé par les équipementiers, il y a
largement la place pour développer des solutions home-made.


+1. Mais attention au SSII^H^H^H^HESN qui aiment bien pousser des solutions
chères et privatrices...



Je trouve que les marketeux sont des génies. Comme Sun & IBM qui 
vendaient des serveurs "optimisés" pour faire tourner du Java qu'ils 
enrichissaient. Les ESN préconisaient Java et recommandaient donc ces 
mêmes serveurs.


Si tu veux du Salesforce il faut intégrer un maximum de chose dessus car 
c'est plus sympa, d'où sa marketplace qui prend tout son intérêt.


AWS vient avec son écosystème (S3, route53, EFS, EKS, ...), ils ont crée 
un marché d'infogéreurs qui 

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[Emmanuel DECAEN]

Bonjour,

Le 21/05/2021 à 12:42, Benjamin CALLAR a écrit :
Pour argumenter le débat, le SDN a tout a fait sa place dans un 
environnement complexe style Datacenter, et comme j'ai pu le voir plus 
tôt aussi, en séparant le controlplane du dataplane.
Imaginez un monde ou le broadcast ARP disparait, ce serait top non ? 
(ne me parlez pas d'IPv6 ...) Clairement, le SDN peut répondre à cela, 
le contrôleur ayant une connaissance globale du réseau, la requête 
peut être répondu localement par le premier saut sans avoir à 
traverser le réseau  !



Sur le principe oui, c'est sympa, mais à moins de changer toute 
l'infrastructure, la suppression de l'ARP peut poser problème si elle se 
fait par étape, en commençant par le coeur.


Cas concret: Infrastructure avec deux switchs clients A et B (L2) 
connectés sur deux switchs de coeur "datacenter" (VXLAN + suppress ARP + 
BGP-EVPN)
Ton client décide de basculer son serveur entre ses deux switchs (A->B) 
=> le serveur devient injoignable.


Dans un réseau uniquement L2, à la première requête ARP, la réponse du 
serveur permet de mettre à jour la table d'adresse MAC sur le chemin de 
switchs (y compris le coeur).
Dans un réseau mixte L2 + VXLAN (avec suppress-arp), le requête ARP sera 
filtrée (suppress-arp) et n'arrivera jamais au serveur, le serveur ne 
sera plus joignable.


Il y a plusieurs solutions de contournement : timeout arp, retrait du 
suppress-arp

Si quelqu'un a une meilleure solution, je suis preneur.

Mais en attendant, à diagnostiquer la première fois, c'est un peu coton ;-)


--
*Emmanuel DECAEN*


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

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[Pierre Colombier via frnog]

J'attends avec impatience le syndrome de la poule et de l'oeuf.

Quand le déploiement automatisé du "software defined" reposera sur 
lui-même, et qu'il faudra reseter l'ensemble parce que la manager s'est 
fait hacker, ça promet d'être un spectacle amusant...




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

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[Benjamin CALLAR]

Hello la liste !

Bravo Cécile pour le débat, quel engouement

Pour moi le SDN, c'est une vraie évolution, mais qui malheureusement a 
été complètement pompée par le marketing et qui en a fait n'importe 
quoi. J'aime le comparer à d'autres tendances - et que j'ai eu 
l'occasion de voir plus tôt dans le thread - que sont le "Cloud" alors 
que c'est juste de la VM (ça doit mieux se vendre les termes anglais XD) 
ou encore le "AI" alors qu'il s'agit juste de statistiques sans aucun 
apprentissage (mais encore une fois, ça se vend vachement bien une 
solution qui fait de "l'intelligence artificielle" (=> un calcul de 
moyenne ? ) !).


Autant je suis 1000% pour l'esprit startup, mais il y a des niches qui 
ont été exploitées à en perdre leur sens .. Le SDN, SD-WAN, AI, Cloud, 
Cybersécurité en font partie...


Et je ne parle pas des écoles qui ont encore plus exploité la chose en 
vendant des formations "Ingénieur Cloud", "Ingénieur cybersécurité, 
"Ingénieur AI" ... alors que le programme corresponds à un titre 
d'ingénieur Systèmes et réseaux ou développeur d'il y a quelques années ...
Je ne mets pas tous les oeufs dans le même panier, il y a des écoles qui 
respectent leurs engagements, mais pour la majorité que j'ai eu 
l'occasion de voir ce n'est pas le cas ...


Malheureusement, cela donne une vision erronée du monde du travail aux 
jeunes qui souhaiteraient rejoindre le milieu.


Pour argumenter le débat, le SDN a tout a fait sa place dans un 
environnement complexe style Datacenter, et comme j'ai pu le voir plus 
tôt aussi, en séparant le controlplane du dataplane.
Imaginez un monde ou le broadcast ARP disparait, ce serait top non ? (ne 
me parlez pas d'IPv6 ...) Clairement, le SDN peut répondre à cela, le 
contrôleur ayant une connaissance globale du réseau, la requête peut 
être répondu localement par le premier saut sans avoir à traverser le 
réseau  !


Idem sur la gestion des tables CAM, où celle-ci peuvent être gérer de 
manière centralisée, et éviter l'auto-apprentissage de celles-ci, et 
pourquoi pas faire du switching intelligent (load balancing, ...) comme 
le permet à peu prêt le PBR que nous connaissons tous, mais au niveau 
2.=> Adieu le spanning-tree


Et il y encore pleins d'autres exemple, les protocoles de NHRP, de LAGP, 
de PBR, peuvent tous être "SDN-isé" pour y ajouter les besoins liés à 
des contextes complexes, et surtout des règles spécifiques à l'entreprise.


Le problème des protocoles que je viens de citer, c'est qu'il faut que 
ça évolue et que ça arrive dans le firmware (qu'il faut mettre à jour), 
avec le SDN, chacun peut y mettre du sien, le contrôleur n'étant qu'un 
"programme" qui peut être mis à jour bien plus souvent qu'un firmware. 
(imaginez la puissance d'un contrôleur opensource combiné avec un bon 
ingénieur)


C'est à ça que j'identifie le SDN, une entité qui a la connaissance 
globale du réseau et qui peut intervenir instantanément sur les flux en 
fonction d'évènements, besoins, etc.


J'ai eu la chance il y a quelques années de suivre une formation 
Coursera à ce sujet, qui est justement dans cette définition du SDN : 
https://www.coursera.org/learn/sdn?#about


En ce qui concerne le SD-WAN, simple Bullshit ... faire du routage 
intelligent, ce n'est pas nouveau, et ça ne se vends pas aussi cher ! Et 
quand je vois à quel point les solutions vendues sont fermées, bridée, 
... ça me déprime ...


J'espère avoir apporté ma pierre au débat,

Vous souhaitant une agréable journée

Benjamin CALLAR


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

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[Xavier Beaudouin]

Hello Jérôme,


> Je ne suis pas tout à fait d'accord. Ce genre de produit permet:
>  - de permettre à plus de gens (il n'y a pas tant que ça d'expert
> réseau sur le marché de l'emploi) de mettre en prod des services sur
> étagère:
> - donc d'accélérer la livraison du service;
> - de standardiser le déploiement, donc moins d'erreur, moins
> d'échec de livraison, plus de satisfaction client;
> - plus d'homogénéité du réseau, une documentation à jour ? Donc
> plus aisé de faire du troubleshooting dessus;
> - donc de diminuer le coût du service;
> - donc d'augmenter le nombre de service pour qu'il puisse profiter
> à plus de gens. S'il fallait qu'un ingé télécom travaille 2 heures pour
> activer une FTTO/FTTH il n'y aurai pas grand monde qui aurait la fibre à
> son travail / à la maison.

Oui et non... C'est "pratique" pour mettre en place un service ou le déployer,
là dessus on est d'accord, mais laisser des gens qui ont peu ou pas d'expertise
a déployer des réseaux de prod, on arrive vite fait à un bordel sans nom,
des choix discutables, et aussi des problèmes de sécurité.
Allez demander au sysadmin quand ils se battent avec des devoups qui déploient
des dockers récupérés je ne sais où, avec des mises à jour de sécurité 
inexistantes depuis 5 ans...
 
>   - en tant qu'expert réseau je préfère travailler sur des sujets
> autrement plus intéressants que de déployer des services basique sans
> intérêt technique et à travailler à la chaîne au déploiement des
> services qui sont toujours les mêmes;

Déployer des services basic peut être automatisés *sans* passer par
un SDN/SD-WAN proprio.

>   - le but ultime de ce genre de produit c'est d'arriver à standardiser
> des pratiques (que contient le service, son déploiement, sa
> configuration, son exploitation ...). Par exemple les emails, jusqu'aux
> années 2010 il fallait gérer son serveur mail avec le smtp, l'imap/pop,
> le webmail, les anti-spam, anti-virus, les quarantaines et c'était les
> admin sys qui géraient le support des utilisateurs. Grâce à l'essor de
> gmail, azure, 95% des boîtes mails sont maintenant dans le cloud avec
> devant des clickodromes permettant de gérer ces boites mails. Depuis, je
> ne gère plus cette partie ! Je peux me concentrer sur de l'admin sys qui
> m'intéresse plus !

Et quand gmail ou azure t'as buté ton serveur, tu es aussi dans la merde,
pareil... vu le nombre de gens qui ne comprennent pas l'infra du mail et
qui pensent que ça doit être immédiat...

Je gère encore mon serveur, il y a des solutions qui le permette sans avoir
a se taper tout... ceci dit, ca apprends les protocoles et comment débugger
les choses quand ça part en couille... (aka expliquer aux devoups ce qu'ils
doivent mettre dans un mail pour pas qu'il soit jeté ).

> Et pour finir, je ne pense pas que ni les gros acteurs ni les petits
> utilisent ce genre d'outil marketé par les équipementiers, il y a
> largement la place pour développer des solutions home-made.

+1. Mais attention au SSII^H^H^H^HESN qui aiment bien pousser des solutions
chères et privatrices...

> Le véritable sujet derrière tout ça c'est la scalabilité que ces outils
> permettent de gagner. A la base on est un artisan qui façonnons nos
> réseaux, nos outils (bientôt le dernier "dino" des télécom au JT de TF1
> ? :) ). Mais pour passer à la vitesse supérieure, il nous faut une usine
> avec des robots que des humains moins expert peuvent piloter et contrôler.

*SURTOUT* contrôler... mais ça me fait penser aux générateurs de codes
qui ne sont plus trop à la mode... 

/Xavier


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

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[Jérôme Marteaux]

Le 21/05/2021 à 10:59, Xavier Beaudouin a écrit :

Hello

Et pour avoir lu ce fil, je suis plutôt entre "c'est un nouveau truc" et 
"mouais".

En résumé, il y a des gens qui cherchent des personnes ayant 5 ans d'expé sur 
les techno cisco sdn (je ne sais plus quel produit et bon ... osef) et ça me 
fait quand même un peu marrer vu la jeunesse du produit.

En gros le seul et unique problème de ces machins, c'est que ça fait ce qui est 
prévu pour une marque X ou Y... Évidement l'interop n'est pas là. Si tu tu veux 
du Cisco tu prends le produit truc et si tu veux du juniper tu prends le 
produit truc.

D'après l'expérience que j'ai avec des gens qui l'utilise c'est que le soft a 
décidé un certain nombre de choses qui simplifie bcp l'admin du reseau 
(syndrôme du pousse bouton sans savoir ce qui se passe en dessous, chose que 
les dino comme moi n'aime pas), mais... quand ça sort des rails de ce qui a été 
prévu par le cahier de charges des dev du soft de SD-WAN, là c'est une autre 
chose.

Après le jour où le machin se fracasse ou que la license est venue a 
expiration, on peux très vite sortir le camion a popcorn et attendre qu'on 
appelle un dino pour réparer le merdier.

Le cote gênant, c'est surtout le coté privateur de cette mode aka vendor locked.
Et on est bon nombre a râler vis a vis de leur pratiques commerciales qui nous 
les brisent.

Pour l'instant je suis dans le wait and see... mais en tous cas dans la boite 
où je bosse, le réseau est suffisamment en dehors de clous habituels pour ne 
pas rentrer dans les cases SD-WAN...

Xavier


Je ne suis pas tout à fait d'accord. Ce genre de produit permet:
 - de permettre à plus de gens (il n'y a pas tant que ça d'expert 
réseau sur le marché de l'emploi) de mettre en prod des services sur 
étagère:

- donc d'accélérer la livraison du service;
- de standardiser le déploiement, donc moins d'erreur, moins 
d'échec de livraison, plus de satisfaction client;
- plus d'homogénéité du réseau, une documentation à jour ? Donc 
plus aisé de faire du troubleshooting dessus;

- donc de diminuer le coût du service;
- donc d'augmenter le nombre de service pour qu'il puisse profiter 
à plus de gens. S'il fallait qu'un ingé télécom travaille 2 heures pour 
activer une FTTO/FTTH il n'y aurai pas grand monde qui aurait la fibre à 
son travail / à la maison.


  - en tant qu'expert réseau je préfère travailler sur des sujets 
autrement plus intéressants que de déployer des services basique sans 
intérêt technique et à travailler à la chaîne au déploiement des 
services qui sont toujours les mêmes;


  - le but ultime de ce genre de produit c'est d'arriver à standardiser 
des pratiques (que contient le service, son déploiement, sa 
configuration, son exploitation ...). Par exemple les emails, jusqu'aux 
années 2010 il fallait gérer son serveur mail avec le smtp, l'imap/pop, 
le webmail, les anti-spam, anti-virus, les quarantaines et c'était les 
admin sys qui géraient le support des utilisateurs. Grâce à l'essor de 
gmail, azure, 95% des boîtes mails sont maintenant dans le cloud avec 
devant des clickodromes permettant de gérer ces boites mails. Depuis, je 
ne gère plus cette partie ! Je peux me concentrer sur de l'admin sys qui 
m'intéresse plus !


Et pour finir, je ne pense pas que ni les gros acteurs ni les petits 
utilisent ce genre d'outil marketé par les équipementiers, il y a 
largement la place pour développer des solutions home-made.


Le véritable sujet derrière tout ça c'est la scalabilité que ces outils 
permettent de gagner. A la base on est un artisan qui façonnons nos 
réseaux, nos outils (bientôt le dernier "dino" des télécom au JT de TF1 
? :) ). Mais pour passer à la vitesse supérieure, il nous faut une usine 
avec des robots que des humains moins expert peuvent piloter et contrôler.



Jérôme

--
Jérôme Marteaux


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

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[Marc Abel]

Bonjour,

En un mot c'est pas pour moi (mais ça peut aider certains d'entre vous) 
(j'ai pas dit comme IPv6).


Pardonnez ma méfiance envers la centralisation du control-plane mais 
j'ai déjà subi des déboires à cause de technos censées fiabiliser le 
réseau...
Certains d'entre vous ont-ils eu des serveurs injoignables parce que le 
HA foirait ? ou avec HSRP/VRRP/load ballancer/ etc. quelle que soit la 
cause.


C'est vrai que le plus souvent les pannes viennent d'erreurs humaines 
(on travaille et ça se voit ;-) mais on peut aussi faire des dégâts sur 
du SDN.
J'imagine que si le SDN tient la route (si j'ose dire) il va éviter les 
incohérences/boucles/duplicate mais sera-t-il exempt de toute faille/bug ?


Le cerveau du SDxxx n'est-il pas un SPOF ? il va falloir le redonder et 
assurer le HA (et penser à payer le support/la licence à temps).


N'ayant pas de budget/ de temps libre / de besoin de ce genre je reste 
sur KISS (pas forcément stupide mais simple et lisible).


Il faut prendre ce qui marche simplement et fait avancer le truc de 
façon maîtrisée, exemple stacker plutôt que cascader les switches, ou 
mieux avec les VSS et autres virtual chassis on simplifie 
l'administration et on diminue le nombre de cerveaux mais on réfléchi un 
peu aux intercos quand même...


Car le software ne peut donner que ce qui existe au niveau hard, ok pour 
mixer une fibre FTTH avec un lien Sdsl dans un petit site distant 
(SD-WAN ?), par contre pas ok pour croire qu'un lien qui bagotte ou qui 
est sous-dimensionné fonctionnera mieux (juste je ne le verrai pas).


Coté utilisateurs j'ai aussi une réticence à proposer 
"any-to-any-as-you-want", l'interco L2 n'est pas une option généralisée 
(si besoin réel on monte un VPLS), à priori tout ce qui sort de 
l'étage/bâtiment est routé. Je veux dire que c'est pas parce que ça 
existe, ou que ça peut fonctionner qu'on doit le faire et le généraliser.


Côté serveurs on en gère un bon millier mais les fonctions sont 
regroupées pour limiter les licences par cœur (Oracle et consort) tout 
mettre à plat serait inutilement coûteux.


Je suis trop petit, jusqu'à preuve du contraire SDN c'est pas pour moi, 
parlez-moi plutôt de micro-switches pour FTTO (Cisco s'y met après 
NeXans et Microsens) ça a du sens d'arrêter le câblage cuivre des 
bâtiments de bureau 


Marc ABEL




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

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[Nang Bat]

Attention malheureux ! En 5g aussi faut tout racheter, le HLR (HSS en
LTE...) change encore de nom et devient UDM (+AUSF...) et c'est du
REST (avec des def openapi du genre
https://github.com/jdegre/5GC_APIs/blob/master/TS29503_Nudm_MT.yaml)
et la je te raconte pas le merdier quand tes users font 2/3/4/5G c'est
que du bonheur.

Le ven. 21 mai 2021 à 11:17, David Ponzone  a écrit :
>
> > Le 21 mai 2021 à 10:59, Xavier Beaudouin  a écrit :
> >
> > Après le jour où le machin se fracasse ou que la license est venue a 
> > expiration, on peux très vite sortir le camion a popcorn et attendre qu'on 
> > appelle un dino pour réparer le merdier.
>
> Oserais-je une comparaison (pas fonctionnelle) avec le HLR d’un réseau mobile 
> ? :)
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[David Ponzone]

> Le 21 mai 2021 à 10:59, Xavier Beaudouin  a écrit :
> 
> Après le jour où le machin se fracasse ou que la license est venue a 
> expiration, on peux très vite sortir le camion a popcorn et attendre qu'on 
> appelle un dino pour réparer le merdier.

Oserais-je une comparaison (pas fonctionnelle) avec le HLR d’un réseau mobile ? 
:)


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

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[aderumier]

Le jeudi 20 mai 2021 à 12:54 +0200, Cécile MORANGE a écrit :
> Hello la liste ! Je commence à me renseigner sur le SDN et je me suis
> dit que ce serait sympa d'écrire un article sur mon blog 
> (blog.ataxya.net) à propos de ça. Vu que sur internet je trouve
> beaucoup 
> plus de présentations commerciales que d'avis réels sur la solution,
> je 
> me suis dit que j'allais demander à mon groupe d'expert préféré ce
> qu'il 
> pense de cette techno. Mes questions sont donc : - Pourquoi passer au
> SDN ? - Il y a-t-il un réel intérêt de passer au SDN ? (Hormis
> l'aspect 
> commercial) - En avez-vous déjà mis en place ? Comment ça s'est passé
> ? 
> Avez-vous remarqué un réel changement dans la façon de faire vos
> réseaux 
> ? (et du gain de temps ?) - Pensez vous que dans 5,10,20 ans, tous
> les 
> réseaux seront du SDN ? Je suis à l'écoute de tous vos retours, ça me
> permettra de mieux comprendre le SDN et l'intérêt (s'il y en a un) !
> (Je sens que je vais lancer un long thread plein de débats :D)
> Merci d'avance !
> 
> Cordialement,
> 
Personnellement, l'intérêt que je vois,  c'est de pouvoir faire de
l'encapsulation (réseau overlay),
au dessus d'un autre réseau.

Quand tu commence à avoir un gros réseau, avec beaucoup d'hyperviseurs,
et plusieurs datacenters,  faire du layer2 partout (pour pouvoir migrer
les machines virtuelles entre les noeuds/baies/dc),
ca devient vite la merde.
du coup, layer3 bgp partout dans ton réseau underlay,  et au dessus tu
ajoute un réseau "sdn" qui s'occupe de gérer le réseau "virtuel" de tes
vms.  

normalement, dans un sdn, le controlplane (qui a la vu les mac/ips de
tes vms) est séparé du dataplane (les bridge/vswitchs de tes
hyperviseurs).  Le but du controller, c'est de pousser les mac dans la
fdb des bridges/vswitchs  VS un appretissage classique layer2 avec des
BUM.

certains sdn on des controllers centralisés (beurk), openflow, tout cas
 , d'autres décentralisés (openstack dragonflow, bgp-evpn ;).

Ensuite au dessus de ca, y'a pleins de briques de NFV (network virtual
function), en fonction de sdn, généralement ce sont des services qui
viennent se plugger dedans (firewall, loadblaancer,...). Généralement
ce sont des vms, et le sdn se démerde pour router les flux dans les
différents briques.


Perso, j'aime bien les standard et l'interopérabilité, du coup bgp-evpn
pour moi. (et l'intégration dans proxmox est dispo ;)


Alexandre








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

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[Pascal Romano via frnog]

On ne peut être plus clair !


> On 21 May 2021, at 10:59, Xavier Beaudouin  wrote:
> 
> Hello
> 
> Et pour avoir lu ce fil, je suis plutôt entre "c'est un nouveau truc" et 
> "mouais".
> 
> En résumé, il y a des gens qui cherchent des personnes ayant 5 ans d'expé sur 
> les techno cisco sdn (je ne sais plus quel produit et bon ... osef) et ça me 
> fait quand même un peu marrer vu la jeunesse du produit.
> 
> En gros le seul et unique problème de ces machins, c'est que ça fait ce qui 
> est prévu pour une marque X ou Y... Évidement l'interop n'est pas là. Si tu 
> tu veux du Cisco tu prends le produit truc et si tu veux du juniper tu prends 
> le produit truc.
> 
> D'après l'expérience que j'ai avec des gens qui l'utilise c'est que le soft a 
> décidé un certain nombre de choses qui simplifie bcp l'admin du reseau 
> (syndrôme du pousse bouton sans savoir ce qui se passe en dessous, chose que 
> les dino comme moi n'aime pas), mais... quand ça sort des rails de ce qui a 
> été prévu par le cahier de charges des dev du soft de SD-WAN, là c'est une 
> autre chose.
> 
> Après le jour où le machin se fracasse ou que la license est venue a 
> expiration, on peux très vite sortir le camion a popcorn et attendre qu'on 
> appelle un dino pour réparer le merdier.
> 
> Le cote gênant, c'est surtout le coté privateur de cette mode aka vendor 
> locked.
> Et on est bon nombre a râler vis a vis de leur pratiques commerciales qui 
> nous les brisent.
> 
> Pour l'instant je suis dans le wait and see... mais en tous cas dans la boite 
> où je bosse, le réseau est suffisamment en dehors de clous habituels pour ne 
> pas rentrer dans les cases SD-WAN...
> 
> Xavier
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[Xavier Beaudouin]

Hello

Et pour avoir lu ce fil, je suis plutôt entre "c'est un nouveau truc" et 
"mouais".

En résumé, il y a des gens qui cherchent des personnes ayant 5 ans d'expé sur 
les techno cisco sdn (je ne sais plus quel produit et bon ... osef) et ça me 
fait quand même un peu marrer vu la jeunesse du produit.

En gros le seul et unique problème de ces machins, c'est que ça fait ce qui est 
prévu pour une marque X ou Y... Évidement l'interop n'est pas là. Si tu tu veux 
du Cisco tu prends le produit truc et si tu veux du juniper tu prends le 
produit truc.

D'après l'expérience que j'ai avec des gens qui l'utilise c'est que le soft a 
décidé un certain nombre de choses qui simplifie bcp l'admin du reseau 
(syndrôme du pousse bouton sans savoir ce qui se passe en dessous, chose que 
les dino comme moi n'aime pas), mais... quand ça sort des rails de ce qui a été 
prévu par le cahier de charges des dev du soft de SD-WAN, là c'est une autre 
chose.

Après le jour où le machin se fracasse ou que la license est venue a 
expiration, on peux très vite sortir le camion a popcorn et attendre qu'on 
appelle un dino pour réparer le merdier.

Le cote gênant, c'est surtout le coté privateur de cette mode aka vendor locked.
Et on est bon nombre a râler vis a vis de leur pratiques commerciales qui nous 
les brisent.

Pour l'instant je suis dans le wait and see... mais en tous cas dans la boite 
où je bosse, le réseau est suffisamment en dehors de clous habituels pour ne 
pas rentrer dans les cases SD-WAN...

Xavier


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

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[aderumier]

Le vendredi 21 mai 2021 à 09:16 +0200, Nicolas Vuillermet a écrit :
> En cours, ce qu'on voit, c'est vraiment la centralisation (modulo la 
> possibilité de haute dispo) du controlplane.
> 
> Comme l'ont dit certains, la base est Openflow, qui ira faire 
> l'interface entre un contrôleur (des noms sont sortis, OpenDayLight, 
> Onos, OpenSack Neutron :troll:).

Personnelement, bgp-evpn c'est du sdn pour moi, et le control plane est
décentralisé (et pas d'openflow)




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

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[Vincent Habchi]

> On 21 May 2021, at 09:54, Gregory CAUCHIE  wrote:
> 
> Je ne pense pas avoir compris ton point.

Argh, les anglicismes :p

V.


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

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[Gregory CAUCHIE]

Erratum, "un nouveau paradigme d’exploitation" et non "un nouveau paradigme 
d’innovation", sorry

> Le 21 mai 2021 à 09:54, Gregory CAUCHIE  a écrit :
> 
> Salut Michel,
> 
>> Le 21 mai 2021 à 07:09, Michel Py  a 
>> écrit :
>> 
>> Je prétends pas être psy, mais dans les contribs de mes co-listiers, dont 
>> certains je me sens proche et d'autres carrément pas, j'ai lu toute la gamme 
>> entre "ras-le-bol" et "plein-les-c..."
>> Là ou ça devient intéressant, ce n'est pas les gens qui sont d'habitude 
>> d'accord avec moi, mais ceux avec qui je n'ai pas ou peu d'atomes crochus. 
>> Et dont certains, comme tu le dirais, on jeté le bébé avec l'eau du bain.
> 
> Je ne pense pas avoir compris ton point.
> 
> 
>> Le problème que j'ai avec SDN (plus du coté sysadmin) et SD-WAN (plus du 
>> coté netadmin) c'est que en fait, ça n'existe pas. Aucune innovation, que 
>> des technologies qui existaient bien avant que le marketing n'invente le 
>> nouveau buzzword à la mode, bref c'est un ramassis de conneries
> 
> Pour avoir fait sur le terrain pas mal d’années de pousse paquet, plusieurs 
> années de "SDN" et un peu d’années de SD-WAN, je ne peux qu’être en désaccord 
> sur le fait que ça n’existe pas. 
> Le SDN n’est pas forcément qu’une histoire pour les sysadmin faisant de 
> l’hébergement voire avec du cloud par-dessus. Ça se décline aussi sur le 
> pousse-paquet des familles.
> Le SD-WAN n’est pas essentiel, le routage dynamique non plus après tout, je 
> ne compte plus le nombre de réseaux d’ETI en routage statique. C’est juste 
> une histoire classique de complexité à opérer, d’impact ou non sur le 
> business et de sous-sous. Dans le cas du SD-WAN, si t’as une problématique de 
> bande-passante et de priorisation de flux que DSCP seul ne peux gérer (pour x 
> raisons), tu peux soit payer un x10 de bande-passante et souvent ne pas voir 
> d’amélioration (vu chez des clients), soit te monter tout seul ton mélange de 
> VPN, de DPI et de routage sur la base de qualité de transport de tes tunnels 
> (beau challenge), soit prendre le produit packagé sous label SD-WAN. 
> 
> Quant à l’innovation, je pense qu’on a aussi ici une problématique de 
> définition. À partir de quel moment une solution est-elle innovante ? quel 
> seuil pour parler de « révolution" ? MPLS a eu un énorme impact sur 
> l’industrie et pourtant la base du protocole n’est que mélange des 
> caractéristiques de datagramme IP et de circuit ATM/Frame Relay/ Le VLAN 
> a permis d’énormément rationaliser la taille des infra sans pour autant 
> changer la technique de commutation. Les VPN, GRE et autres VxLAN sont tous 
> des techniques de tunnelisation/overlay comme un VLAN au dessus d’une infra 
> mutualisée. Arpanet s’est monté en overlay des réseaux de l’époque, donc pas 
> nouveau et pourtant chaque VPN a eu son propre impact (site distant, 
> extension de LAN entre DC, …) . 
> Bref à chaque fois on met plusieurs trucs dans une même boîte pour diminuer 
> (pas supprimer, juste baisser) la complexité de gestion et le TCO. Donc à 
> voir où se placer entre d’un côté « pas d'innovation depuis l’apparition du 
> datagramme IP » et de l’autre « SD-WAN apporte un nouveau paradigme 
> d’innovation ». 
> 
> —
> Grégory


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

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[Gregory CAUCHIE]

Salut Michel,

> Le 21 mai 2021 à 07:09, Michel Py  a 
> écrit :
> 
> Je prétends pas être psy, mais dans les contribs de mes co-listiers, dont 
> certains je me sens proche et d'autres carrément pas, j'ai lu toute la gamme 
> entre "ras-le-bol" et "plein-les-c..."
> Là ou ça devient intéressant, ce n'est pas les gens qui sont d'habitude 
> d'accord avec moi, mais ceux avec qui je n'ai pas ou peu d'atomes crochus. Et 
> dont certains, comme tu le dirais, on jeté le bébé avec l'eau du bain.

Je ne pense pas avoir compris ton point.


> Le problème que j'ai avec SDN (plus du coté sysadmin) et SD-WAN (plus du coté 
> netadmin) c'est que en fait, ça n'existe pas. Aucune innovation, que des 
> technologies qui existaient bien avant que le marketing n'invente le nouveau 
> buzzword à la mode, bref c'est un ramassis de conneries

Pour avoir fait sur le terrain pas mal d’années de pousse paquet, plusieurs 
années de "SDN" et un peu d’années de SD-WAN, je ne peux qu’être en désaccord 
sur le fait que ça n’existe pas. 
Le SDN n’est pas forcément qu’une histoire pour les sysadmin faisant de 
l’hébergement voire avec du cloud par-dessus. Ça se décline aussi sur le 
pousse-paquet des familles.
Le SD-WAN n’est pas essentiel, le routage dynamique non plus après tout, je ne 
compte plus le nombre de réseaux d’ETI en routage statique. C’est juste une 
histoire classique de complexité à opérer, d’impact ou non sur le business et 
de sous-sous. Dans le cas du SD-WAN, si t’as une problématique de 
bande-passante et de priorisation de flux que DSCP seul ne peux gérer (pour x 
raisons), tu peux soit payer un x10 de bande-passante et souvent ne pas voir 
d’amélioration (vu chez des clients), soit te monter tout seul ton mélange de 
VPN, de DPI et de routage sur la base de qualité de transport de tes tunnels 
(beau challenge), soit prendre le produit packagé sous label SD-WAN. 

Quant à l’innovation, je pense qu’on a aussi ici une problématique de 
définition. À partir de quel moment une solution est-elle innovante ? quel 
seuil pour parler de « révolution" ? MPLS a eu un énorme impact sur l’industrie 
et pourtant la base du protocole n’est que mélange des caractéristiques de 
datagramme IP et de circuit ATM/Frame Relay/ Le VLAN a permis d’énormément 
rationaliser la taille des infra sans pour autant changer la technique de 
commutation. Les VPN, GRE et autres VxLAN sont tous des techniques de 
tunnelisation/overlay comme un VLAN au dessus d’une infra mutualisée. Arpanet 
s’est monté en overlay des réseaux de l’époque, donc pas nouveau et pourtant 
chaque VPN a eu son propre impact (site distant, extension de LAN entre DC, …) 
. 
Bref à chaque fois on met plusieurs trucs dans une même boîte pour diminuer 
(pas supprimer, juste baisser) la complexité de gestion et le TCO. Donc à voir 
où se placer entre d’un côté « pas d'innovation depuis l’apparition du 
datagramme IP » et de l’autre « SD-WAN apporte un nouveau paradigme 
d’innovation ». 

—
Grégory

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

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[Nang Bat]

Pour les ROADM, oui après faut avoir le besoin et puis en plus les
dernières génération de ROADM sont "flexgrid" pour prendre des
channels de largeurs variable. Après de ce que j'ai vu en prod c'est
pour du très gros CSP, peut-être des telco je sais pas.
Sinon les histoire d'API northbound, depuis qu'on a telnet j'ai vu des
gens faire du expect avec du perl ça compte :D
La ou j'admet qu'on peut percevoir un changement dans les équipements
c'est le moment ou tu peux taper la RIB en direct avec des truc genre
openconfig/gribi la on peut commencer à avoir des soft qui font des
trucs sympa. En presque off-topic c'est le genre de logique qu'on
retrouve sur au moins une constellation de satellite pour le
broadband: synthétiser les RIB (avec des LFA etc.) de tout les
satellites au sol (vu que tu connais la topologie du reseau en avance)
et les dispatcher au fil du temps, ca permet de supprimer complètement
la décision locale, ce qui est impossible tant qu'il reste un bout
d'igp/bgp qui tourne sur les équipements.

Le ven. 21 mai 2021 à 09:25, Remi Desgrange
 a écrit :
>
> Moi avec l'émergence du "edge computing" (aka, "le pc dans le placard, mais
> géré par un cloud provider") j'attends le "SDN At The Edge" :-)
>
> Tiens est-ce que les ROADM c'est du SDN ? Est-ce que des gens utilise ça en
> vrais ?
>
> On Fri, May 21, 2021 at 9:18 AM Nicolas Vuillermet 
> wrote:
>
> > SDN, bullshit pour ceux qui ont pas pigé l'idée ?
> >
> > En cours, ce qu'on voit, c'est vraiment la centralisation (modulo la
> > possibilité de haute dispo) du controlplane.
> >
> > Comme l'ont dit certains, la base est Openflow, qui ira faire
> > l'interface entre un contrôleur (des noms sont sortis, OpenDayLight,
> > Onos, OpenSack Neutron :troll:).
> >
> > Dans le fond, ça va faire plusieurs choses.
> >
> > Déjà pousser les confs (on en a fait que niveau L2) vers une
> > hétéréogénéité d'équipements, bien suivant le contrôleur expose une API
> > Northbound.
> >
> > L'autre point qu'on a vu en cours, c'est le routage L2. Oui oui oui oui,
> > personne n'a rien compris quand la prof en a parlé, et maintenant la
> > moitié de la promo confond routage et commutation.
> > Mais bon, l'idée sous-jacente est la possibilité de ne plus avoir des
> > dumb-switch au niveau ARP, mais qu'à chaque nécessité de remplir la
> > table ARP, que les switchs du réseau SDN aillent demander au contrôleur
> > où se trouvent l'adresse. Dans certains cas, c'est tout le paquet qui
> > rentre dans le réseau SDN qui est envoyé au contrôleur pour analyse et
> > décision. Les paquets suivants respecteront par la suite la décision du
> > contrôleur (c'est du ARP managé en gros ? c'est ce que j'ai retenu).
> >
> > Pour ce point je trouve un sacré avantage : pour une infra DC, tu
> > automatises l'emplacement des @MAC sur les switchs, du coup tu filtres
> > niveau MAC, c'est sympa je trouve.
> > On a vu des choses amusantes du genre couplage 802.1x avec contrôleur
> > SDN...
> >
> > Bref :) C'est cool, mais pas tout le temps en a la nécessité.
> >
> > 'dredi morning
> >
> > Le 20/05/2021 à 20:31, Vincent Habchi a écrit :
> > >> On 20 May 2021, at 19:18, Toussaint OTTAVI  wrote:
> > >>
> > >>
> > >> Le 20/05/2021 à 15:04, Pierre DOLIDON a écrit :
> > >>> Si je résume, SDN est au réseau ce que Cloud est à l'hébergement ?
> > >> J'allais le dire, mais tu m'as coupé l'herbe sous le pied :-)
> > > Un jour, le groupe Accor lancera une nouvelle chaîne d’hôtels appelés «
> > Cloud » et le slogan sera « les spécialistes de l’hébergement ».
> > >
> > > Bon, je sors … … …
> > >
> > > V.
> > >
> > >
> > > ---
> > > Liste de diffusion du FRnOG
> > > http://www.frnog.org/
> >
> >
> > ---
> > Liste de diffusion du FRnOG
> > http://www.frnog.org/
> >
>
>
> --
> Cordialement, Rémi Desgrange
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[David Ponzone]

Chouette, une bataille d’acronyme.
Et je crois que j’en ai un qui a été oublié……le vCPE!
Et le uCPE aussi.

Un bel article de 2019 bien bullshit avec des prospectives faites en 2015:
https://blogdigital.beijaflore.com/vcpe-virtualisation-reseaux/ 


> Le 21 mai 2021 à 09:22, Remi Desgrange  a 
> écrit :
> 
> Moi avec l'émergence du "edge computing" (aka, "le pc dans le placard, mais
> géré par un cloud provider") j'attends le "SDN At The Edge" :-)
> 
> Tiens est-ce que les ROADM c'est du SDN ? Est-ce que des gens utilise ça en
> vrais ?
> 
> On Fri, May 21, 2021 at 9:18 AM Nicolas Vuillermet 
> wrote:
> 


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

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[Benoit Chesneau]

On Fri, May 21, 2021 at 09:22, Remi Desgrange  
wrote:

> Moi avec l'émergence du "edge computing" (aka, "le pc dans le placard, mais
> géré par un cloud provider") j'attends le "SDN At The Edge" :-)

cela s’appelle azure stack hci…

> Tiens est-ce que les ROADM c'est du SDN ? Est-ce que des gens utilise ça en
> vrais ?
>
> On Fri, May 21, 2021 at 9:18 AM Nicolas Vuillermet 
> wrote:
>
>> SDN, bullshit pour ceux qui ont pas pigé l'idée ?
>>
>> En cours, ce qu'on voit, c'est vraiment la centralisation (modulo la
>> possibilité de haute dispo) du controlplane.
>>
>> Comme l'ont dit certains, la base est Openflow, qui ira faire
>> l'interface entre un contrôleur (des noms sont sortis, OpenDayLight,
>> Onos, OpenSack Neutron :troll:).
>>
>> Dans le fond, ça va faire plusieurs choses.
>>
>> Déjà pousser les confs (on en a fait que niveau L2) vers une
>> hétéréogénéité d'équipements, bien suivant le contrôleur expose une API
>> Northbound.
>>
>> L'autre point qu'on a vu en cours, c'est le routage L2. Oui oui oui oui,
>> personne n'a rien compris quand la prof en a parlé, et maintenant la
>> moitié de la promo confond routage et commutation.
>> Mais bon, l'idée sous-jacente est la possibilité de ne plus avoir des
>> dumb-switch au niveau ARP, mais qu'à chaque nécessité de remplir la
>> table ARP, que les switchs du réseau SDN aillent demander au contrôleur
>> où se trouvent l'adresse. Dans certains cas, c'est tout le paquet qui
>> rentre dans le réseau SDN qui est envoyé au contrôleur pour analyse et
>> décision. Les paquets suivants respecteront par la suite la décision du
>> contrôleur (c'est du ARP managé en gros ? c'est ce que j'ai retenu).
>>
>> Pour ce point je trouve un sacré avantage : pour une infra DC, tu
>> automatises l'emplacement des @MAC sur les switchs, du coup tu filtres
>> niveau MAC, c'est sympa je trouve.
>> On a vu des choses amusantes du genre couplage 802.1x avec contrôleur
>> SDN...
>>
>> Bref :) C'est cool, mais pas tout le temps en a la nécessité.
>>
>> 'dredi morning
>>
>> Le 20/05/2021 à 20:31, Vincent Habchi a écrit :
>> >> On 20 May 2021, at 19:18, Toussaint OTTAVI  wrote:
>> >>
>> >>
>> >> Le 20/05/2021 à 15:04, Pierre DOLIDON a écrit :
>> >>> Si je résume, SDN est au réseau ce que Cloud est à l'hébergement ?
>> >> J'allais le dire, mais tu m'as coupé l'herbe sous le pied :-)
>> > Un jour, le groupe Accor lancera une nouvelle chaîne d’hôtels appelés «
>> Cloud » et le slogan sera « les spécialistes de l’hébergement ».
>> >
>> > Bon, je sors … … …
>> >
>> > V.
>> >
>> >
>> > ---
>> > Liste de diffusion du FRnOG
>> > http://www.frnog.org/
>>
>>
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
>>
>
> --
> Cordialement, Rémi Desgrange
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[Remi Desgrange]

Moi avec l'émergence du "edge computing" (aka, "le pc dans le placard, mais
géré par un cloud provider") j'attends le "SDN At The Edge" :-)

Tiens est-ce que les ROADM c'est du SDN ? Est-ce que des gens utilise ça en
vrais ?

On Fri, May 21, 2021 at 9:18 AM Nicolas Vuillermet 
wrote:

> SDN, bullshit pour ceux qui ont pas pigé l'idée ?
>
> En cours, ce qu'on voit, c'est vraiment la centralisation (modulo la
> possibilité de haute dispo) du controlplane.
>
> Comme l'ont dit certains, la base est Openflow, qui ira faire
> l'interface entre un contrôleur (des noms sont sortis, OpenDayLight,
> Onos, OpenSack Neutron :troll:).
>
> Dans le fond, ça va faire plusieurs choses.
>
> Déjà pousser les confs (on en a fait que niveau L2) vers une
> hétéréogénéité d'équipements, bien suivant le contrôleur expose une API
> Northbound.
>
> L'autre point qu'on a vu en cours, c'est le routage L2. Oui oui oui oui,
> personne n'a rien compris quand la prof en a parlé, et maintenant la
> moitié de la promo confond routage et commutation.
> Mais bon, l'idée sous-jacente est la possibilité de ne plus avoir des
> dumb-switch au niveau ARP, mais qu'à chaque nécessité de remplir la
> table ARP, que les switchs du réseau SDN aillent demander au contrôleur
> où se trouvent l'adresse. Dans certains cas, c'est tout le paquet qui
> rentre dans le réseau SDN qui est envoyé au contrôleur pour analyse et
> décision. Les paquets suivants respecteront par la suite la décision du
> contrôleur (c'est du ARP managé en gros ? c'est ce que j'ai retenu).
>
> Pour ce point je trouve un sacré avantage : pour une infra DC, tu
> automatises l'emplacement des @MAC sur les switchs, du coup tu filtres
> niveau MAC, c'est sympa je trouve.
> On a vu des choses amusantes du genre couplage 802.1x avec contrôleur
> SDN...
>
> Bref :) C'est cool, mais pas tout le temps en a la nécessité.
>
> 'dredi morning
>
> Le 20/05/2021 à 20:31, Vincent Habchi a écrit :
> >> On 20 May 2021, at 19:18, Toussaint OTTAVI  wrote:
> >>
> >>
> >> Le 20/05/2021 à 15:04, Pierre DOLIDON a écrit :
> >>> Si je résume, SDN est au réseau ce que Cloud est à l'hébergement ?
> >> J'allais le dire, mais tu m'as coupé l'herbe sous le pied :-)
> > Un jour, le groupe Accor lancera une nouvelle chaîne d’hôtels appelés «
> Cloud » et le slogan sera « les spécialistes de l’hébergement ».
> >
> > Bon, je sors … … …
> >
> > V.
> >
> >
> > ---
> > Liste de diffusion du FRnOG
> > http://www.frnog.org/
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>


-- 
Cordialement, Rémi Desgrange

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

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[Nicolas Vuillermet]

SDN, bullshit pour ceux qui ont pas pigé l'idée ?

En cours, ce qu'on voit, c'est vraiment la centralisation (modulo la 
possibilité de haute dispo) du controlplane.


Comme l'ont dit certains, la base est Openflow, qui ira faire 
l'interface entre un contrôleur (des noms sont sortis, OpenDayLight, 
Onos, OpenSack Neutron :troll:).


Dans le fond, ça va faire plusieurs choses.

Déjà pousser les confs (on en a fait que niveau L2) vers une 
hétéréogénéité d'équipements, bien suivant le contrôleur expose une API 
Northbound.


L'autre point qu'on a vu en cours, c'est le routage L2. Oui oui oui oui, 
personne n'a rien compris quand la prof en a parlé, et maintenant la 
moitié de la promo confond routage et commutation.
Mais bon, l'idée sous-jacente est la possibilité de ne plus avoir des 
dumb-switch au niveau ARP, mais qu'à chaque nécessité de remplir la 
table ARP, que les switchs du réseau SDN aillent demander au contrôleur 
où se trouvent l'adresse. Dans certains cas, c'est tout le paquet qui 
rentre dans le réseau SDN qui est envoyé au contrôleur pour analyse et 
décision. Les paquets suivants respecteront par la suite la décision du 
contrôleur (c'est du ARP managé en gros ? c'est ce que j'ai retenu).


Pour ce point je trouve un sacré avantage : pour une infra DC, tu 
automatises l'emplacement des @MAC sur les switchs, du coup tu filtres 
niveau MAC, c'est sympa je trouve.
On a vu des choses amusantes du genre couplage 802.1x avec contrôleur 
SDN...


Bref :) C'est cool, mais pas tout le temps en a la nécessité.

'dredi morning

Le 20/05/2021 à 20:31, Vincent Habchi a écrit :

On 20 May 2021, at 19:18, Toussaint OTTAVI  wrote:


Le 20/05/2021 à 15:04, Pierre DOLIDON a écrit :

Si je résume, SDN est au réseau ce que Cloud est à l'hébergement ?

J'allais le dire, mais tu m'as coupé l'herbe sous le pied :-)

Un jour, le groupe Accor lancera une nouvelle chaîne d’hôtels appelés « Cloud » 
et le slogan sera « les spécialistes de l’hébergement ».

Bon, je sors … … …

V.


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



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

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[Jean-Francois Billaud via frnog]

On 21/05/2021 07:09, Michel Py via frnog wrote:

> Question pour Cécile : quand on est une nana, comment on dit "plein les 
> couilles" ?

Les autres aussi peuvent répondre ?

GONADE, subst. fém.
BIOL. Glande génitale qui produit les gamètes et sécrète des hormones 
sexuelles. Gonade femelle (synon. ovaire), gonade mâle (synon. testicule).

Donc gonadoclaste = qui casse les gonades

et gonadoclastophobe = qui n'aime pas les gonadoclastes.


JFB (inclusif gonadoclastophobe ampélidophile xyloglotte)


PS https://www.cledut.net/xylo.htm

-- 
   __  _
   .-.'  `; `-._  __  _
  (_, .-:'  `; `-._
,'o"((_,   )
   (__,-'  ,'o"()>
  (   (__,-')
   `-'._.--._( )
  |||  |||`-'._.--._.-'
 |||  |||
(Bob Allison)


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

RE: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[Michel Py via frnog]

> Gregory CAUCHIE a écrit :
> Je suis étonné que vous jettiez tous le bébé avec l’eau du bain.

Je prétends pas être psy, mais dans les contribs de mes co-listiers, dont 
certains je me sens proche et d'autres carrément pas, j'ai lu toute la gamme 
entre "ras-le-bol" et "plein-les-c..."
Là ou ça devient intéressant, ce n'est pas les gens qui sont d'habitude 
d'accord avec moi, mais ceux avec qui je n'ai pas ou peu d'atomes crochus. Et 
dont certains, comme tu le dirais, on jeté le bébé avec l'eau du bain.

> Après dire que cloud et hébergement sont pareils

Pour rendre le troll intéressant, ceci n'est pas vraiment ma partie. Je 
m'occupe plus de la partie "réseau" dans le genre "pousse-paquet" que de la 
partie "hébergement" dans le genre "pousse-requête-web".
N'étant pas complètement étranger au problème, je comprends parfaitement les 
gens qui comparent "cloud" et "hébergement". Ils ont le même problème que moi 
avec "SD-WAN" et "réseau".

J'en ai plein les couilles de perdre mon temps avec les pousseurs de propale et 
les vendeurs de pompes usées qui essaient de me vendre du "cloud", du "SDN", du 
"SD-WAN", et autres.

Question pour Cécile : quand on est une nana, comment on dit "plein les 
couilles" ?
Mon boss et le boss de mon boss sont des mecs, mais "Senior Vice President" est 
une meuf, et j'ai absolument aucun problème avec ça. Elle en a une paire. Pas 
au même endroit que moi :P
Faut assumer, c'est toi qui a ouvert le fil.

Le problème que j'ai avec SDN (plus du coté sysadmin) et SD-WAN (plus du coté 
netadmin) c'est que en fait, ça n'existe pas. Aucune innovation, que des 
technologies qui existaient bien avant que le marketing n'invente le nouveau 
buzzword à la mode, bref c'est un ramassis de conneries, un fourre-tout ou on 
met tout et n'importe-quoi dedans en bordel couvré, et que j'en ai plein les 
coui^H^H^H^H^Hnibbards de gaspiller mon temps avec les bit^H^H^Hchattes 
auxquelles tu donnes une adresse IP de 321.192.168.1 et qui vont joyeusement 
passer ça à leur "ingénieur" réseau.


> Fabien VINCENT a écrit :
> Mon point de vue trollesque est : SDN c'est Still Does Nothing.

J'ai plussoyé hier et je plussoie encore.

> Moi je travaille sur du RDN, Real Defined Network :p

:-D


> Tu trouveras personne qui a la même définition du SDN parce que ca ne
> représente rien de manière unitaire technologiquement parlant.

On est bien d'accord. Un terme fourre-tout marketing, destiné aux politiciens 
qui n'ont ni couilles ni nichons ni cervelle et dont la mémoire à court-terme 
ne contient que 2 ou trois "buzzwords".

La mémoire collective de cette liste se rappellera, d'ailleurs, que d'être une 
grosse légume, y compris Secrétaire d'Etat, ne garantie ni la sécurité de 
l'emploi, ni le parachute doré, et surtout pas la sympathie sans même évoquer 
l'idée d'aide des requins avec qui on a cru nager dans la même piscine pendant 
quelques malheureuses semaines.

Michel.


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

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[Gregory CAUCHIE]

Je suis étonné que vous jettiez tous le bébé avec l’eau du bain.

SDN a vu sa définition évolué dans le temps, d’abord uniquement autour de 
l’OpenFlow, comme évoqué précédemment par Rémi Desgrange, puis l’IETF et 
d’autres s’en sont aussi emparé sur la base qu'en gros ’software’ n’était pas 
obligé de se limiter à OpenFlow et que d’autres techno pouvaient aussi rentrer 
dans un cadre de "mise en place" par le software… sauf qu’au final on ne défini 
jamais de quelle gestion/définition/mise en place on traite exactement.

Pour ma part, je vois le SDN comme une application pour le réseau des concepts 
de CI/CD et d’infrastructure as Code. L’intérêt selon moi est la possibilité de 
valider son ingénierie sur du quasi iso-prod, systématiser les tests de non 
régression et garantir une reproductibilité (évoquée aussi par Xavier Claude) 
des états du réseau (avec le concept immutable, vs. snowflake). Bref faire sur 
le réseau ce que l’on fait avec les applications, i.e. après *beaucoup* de 
boulot, avoir un rythme d’évolution et une qualité de mise en prod 
incomparable, mais à la différence que les clouds ne peuvent pas être utilisés 
pour le pur LAN/WAN et que l’on doit donc se tourner vers d’autres types de 
solution. Du moins moi et mes précédentes équipes n’avons jamais réussi à faire 
passer des protocoles utilisant du broadcast/multicast (LLDP, Hello IGP, …) sur 
de l’OpenStack/DevStack et consoeurs.

Après dire que cloud et hébergement sont pareils, c’est pour moi ne pas avoir 
compris la différence en termes d’expérience client. Je n’ai jamais vu 
d’entreprise offre une mise en place d’un setup d’infra réseau/serveur/stockage 
en moins de plusieurs jours après la première formulation du besoin du client 
(et je suis très très gentil), alors qu’avec le cloud ça se fait dans le quart 
d’heure sans l’aide de terraform.

Quant à SDWAN… c’est pas du bullshit mais un plus grand fourre-tout, avec plus 
ou moins de capacité des API pour le SDN, plus ou moins d’orchestration des 
outils propriétaires, plus ou moins de sécurité (firewall, IPS/IDS, anti-spam, 
anti-malware, …), plus ou moins de DPI pour la reconnaissance des applis, plus 
ou moins de capacité à superviser la qualité des différents tunnels VPN, plus 
ou moins de capacité de routage/switching (VRF, NAT, BGP, IGP, …), etc. Et je 
suis d’ailleurs étonné que personne n’ai lâché le mot SASE pour crier encore 
plus au bullshit.

Ne me faites pas dire enfin qu’il n’y a aucun marketing là-dedans. Je reviens 
sur la formule de départ, ne jetons pas le bébé avec l’eau du bain. Il y a un 
peu de bon grain dans tout cela.

--
Grégory

> Le 20 mai 2021 à 20:31, Vincent Habchi  a écrit :
> 
>> On 20 May 2021, at 19:18, Toussaint OTTAVI  wrote:
>> 
>> 
>> Le 20/05/2021 à 15:04, Pierre DOLIDON a écrit :
>>> Si je résume, SDN est au réseau ce que Cloud est à l'hébergement ? 
>> 
>> J'allais le dire, mais tu m'as coupé l'herbe sous le pied :-)
> 
> Un jour, le groupe Accor lancera une nouvelle chaîne d’hôtels appelés « Cloud 
> » et le slogan sera « les spécialistes de l’hébergement ».
> 
> Bon, je sors … … …
> 
> V.
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[Vincent Habchi]

> On 20 May 2021, at 19:18, Toussaint OTTAVI  wrote:
> 
> 
> Le 20/05/2021 à 15:04, Pierre DOLIDON a écrit :
>> Si je résume, SDN est au réseau ce que Cloud est à l'hébergement ? 
> 
> J'allais le dire, mais tu m'as coupé l'herbe sous le pied :-)

Un jour, le groupe Accor lancera une nouvelle chaîne d’hôtels appelés « Cloud » 
et le slogan sera « les spécialistes de l’hébergement ».

Bon, je sors … … …

V.


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

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[Toussaint OTTAVI]

Le 20/05/2021 à 15:04, Pierre DOLIDON a écrit :
Si je résume, SDN est au réseau ce que Cloud est à l'hébergement ? 


J'allais le dire, mais tu m'as coupé l'herbe sous le pied :-)



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

RE: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[Michel Py via frnog]

> Cécile MORANGE a écrit :
> Vu que sur internet je trouve beaucoup plus de présentations commerciales que 
> d'avis réels sur la solution,

Pas étonnant ;-)

SDN et en particulier SD-WAN, c'est un terme fourre-tout marketing. C'est une 
solution qui cherche un problème, basée sur des technologies qui n'ont rien de 
nouveau. C'est un mélange savant de cloud, de QOS, de VPN et de scripts destiné 
aux décideurs incompétents. On noie le poisson et au passage on vend une 
license supplémentaire.

En fait, voici un site qui décrit très bien ce concept :
https://poudreverte.org/


> David Ponzone a écrit :
> Si on élargit au coeur de réseau, on reste dans un bon bullshit non ?

Oui et en plus d'être du bullshit c'est dangereux, parce qu'on fournit parfois 
un clickodrome à un abruti qui n'y comprend rien et qui ne devrait pas y 
toucher.

> Des confs de routeurs poussées par Ansible, c’est du SDN ou pas ?

Hmmm, j'aurais tendance à dire pas vraiment. Ca n'existait pas avant que 
l'acronyme SDN soit inventé ?


> Pierre Colombier a écrit :
> J'avoue que je n'ai toujours pas compris ce dont il s'agissait.

T'inquiète pas, nous non plus :P

> soit c'est une boite noire magique qui fait tout automagiquement et c'est donc
> casse-gueule : Quels leviers reste-t-il quand la magie n'opère pas ?

+1

> Julien a écrit :
> parce que la dernière fois que j'ai parlé de MPLS, on ma répondu avec mépris 
> : "Pfff, mpls c'est has-been,
> nous on fait du *SD-WAN* maintenant". Et après m'être renseigné ben en 
> fait j'ai pas tellement vu de
> différence entre un "SD-WAN" et un tinc :-/ , hormis le fait que c'était 
> vendu hors de prix par un
> intégrateur, qu'il y avait parfois un clickodrome et qu'on y perdait toute 
> notion de GTR ou de QoS.

+1 


> Pierre DOLIDON a écrit :
> Si je résume, SDN est au réseau ce que Cloud est à l'hébergement ?

L'obscurantisme en plus.


> Fabien VINCENT a écrit :
> Mon point de vue trollesque est : SDN c'est Still Does Nothing.

:-D

Michel.


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

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[Radu-Adrian Feurdean]

On Thu, May 20, 2021, at 13:09, Hugues Voiturier wrote:
> C’est pas plutôt SD-WAN ça ?

SD-WAN = SDN pour le WAN


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

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[Benjamin Phạm-Bachelart]

 Hello,

Je sais qu'au moins 3 opérateurs utilisent la solution cisco NSO
(anciennement tail-f)
https://www.cisco.com/c/en/us/products/cloud-systems-management/network-services-orchestrator/index.html
, je suppose que tout le monde ne considérera pas ça comme du SDN, mais je
me permets un petit retour,
c'est vendu comme un orchestrateur de service, qui stocke localement une
copie synchronisé de toutes les configurations des équipements que l'on
souhaite gérer, pour avoir travaillé dessus, je vois ça comme en quelque
sorte un framework qui te permet de décrire (en yang) et de développer (en
Java, ou Python) des services. Les conf poussées sont gérés sous forme de
template xml.

La solution propose en plus des couches d'abstraction d'équipements (cela
peut être quasiment n'importe quoi, des VM, des équipements réels, des
serveurs linux..., que l'on peut - d'ailleurs - développer soi-même). En
gros les templates xml utilisés par NSO seront passés dans la moulinette
NED (*Network Element Driver*) pour être transformés en format de
configuration natif, la solution ajoute aussi du transactionnel afin de
permettre des rollbacks en cas de soucis même si cela n'est pas géré
nativement par l'équipement que l'on souhaite configurer.

Pour l'équipe qui va pousser de la configuration, au lieu de pousser
nativement des configs, spécifiques à chaque type de
fournisseur/équipement/CLI, du coup on a une espèce de couche haute
uniforme pour un même service, la promesse en gros, pour pousser un vlan,
que ce soit du juniper, nokia, cisco, ou du linux, la personne qui voudra
configurer pourra juste pousser sur le cli NSO "service vlan 1337 device
interface", ou faire de même via API RESTful/Netconf. Donc un vrai plus du
point de vue des personnes qui seront utilisatrices.

Bien entendu, cela demande un effort considérable au niveau de
développement de service, vu que la complexité doit se gérer au niveau du
code/des différents templates, bien qu'il existe des NED qui promettent une
couche d'abstraction du langage natif de l'équipement, chaque format de
template xml d'un NED (couche "basse" NSO) a son propre format, en gros le
format de template d'un ios-xr, ios-xe, junos, sr-os sera très différent.
Et c'est dans les services que doivent se faire traiter les différents cas.
Et comme dans tout ce qui est automatisation, il est simple de gérer des
cas courants/si notre parc est homogène/si notre besoin est standard, mais
difficile de traiter de nombreux différents cas spécifiques.
Et nombreux sont les cas où les NED manquent encore de fonctionnalités ou
ne fonctionnent pas comme attendus, et donc il faut demander des
évols/corrections. L'effort de développement est non-négligeable, mais si
le service développé et les NED sont stables, cela offre un gain de temps
réel sur les cas d'usage courants et standards.

Au delà de l'aspect configuration uniquement, il est possible de développer
des services qui permettent d'interroger les différents équipements gérés
sur leurs états (je pense surtout à des choses comme des tables de routage,
état des interfaces, etc), et il est donc possible - par exemple - de
développer un service qui permet d'interroger la table bgp d'équipements de
différents fournisseurs, et de rendre cela uniforme et accessible via l'API
de la solution.

Cdlt,

On Thu, May 20, 2021 at 12:56 PM Cécile MORANGE 
wrote:

> Hello la liste ! Je commence à me renseigner sur le SDN et je me suis
> dit que ce serait sympa d'écrire un article sur mon blog
> (blog.ataxya.net) à propos de ça. Vu que sur internet je trouve beaucoup
> plus de présentations commerciales que d'avis réels sur la solution, je
> me suis dit que j'allais demander à mon groupe d'expert préféré ce qu'il
> pense de cette techno. Mes questions sont donc : - Pourquoi passer au
> SDN ? - Il y a-t-il un réel intérêt de passer au SDN ? (Hormis l'aspect
> commercial) - En avez-vous déjà mis en place ? Comment ça s'est passé ?
> Avez-vous remarqué un réel changement dans la façon de faire vos réseaux
> ? (et du gain de temps ?) - Pensez vous que dans 5,10,20 ans, tous les
> réseaux seront du SDN ? Je suis à l'écoute de tous vos retours, ça me
> permettra de mieux comprendre le SDN et l'intérêt (s'il y en a un) !
> (Je sens que je vais lancer un long thread plein de débats :D)
> Merci d'avance !
>
> Cordialement,
>
> --
> Cécile MORANGE
> cont...@cecilemorange.fr
> ataxya.net
> @AtaxyaNetwork
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[Pierre DOLIDON]

Si je résume, SDN est au réseau ce que Cloud est à l'hébergement ?



Le 20/05/2021 à 14:55, Fabien VINCENT FrNOG via frnog a écrit :

Bonjour,

Wikipedia non ? Pour éviter de lancer une trollchain :D

<...>
C'est un ensemble de technologies ayant comme points communs :
1. un contrôle centralisé des ressources réseau ;
2. une orchestration centralisée ;
3. une virtualisation des ressources physiques.
<...>

Le 2 a déjà été évoqué (ansible, automation tout ca tout ca). Le 3, 
tout le monde le voit tous les jours, bye bye le HW chiant, vive les 
VMs, les dockers les k8s. (bon ca tourne toujours sur un proc qui 
n'est pas quantique mais c'est abstrait c'est déjà ca)


Le 1 par contre c'est le truc le plus touchy et fourre tout. On te 
vend du SDx pour tout et n'importe quoi. En vrai, y a un vrai sujet de 
centralisation du control plane (voir du côté d'OpenFlow, de 
OpenDaylight, des technos comme SR ou des RR out of the path pour 
BGP). Bref, c'est plutôt un changement de paradigme du réseau dans la 
gestion de son controle plane de manière + centralisé. Il y a aussi le 
sujet de la désagrégation avec la séparation du HW et du SW avec les 
whitebox (Sonic ou même les constructeurs comme Arista/Nokia qui 
vendent des SW now sur du HW tier)


Donc pour moi SDN ca veut "rien dire". Parce que c'est un ensemble de 
technos que les marketeux ne comprendront pas ;) Et on peut pas leur 
en vouloir ! Heureusement ca n'a jamais remplacé le métier d'ingé' 
réseau ;) Voir même ca l'a renforcé ! Plus qu'IPv6 :D


Juste mon avis, peu d'envie d'en débattre si j'ai raison ou pas, à 
part peut être avec un commercial qui vendrait une solution SDx ^^


Mon point de vue trollesque est : SDN c'est Still Does Nothing. Moi je 
travaille sur du RDN, Real Defined Network :p Tu trouveras personne 
qui a la même définition du SDN parce que ca ne représente rien de 
manière unitaire technologiquement parlant. On peut faire un peu la 
même chose avec le Zero Trust ces derniers mois ;)



Le 20-05-2021 12:54, Cécile MORANGE a écrit :

Hello la liste ! Je commence à me renseigner sur le SDN et je me suis
dit que ce serait sympa d'écrire un article sur mon blog
(blog.ataxya.net) à propos de ça. Vu que sur internet je trouve
beaucoup plus de présentations commerciales que d'avis réels sur la
solution, je me suis dit que j'allais demander à mon groupe d'expert
préféré ce qu'il pense de cette techno. Mes questions sont donc : -
Pourquoi passer au SDN ? - Il y a-t-il un réel intérêt de passer au
SDN ? (Hormis l'aspect commercial) - En avez-vous déjà mis en place ?
Comment ça s'est passé ? Avez-vous remarqué un réel changement dans la
façon de faire vos réseaux ? (et du gain de temps ?) - Pensez vous que
dans 5,10,20 ans, tous les réseaux seront du SDN ? Je suis à l'écoute
de tous vos retours, ça me permettra de mieux comprendre le SDN et
l'intérêt (s'il y en a un) !
(Je sens que je vais lancer un long thread plein de débats :D)
Merci d'avance !

Cordialement,





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

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[Fabien VINCENT FrNOG via frnog]

Bonjour,

Wikipedia non ? Pour éviter de lancer une trollchain :D

<...>
C'est un ensemble de technologies ayant comme points communs :
1. un contrôle centralisé des ressources réseau ;
2. une orchestration centralisée ;
3. une virtualisation des ressources physiques.
<...>

Le 2 a déjà été évoqué (ansible, automation tout ca tout ca). Le 3, tout 
le monde le voit tous les jours, bye bye le HW chiant, vive les VMs, les 
dockers les k8s. (bon ca tourne toujours sur un proc qui n'est pas 
quantique mais c'est abstrait c'est déjà ca)


Le 1 par contre c'est le truc le plus touchy et fourre tout. On te vend 
du SDx pour tout et n'importe quoi. En vrai, y a un vrai sujet de 
centralisation du control plane (voir du côté d'OpenFlow, de 
OpenDaylight, des technos comme SR ou des RR out of the path pour BGP). 
Bref, c'est plutôt un changement de paradigme du réseau dans la gestion 
de son controle plane de manière + centralisé. Il y a aussi le sujet de 
la désagrégation avec la séparation du HW et du SW avec les whitebox 
(Sonic ou même les constructeurs comme Arista/Nokia qui vendent des SW 
now sur du HW tier)


Donc pour moi SDN ca veut "rien dire". Parce que c'est un ensemble de 
technos que les marketeux ne comprendront pas ;) Et on peut pas leur en 
vouloir ! Heureusement ca n'a jamais remplacé le métier d'ingé' réseau 
;) Voir même ca l'a renforcé ! Plus qu'IPv6 :D


Juste mon avis, peu d'envie d'en débattre si j'ai raison ou pas, à part 
peut être avec un commercial qui vendrait une solution SDx ^^


Mon point de vue trollesque est : SDN c'est Still Does Nothing. Moi je 
travaille sur du RDN, Real Defined Network :p Tu trouveras personne qui 
a la même définition du SDN parce que ca ne représente rien de manière 
unitaire technologiquement parlant. On peut faire un peu la même chose 
avec le Zero Trust ces derniers mois ;)



Le 20-05-2021 12:54, Cécile MORANGE a écrit :

Hello la liste ! Je commence à me renseigner sur le SDN et je me suis
dit que ce serait sympa d'écrire un article sur mon blog
(blog.ataxya.net) à propos de ça. Vu que sur internet je trouve
beaucoup plus de présentations commerciales que d'avis réels sur la
solution, je me suis dit que j'allais demander à mon groupe d'expert
préféré ce qu'il pense de cette techno. Mes questions sont donc : -
Pourquoi passer au SDN ? - Il y a-t-il un réel intérêt de passer au
SDN ? (Hormis l'aspect commercial) - En avez-vous déjà mis en place ?
Comment ça s'est passé ? Avez-vous remarqué un réel changement dans la
façon de faire vos réseaux ? (et du gain de temps ?) - Pensez vous que
dans 5,10,20 ans, tous les réseaux seront du SDN ? Je suis à l'écoute
de tous vos retours, ça me permettra de mieux comprendre le SDN et
l'intérêt (s'il y en a un) !
(Je sens que je vais lancer un long thread plein de débats :D)
Merci d'avance !

Cordialement,


--
Fabien VINCENT
_@beufanet_


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

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[Stéphane Rivière]

> Au prochain lustre,

Confirme le 19 mai 2026 pour notre prochain contact.

-- 
Stéphane Rivière
Ile d'Oléron - France


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

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[Vincent Habchi]

> On 20 May 2021, at 14:31, Stéphane Rivière  wrote:
>> Il s’est passé quelque chose depuis 1930 ?
> 
> Non.
> 
> Les allemands sont toujours les meilleurs, les grands-bretons toujours
> sur leur île et nous toujours aussi gaulois.

Merci de confirmer. :)

Je vais pouvoir retourner à mes méditations, sans arrière-pensées.

Au prochain lustre,

V.


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

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[Remi Desgrange]

Tout ceci est intéressant.


Je pense que dans ce fil y'a des gens qui confondent : SDN et SD-WAN.
Egalement NFV (network function virtualization) et SDN. Rien à voir :-)

Personne n'a parlé du protocole derrière le SDN: OpenFlow, qui permet de
contrôler des équipements à distance. Dans les prez commerciale, le fait de
pouvoir gérer les équipements via ansible c'est jamais vraiment vendu, ce
qui est vendu, c'est de séparer le plan de contrôle du plan de données, de
mettre l'intelligence dans un truc central (manipulable via API, et oui,
commerciale on vous dit, et SPOF aussi) pour pouvoir changer le plan de
données à la volé.

Loin du ansible donc :-)

Gérer les confs dans ansible c'est pas vraiment du SDN pour moi (mais là
c'est mon avis) c'est simplement du conf mgmt en version 2.

On Thu, May 20, 2021 at 2:36 PM Stéphane Kanschine 
wrote:

>
> Salutations,
>
> Le jeu. 20 mai, vers 13:12, David Ponzone exprimait :
>
> > Ah Cécile n’ayant pas précisé, j’ai effectivement raccourci à la partie
> la plus visible du SDN.
> >
> > Si on élargit au coeur de réseau, on reste dans un bon bullshit non ?
> > Des confs de routeurs poussées par Ansible, c’est du SDN ou pas ?
>
> Oui.
>
> Chez mon client actuel, c'est la partie logiciel qui automatise la
> création de liens commandés en ligne par les clients entre plusieurs
> fournisseur cloud (aws, gcp, azure, alibaba, ibm, oracle), sur
> plusieurs marques de matos (extreme, juniper, etc).
>
> Donc des template de confs pour chaque fabricant/version ont été
> définis. L'inventaire et la supervision sont interrogées et remplies
> automatiquement et le déprovisionnement des liens aussi.
>
> Numériquement,
> Stéphane
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>


-- 
Cordialement, Rémi Desgrange

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

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[Stéphane Kanschine]

Salutations,

Le jeu. 20 mai, vers 13:12, David Ponzone exprimait :

> Ah Cécile n’ayant pas précisé, j’ai effectivement raccourci à la partie la 
> plus visible du SDN.
> 
> Si on élargit au coeur de réseau, on reste dans un bon bullshit non ?
> Des confs de routeurs poussées par Ansible, c’est du SDN ou pas ?

Oui.

Chez mon client actuel, c'est la partie logiciel qui automatise la
création de liens commandés en ligne par les clients entre plusieurs
fournisseur cloud (aws, gcp, azure, alibaba, ibm, oracle), sur
plusieurs marques de matos (extreme, juniper, etc).

Donc des template de confs pour chaque fabricant/version ont été
définis. L'inventaire et la supervision sont interrogées et remplies
automatiquement et le déprovisionnement des liens aussi.

Numériquement,
Stéphane


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

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[Stéphane Rivière]

> Euh, j’ai dû louper quelque chose, parce que pour moi, SDN c’est la Société 
> Des Nations…

:

> Il s’est passé quelque chose depuis 1930 ?

Non.

Les allemands sont toujours les meilleurs, les grands-bretons toujours
sur leur île et nous toujours aussi gaulois.

-- 
Be Seeing You
Number Six


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

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[Stéphane Rivière]

> A mon sens, oui. Ou tout réseau qui utilise un S.I. maison pour faire
> son (dé)provisionning, c'est quelque part du SDN, et ca n'a rien de
> nouveau dans le concept.

+1000

Je viens d'apprendre que je fais du SDN avec notre gestionnaire de
cluster Debian/Xen qui s'appuie sur le noyau linux pour le réseau et le
routage (dynamiquement modifié), le tout étant automatisé en Ada.

Crénondédiou !

-- 
Be Seeing You
Number Six


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

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[OB via frnog]

Bonjour,

> Alors, le SDN étant un terme marketing et à la mode, tout le monde a 
un peu sa

> définition pour pouvoir y coller ses produits. Je vais donc commencer par
> définir pour moi ce que c'est. Et je me limiterais au réseau de 
"datacenter"
> parce que je n'ai pas encore vue de différence entre du SD-WAN et un 
lien VPN.


Merci de cette réponse, Xavier, parce que la dernière fois que j'ai 
parlé de MPLS, on ma répondu avec mépris : "Pfff, mpls c'est has-been, 
nous on fait du *SD-WAN* maintenant".
Et après m'être renseigné ben en fait j'ai pas tellement vu de 
différence entre un "SD-WAN" et un tinc :-/ , hormis le fait que c'était 
vendu hors de prix par un intégrateur, qu'il y avait parfois un 
clickodrome et qu'on y perdait toute notion de GTR ou de QoS.



Dans le cas d'usage hyper-spécifique de Grégoire, oui, OK (faisant moi 
même un peu de multicast je conçois la galère).



Pour le SDN, je peux tout à fait concevoir l'intérêt d'avoir une conf 
réseau unifiée et applicable à n'importe quelle marque de routeur (il me 
semble que j'avais déjà vu un projet qui "traduisait" des conf en yaml 
en cisco/arista/junip/microtik/...)


Pour une grande équipe et dans un souci de documentation vis à vis du 
turn-over, je peux vois l'intérêt. Aujourd'hui, je pense que 
j'utiliserais Ansible pour ça... mais ce n'est que moi.




Julien



Salut,


Donc, pour moi, le SDN c'est le fait de pouvoir utiliser une API pour
configurer ton réseau. C'est-à-dire que tu peux utiliser un produit existant ou
développer un truc maison pour configurer ton parc. Dans le cas de
virtualisation de réseau (quand tu utilises des VM), cela va aller jusqu'au
branchement des câbles virtuels.

Pourquoi passer au SDN et quels sont les avantages ? Déjà, beaucoup de monde en
fait déjà en partie à coup d'outils existant ou de scripts maison. Mais je
dirais que le plus gros avantage est la reproductibilité et le déploiement
automatique. Tu vas pouvoir avoir la même configuration Terraform en DEV et en
PROD aux variables prêt (par exemple le plan d'adressage, même si avec des VRF,
ça pourrait même être strictement le même), ça permet d'éviter les erreurs de
la config qui fonctionne en dev mais pas en prod. Toujours en restant avec
l'exemple Terraform, tu vas pouvoir avoir le même projet pour la configuration
réseau que pour les VM, ce qui veut dire que tu le jour où tu supprime tes VM,
la configuration réseau spécifique est aussi supprimée, ça évite d'avoir des
relicats que plus personne ne connaît. Tout cela permet de simplifier la partie
"self-service" et évite de passer du temps à copier la configuration sur tous
les switchs et routeurs impactés.

En avez-vous déjà mis en place ? Oui, mais dans un cas particulier avec VMWare
NSX-T, donc qui implique la virtualisation de réseau (en gros, tous les paquets
sont encapsulés), ce qui veut dire, pas de configuration du réseau physique. Au
niveau gain de temps, oui. Quand une VM doit être déployée, il suffit de mêttre
les bon paramètres Terraform et avec quelques modules, on a la VM, le switch
virtuel, le routeur et mêmes les règles firewall spécifiques qui sont déployées
automatiquement. Gain de temps mais surtout moins d'erreurs de manipulation.
Cela n'a bien sûr de l'intérêt que pour les tâches courantes, automatiser la
configuration qui sera faite une fois tous les 5 ans est une perte de temps et
dans 5 ans, plus personne ne se souvient de comment le script fonctionne.

Voilà mon retour sur un cas spécifique d'utilisation.

Bonne journée.

Xavier


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




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

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[Xavier Claude]

On Thu, May 20, 2021 at 12:54:28PM +0200, Cécile MORANGE wrote:
> Hello la liste ! Je commence à me renseigner sur le SDN et je me suis dit
> que ce serait sympa d'écrire un article sur mon blog (blog.ataxya.net) à
> propos de ça. Vu que sur internet je trouve beaucoup plus de présentations
> commerciales que d'avis réels sur la solution, je me suis dit que j'allais
> demander à mon groupe d'expert préféré ce qu'il pense de cette techno. Mes
> questions sont donc : - Pourquoi passer au SDN ? - Il y a-t-il un réel
> intérêt de passer au SDN ? (Hormis l'aspect commercial) - En avez-vous déjà
> mis en place ? Comment ça s'est passé ? Avez-vous remarqué un réel
> changement dans la façon de faire vos réseaux ? (et du gain de temps ?) -
> Pensez vous que dans 5,10,20 ans, tous les réseaux seront du SDN ? Je suis à
> l'écoute de tous vos retours, ça me permettra de mieux comprendre le SDN et
> l'intérêt (s'il y en a un) !
> (Je sens que je vais lancer un long thread plein de débats :D)
> Merci d'avance !


Salut,

Alors, le SDN étant un terme marketing et à la mode, tout le monde a un peu sa
définition pour pouvoir y coller ses produits. Je vais donc commencer par
définir pour moi ce que c'est. Et je me limiterais au réseau de "datacenter"
parce que je n'ai pas encore vue de différence entre du SD-WAN et un lien VPN.

Donc, pour moi, le SDN c'est le fait de pouvoir utiliser une API pour
configurer ton réseau. C'est-à-dire que tu peux utiliser un produit existant ou
développer un truc maison pour configurer ton parc. Dans le cas de
virtualisation de réseau (quand tu utilises des VM), cela va aller jusqu'au
branchement des câbles virtuels. 

Pourquoi passer au SDN et quels sont les avantages ? Déjà, beaucoup de monde en
fait déjà en partie à coup d'outils existant ou de scripts maison. Mais je
dirais que le plus gros avantage est la reproductibilité et le déploiement
automatique. Tu vas pouvoir avoir la même configuration Terraform en DEV et en
PROD aux variables prêt (par exemple le plan d'adressage, même si avec des VRF,
ça pourrait même être strictement le même), ça permet d'éviter les erreurs de
la config qui fonctionne en dev mais pas en prod. Toujours en restant avec
l'exemple Terraform, tu vas pouvoir avoir le même projet pour la configuration
réseau que pour les VM, ce qui veut dire que tu le jour où tu supprime tes VM,
la configuration réseau spécifique est aussi supprimée, ça évite d'avoir des
relicats que plus personne ne connaît. Tout cela permet de simplifier la partie
"self-service" et évite de passer du temps à copier la configuration sur tous
les switchs et routeurs impactés.

En avez-vous déjà mis en place ? Oui, mais dans un cas particulier avec VMWare
NSX-T, donc qui implique la virtualisation de réseau (en gros, tous les paquets
sont encapsulés), ce qui veut dire, pas de configuration du réseau physique. Au
niveau gain de temps, oui. Quand une VM doit être déployée, il suffit de mêttre
les bon paramètres Terraform et avec quelques modules, on a la VM, le switch
virtuel, le routeur et mêmes les règles firewall spécifiques qui sont déployées
automatiquement. Gain de temps mais surtout moins d'erreurs de manipulation.
Cela n'a bien sûr de l'intérêt que pour les tâches courantes, automatiser la
configuration qui sera faite une fois tous les 5 ans est une perte de temps et
dans 5 ans, plus personne ne se souvient de comment le script fonctionne.

Voilà mon retour sur un cas spécifique d'utilisation.

Bonne journée.

Xavier


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

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[Gregoire Huet]

Hello,

Le SDN est très utilisé pour la production vidéo « live », en particulier pour 
mettre en oeuvre la norme SMPTE ST-2110 de production audio/video temps-réel 
sur IP.

Le principe est de créer des flux multicast à la demande sur le réseau, entre 
producteurs (caméra…) et consommateurs (diffusion..) depuis divers équipements 
comme des panneaux de contrôle (hard ou soft), dans un moteur de workflow ou 
encore entre différents réseaux.

Ça se passe bien, ça fonctionne bien, les vendeurs de hard (j’ai utilisé 
Mellanox et Arista, mais Cisco ça marche aussi) supportent différentes API qui 
permettent l’insertion de routes de manière quasi-immédiate.
Je trouve très intéressant les contrôleurs SDN qui fabriquent des chemins 
multicast complètement différents sur un même réseau pour construire une 
redondance des flux de manière dynamique.

L’intérêt par rapport à du simple IGMP est un contrôle centralisé, une rapidité 
d’exécution, une délégation à un contrôleur qui ne fait pas d’erreur, une 
allocation automatique des groupes multicast etc..

Le sujet est vaste et passionnant, et pour cette application particulière, le 
SDN semble indispensable.

Bien cordialement,

Grégoire

> Le 20 mai 2021 à 12:54, Cécile MORANGE  a écrit :
> 
> Hello la liste ! Je commence à me renseigner sur le SDN et je me suis dit que 
> ce serait sympa d'écrire un article sur mon blog (blog.ataxya.net) à propos 
> de ça. Vu que sur internet je trouve beaucoup plus de présentations 
> commerciales que d'avis réels sur la solution, je me suis dit que j'allais 
> demander à mon groupe d'expert préféré ce qu'il pense de cette techno. Mes 
> questions sont donc : - Pourquoi passer au SDN ? - Il y a-t-il un réel 
> intérêt de passer au SDN ? (Hormis l'aspect commercial) - En avez-vous déjà 
> mis en place ? Comment ça s'est passé ? Avez-vous remarqué un réel changement 
> dans la façon de faire vos réseaux ? (et du gain de temps ?) - Pensez vous 
> que dans 5,10,20 ans, tous les réseaux seront du SDN ? Je suis à l'écoute de 
> tous vos retours, ça me permettra de mieux comprendre le SDN et l'intérêt 
> (s'il y en a un) !
> (Je sens que je vais lancer un long thread plein de débats :D)
> Merci d'avance !
> 
> Cordialement,
> 
> -- 
> Cécile MORANGE
> cont...@cecilemorange.fr
> ataxya.net
> @AtaxyaNetwork
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[Vincent Habchi]

On 20 May 2021, at 12:54, Cécile MORANGE  wrote:
> 
> Hello la liste ! Je commence à me renseigner sur le SDN

[…]

Euh, j’ai dû louper quelque chose, parce que pour moi, SDN c’est la Société Des 
Nations…

Il s’est passé quelque chose depuis 1930 ?

V.


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

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[Romain BAFFERT]

Hello Cécile, content de te voir ici ! Je suis un fan depuis longtemps sur ton 
Twitter, et je parlais justement de toi à ma geekette de collègue « regarde 
cette fille elle envoie du pâté de geek avec son datacenter à cet âge ! » elle 
était admirative ^^

Pour ce qui est de ta question, un peu comme toi je suis un peu soulé par le 
côté bullshit marketing de beaucoup de techno... mais c’est un peu général ! 
Pourquoi appeler cloud ce qui s’appelle hébergement depuis bien longtemps, etc 
etc...

Après, là où je suis d’accord que c’est pas que du marketing, c’est toutes les 
solutions techniques qui permettent de faire abstraction facile du hardware 
(notamment justement les solutions type cloud public). Je cherche d’ailleurs un 
système (même payant) permettant de faire en multi tenant ce que proposent des 
AWS / GCP / azure, j’imagine une distribution / logiciel qui s’installerait sur 
du bare métal et montrerait une surcouche permettant de laisser l’utilisateur 
gérer des réseaux des routages etc... vmware fait un peu ça, je sais pas si des 
choses comme proxmox / ubuntu ont des choses similaires, ou bien carrément des 
startup qui proposeraient ça en mode SaaS...

En tous cas le sujet est intéressant à discuter entre techniciens en faisant 
abstraction du bullshit marketing !

Le 20 mai 2021 à 17:55 +0700, Cécile MORANGE , a écrit :
Hello la liste ! Je commence à me renseigner sur le SDN et je me suis
dit que ce serait sympa d'écrire un article sur mon blog
(blog.ataxya.net) à propos de ça. Vu que sur internet je trouve beaucoup
plus de présentations commerciales que d'avis réels sur la solution, je
me suis dit que j'allais demander à mon groupe d'expert préféré ce qu'il
pense de cette techno. Mes questions sont donc : - Pourquoi passer au
SDN ? - Il y a-t-il un réel intérêt de passer au SDN ? (Hormis l'aspect
commercial) - En avez-vous déjà mis en place ? Comment ça s'est passé ?
Avez-vous remarqué un réel changement dans la façon de faire vos réseaux
? (et du gain de temps ?) - Pensez vous que dans 5,10,20 ans, tous les
réseaux seront du SDN ? Je suis à l'écoute de tous vos retours, ça me
permettra de mieux comprendre le SDN et l'intérêt (s'il y en a un) !
(Je sens que je vais lancer un long thread plein de débats :D)
Merci d'avance !

Cordialement,

--
Cécile MORANGE
cont...@cecilemorange.fr
ataxya.net
@AtaxyaNetwork


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

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

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[Arnold Dechamps]

Bonjour,

Si SDN signifie ici : gestion à distance centralisée d'équipements, il y'a des 
trucs qui semblent pas mal chez Cisco (ACI. Jamais testé) et d'autres qui sont 
notoirement moins bon chez cisco aussi (DNA-C). Il y'a UniFi qui fait une base 
de SDN... Mais malheureusement, à moins d'aller sur des trucs très poussés pour 
du très large scale, ce genre de SDN est au réseau ce que beaucoup de packages 
commerciaux de DPI sont à la Cybersécu. AKA des Pew-Pew map pour managers qui 
veulent voir de quel pays sont les hackers qui les piratent depuis une jolie 
interface web.

Ansible-Playbook (avec un tower si tu veux une interface web) marche bien mais 
est fastidieu à set-up.

Bien cordialement,

Arnold

Le 20/05/2021 13:18, « Hugues Voiturier »  a écrit :

> Des confs de routeurs poussées par Ansible, c’est du SDN ou pas ?
Moi je dirais que oui, mais certains te parlent de routeur/switch virtuel, 
et là, ça commence à m’inquiéter :)


Hugues Voiturier
Consultant en architecture réseau
AS57199

> On 20 May 2021, at 13:12, David Ponzone  wrote:
> 
> Ah Cécile n’ayant pas précisé, j’ai effectivement raccourci à la partie 
la plus visible du SDN.
> 
> Si on élargit au coeur de réseau, on reste dans un bon bullshit non ?
> Des confs de routeurs poussées par Ansible, c’est du SDN ou pas ?
> 
> 
>> Le 20 mai 2021 à 13:09, Hugues Voiturier  a 
écrit :
>> 
>>> Sans parler des risques que sous prétexte qu’on fait du « SDN », on met 
n’importe quoi comme liaisons en dessous, parce que le SDN est « agnostique » 
des technos utilisées.
>> C’est pas plutôt SD-WAN ça ?
>> 
> 


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



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

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[Pierre Colombier via frnog]

Hello,

Comment vous employez Ansible pour du matos réseau ?

J'ai essayé et 'ai trouvé que c'était la misère...

Ansible sans interpréteur python sur la cible ou sans module bien léché, 
comment dire Autant faire des scripts en bash



On 20/05/2021 13:12, David Ponzone wrote:

Ah Cécile n’ayant pas précisé, j’ai effectivement raccourci à la partie la plus 
visible du SDN.

Si on élargit au coeur de réseau, on reste dans un bon bullshit non ?
Des confs de routeurs poussées par Ansible, c’est du SDN ou pas ?



Le 20 mai 2021 à 13:09, Hugues Voiturier  a écrit :


Sans parler des risques que sous prétexte qu’on fait du « SDN », on met 
n’importe quoi comme liaisons en dessous, parce que le SDN est « agnostique » 
des technos utilisées.

C’est pas plutôt SD-WAN ça ?



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



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

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[Clement Cavadore]

Hello,

Le jeudi 20 mai 2021 à 13:12 +0200, David Ponzone a écrit :
> Des confs de routeurs poussées par Ansible, c’est du SDN ou pas ?

A mon sens, oui. Ou tout réseau qui utilise un S.I. maison pour faire
son (dé)provisionning, c'est quelque part du SDN, et ca n'a rien de
nouveau dans le concept.

Après, les solutions tout intégrées par les vendors, le SD-WAN, etc,
tout ca, y'a matière à en parler, en effet. Il faut, comme toujours,
savoir distiller les infos/technos/solutions pour ses propres besoins,
mais il est vrai que parfois, il y a du bon gros bullshit marketto-
sales oriented. 

Mais pas toujours... :D

-- 
Clément Cavadore


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

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[David Ponzone]

Ok donc quand tu as un HV, avec son vSwitch intégré, et que tu mets des 
routeurs dans certaines VM en frontal aux VM applications, tu fais déjà du SDN.
Si en plus, tu as automatisé tout ça, t’as un AutoSDN :)
Bref, bullshit.

Si quelqu’un a un exemple un peu plus impressionnant à donner ?

> Le 20 mai 2021 à 13:13, Hugues Voiturier  a écrit :
> 
>> Des confs de routeurs poussées par Ansible, c’est du SDN ou pas ?
> Moi je dirais que oui, mais certains te parlent de routeur/switch virtuel, et 
> là, ça commence à m’inquiéter :)
> 


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

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[Pierre Colombier via frnog]

J'avoue que je n'ai toujours pas compris ce dont il s'agissait.

Je veux dire précisément, qu'est-ce qu'il reste une fois on a enlevé le 
vernis commercial ?



Selon ce qu'on entends par ce mot, soit c'est une coquille vide et ça 
sert pas à grand chose,


soit c'est une boite noire magique qui fait tout automagiquement et 
c'est donc casse-gueule : Quels leviers reste-t-il quand la magie 
n'opère pas ?






On 20/05/2021 12:54, Cécile MORANGE wrote:
Hello la liste ! Je commence à me renseigner sur le SDN et je me suis 
dit que ce serait sympa d'écrire un article sur mon blog 
(blog.ataxya.net) à propos de ça. Vu que sur internet je trouve 
beaucoup plus de présentations commerciales que d'avis réels sur la 
solution, je me suis dit que j'allais demander à mon groupe d'expert 
préféré ce qu'il pense de cette techno. Mes questions sont donc : - 
Pourquoi passer au SDN ? - Il y a-t-il un réel intérêt de passer au 
SDN ? (Hormis l'aspect commercial) - En avez-vous déjà mis en place ? 
Comment ça s'est passé ? Avez-vous remarqué un réel changement dans la 
façon de faire vos réseaux ? (et du gain de temps ?) - Pensez vous que 
dans 5,10,20 ans, tous les réseaux seront du SDN ? Je suis à l'écoute 
de tous vos retours, ça me permettra de mieux comprendre le SDN et 
l'intérêt (s'il y en a un) !

(Je sens que je vais lancer un long thread plein de débats :D)
Merci d'avance !

Cordialement,




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

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[Hugues Voiturier]

> Des confs de routeurs poussées par Ansible, c’est du SDN ou pas ?
Moi je dirais que oui, mais certains te parlent de routeur/switch virtuel, et 
là, ça commence à m’inquiéter :)


Hugues Voiturier
Consultant en architecture réseau
AS57199

> On 20 May 2021, at 13:12, David Ponzone  wrote:
> 
> Ah Cécile n’ayant pas précisé, j’ai effectivement raccourci à la partie la 
> plus visible du SDN.
> 
> Si on élargit au coeur de réseau, on reste dans un bon bullshit non ?
> Des confs de routeurs poussées par Ansible, c’est du SDN ou pas ?
> 
> 
>> Le 20 mai 2021 à 13:09, Hugues Voiturier  a écrit 
>> :
>> 
>>> Sans parler des risques que sous prétexte qu’on fait du « SDN », on met 
>>> n’importe quoi comme liaisons en dessous, parce que le SDN est « agnostique 
>>> » des technos utilisées.
>> C’est pas plutôt SD-WAN ça ?
>> 
> 


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

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[David Ponzone]

Ah Cécile n’ayant pas précisé, j’ai effectivement raccourci à la partie la plus 
visible du SDN.

Si on élargit au coeur de réseau, on reste dans un bon bullshit non ?
Des confs de routeurs poussées par Ansible, c’est du SDN ou pas ?


> Le 20 mai 2021 à 13:09, Hugues Voiturier  a écrit :
> 
>> Sans parler des risques que sous prétexte qu’on fait du « SDN », on met 
>> n’importe quoi comme liaisons en dessous, parce que le SDN est « agnostique 
>> » des technos utilisées.
> C’est pas plutôt SD-WAN ça ?
> 


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

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[Hugues Voiturier]

> Sans parler des risques que sous prétexte qu’on fait du « SDN », on met 
> n’importe quoi comme liaisons en dessous, parce que le SDN est « agnostique » 
> des technos utilisées.
C’est pas plutôt SD-WAN ça ?

> On 20 May 2021, at 13:07, David Ponzone  wrote:
> 
> bullshit marketing
> Sans parler des risques que sous prétexte qu’on fait du « SDN », on met 
> n’importe quoi comme liaisons en dessous, parce que le SDN est « agnostique » 
> des technos utilisées.
> 
>> Le 20 mai 2021 à 12:54, Cécile MORANGE  a écrit :
>> 
>> Hello la liste ! Je commence à me renseigner sur le SDN et je me suis dit 
>> que ce serait sympa d'écrire un article sur mon blog (blog.ataxya.net) à 
>> propos de ça. Vu que sur internet je trouve beaucoup plus de présentations 
>> commerciales que d'avis réels sur la solution, je me suis dit que j'allais 
>> demander à mon groupe d'expert préféré ce qu'il pense de cette techno. Mes 
>> questions sont donc : - Pourquoi passer au SDN ? - Il y a-t-il un réel 
>> intérêt de passer au SDN ? (Hormis l'aspect commercial) - En avez-vous déjà 
>> mis en place ? Comment ça s'est passé ? Avez-vous remarqué un réel 
>> changement dans la façon de faire vos réseaux ? (et du gain de temps ?) - 
>> Pensez vous que dans 5,10,20 ans, tous les réseaux seront du SDN ? Je suis à 
>> l'écoute de tous vos retours, ça me permettra de mieux comprendre le SDN et 
>> l'intérêt (s'il y en a un) !
>> (Je sens que je vais lancer un long thread plein de débats :D)
>> Merci d'avance !
>> 
>> Cordialement,
>> 
>> -- 
>> Cécile MORANGE
>> cont...@cecilemorange.fr
>> ataxya.net
>> @AtaxyaNetwork
>> 
>> 
>> ---
>> 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] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[David Ponzone]

bullshit marketing
Sans parler des risques que sous prétexte qu’on fait du « SDN », on met 
n’importe quoi comme liaisons en dessous, parce que le SDN est « agnostique » 
des technos utilisées.

> Le 20 mai 2021 à 12:54, Cécile MORANGE  a écrit :
> 
> Hello la liste ! Je commence à me renseigner sur le SDN et je me suis dit que 
> ce serait sympa d'écrire un article sur mon blog (blog.ataxya.net) à propos 
> de ça. Vu que sur internet je trouve beaucoup plus de présentations 
> commerciales que d'avis réels sur la solution, je me suis dit que j'allais 
> demander à mon groupe d'expert préféré ce qu'il pense de cette techno. Mes 
> questions sont donc : - Pourquoi passer au SDN ? - Il y a-t-il un réel 
> intérêt de passer au SDN ? (Hormis l'aspect commercial) - En avez-vous déjà 
> mis en place ? Comment ça s'est passé ? Avez-vous remarqué un réel changement 
> dans la façon de faire vos réseaux ? (et du gain de temps ?) - Pensez vous 
> que dans 5,10,20 ans, tous les réseaux seront du SDN ? Je suis à l'écoute de 
> tous vos retours, ça me permettra de mieux comprendre le SDN et l'intérêt 
> (s'il y en a un) !
> (Je sens que je vais lancer un long thread plein de débats :D)
> Merci d'avance !
> 
> Cordialement,
> 
> -- 
> Cécile MORANGE
> cont...@cecilemorange.fr
> ataxya.net
> @AtaxyaNetwork
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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