> Arnaud Fenioux a dit :
><troll>
>Si ta question est : "Quand est ce que tout le monde utilisera LISP?"
>Je dirais : c est comme le déploiement d'IPv6 ou de DNSSEC hein!
></troll>
Guten Aben, Freunde,
"Mon petit Fred, j'ai explication" comme disait Tonton Helmut, le doc
gyneco des carpates.
Excellente question au demeurant : y a-t-il un intérêt à déployer LISP pour
n'importe quelle entreprise ?
L'argument de départ de LISP était : réduction de la taille de la DFZ.
Force est de constater que pour un opérateur qui a la full route, il est
plus simple d'investir dans du routeur qui tient la DFZ a plusieurs
millions de routes que de déployer LISP (les arguments étant souvent
spécieux : "c'est pas assez sec / c'est trop complexe").
De plus, test effectué dans le lab cette semaine, mais une VM Quagga sous
Debian (bref Vyatta par exemple) avec 2Go de RAM, on lui injecte 2 millions
de routes dans la tête, elle bronche pas. "Oui mais c'est pas déployable en
prod". Certes mais pas à cause du control plane, pour 90% des besoins
Quagga suffirait (je parle bien sur pas d'opérateurs faisant des trucs un
peu complexe, genre VPLS and co), par contre le forward plane d'une VM
c'est pas encore ça ... pour le moment (cf présentation DPDK du dernier
FRNOG)
On peut donc conjecturer que l'avenir sera aux OS dédié routage, plutot
décorrélé du hard, mort des ASICs/SOC au profit d'une archi "banalisé"
x86/PCIe pour les routeurs ne nécessitant pas une concentration monstrueuse
de ports.
Du coup, LISP pour la réduction de la DFZ, j'ai peur que l'argument ne
tienne plus, donc qu'on déploiera LISP, mais pour d'autres raisons.
Fick dich, Herr Lisp, donc ?
La raison principale qui me vient à l'esprit, c'est la gestion de la
mobilité.
A l'heure actuelle, la convergence réseau "LTE" et réseau "Wireless de
proximité", c'est nul et non avenu. Bon ok, la 4G promet une convergence
Wifi,LTE et même Wimax (ah ah ah ?), mais en pratique, ça n'existe juste
pas (ne serait ce que parce que ça voudrait dire avoir un Access Point Wifi
dans sa box, géré depuis un controleur central ... mmm GFY).
Bon et puis y a pas que les téléphones qui bougent, y a aussi les VMs.
Dans tous les cas, la gestion de la mobilité est historiquement laissée aux
équipements réseaux de l'opérateur (S/GGSN en 3G par ex, home/foreign agent
en IP Mobility).
Juste pour exemple, la téléphonie mobile.
LISP, notamment lisp-mob permet d'envisager les choses sous un autre angle
: je déploie lisp_mob directement sur mon téléphone (Android typiquement)
=> mon téléphone devient xTR, pour un subnet super restreint = son EID.
Dans le réseau opérateur, voire même à l'échelle de plusieurs opérateur,
pour gérer un handover multiréseaux, on déploie un ensemble de MS/MR
(typiquement en LISP-Tree sous l'égide d'un organisme neutre veillant sur
le root ... ça va faire plaisir au Bortzmeyer), et l'opérateur n'est en
charge que d'assurer la livraison du RLOC sur le téléphone, tout le reste
est autonome, et migrera avec la mobilité du téléphone.
En clair, la "loopback" de mon téléphone est toujours joignable.
Bien entendu, l'IP du téléphone c'est une IPv4 publique, et une IPv6
(publique ...). Vu l'économie d'IP réalisée, toutes les IPs intercos,
loopback de routeurs, etc peuvent être réattribuées aux End Users, ici les
téléphones.
Si maintenant j'ai une flotte entreprise, donc je veux cloisonner ma flotte
vis à vis de la DFZ.
Solution historique : un APN dédié, mappé sur un VPN-MPLS dans le réseau
opérateur. Ca marche bien en 3G/LTE, mais une fois basculé sur le wifi ...
faut prévoir un SSID dédié, mappé sur le même VPN MPLS etc.
Avec LISP, j'affecte une IPv4 et une IPv6 d'un pool spécifique au client,
je fais le bon mapping qui va bien (ie : soit le client a un MS/MR dédié
[bof] soit le client est cloisonné au niveau du MS/MR avec les extensions
qui vont bien), mais le reste est inchangé.
Dans ces conditions, LISP est déjà utilisé à petite échelle, notamment sur
les accès Wifi dans des trains en Allemagne.
Pour les VMs, même approche.
Actuellement les déploiement de LISP partent du principe que les ingés
systèmes sont des burnasses téluriques en réseau, donc on fait tourner le
xTR sur le routeur de first hop.
Donc c'est tout le subnet qui est derrière qui est mappé, et donc on garde
les emmerdes d'un IP over Ethernet classique sur le premier segment.
Si je déplace une VM d'un site A à un site B, LISP est conscient du
déplacement au premier paquet envoyé depuis le site B. Donc latence et
éventuellement perte de paquet dans l'intervalle. Comment on résoud ça ? On
met un layer 2 étendu entre site A et site B (VPLS, PBB-EVPN) et quand la
VM bouge sur le site B, LISP a un rôle d'optimisation du routage a
posteriori.
En attendant, la gateway est soit étendu via un moche VRRP inter-sites,
soit locale sur un site, donc trafic asymétrique quand je bouge, soit un
gros caca de type "on fixe la même adresse MAC sur les deux gateways site
A, et site B, et sur le layer 2 étendu entre les deux, on filtre les
requêtes ARP sur cette IP/MAC". Bref gaz factory ultime.
Demain, je prends mes guest OS favoris, j'installe LISP-MOB dessus, donc le
xTR n'est plus le routeur de la zone, mais tout simplement ma VM. Pas
besoin d'un RLOC en IPv4, IPv6 suffira vu que ce qui m'intéresse c'est que
l'EID de ma VM qui lui est dual-stack (mais en LISP, point besoin que le
core connaisse l'espace d'adressage des EID, donc on s'en fout).
Pourquoi IPv6 pour le RLOC ? Pour utiliser uniquement une IPv6 EUI-64
calculé automatiquement en fonction du site ==> elle change quand la VM
bouge de site A à site B, pas de soucis, on met à jour le mapping RLOC /
EID, comme d'hab.
Du coup, plus besoin de layer 2 entre les sites, plus besoin d'IPv4 dans le
Core, on ne gère que l'espace des EID des machines, qui est indépendant.
Conclusion, pour en revenir à la question initiale "quand tout le monde
utilisera LISP ?".
Jamais.
Les opérateurs de Cloud y viendront surement, ça permet d'envisager des
migrations inter-opérateurs sans avoir d'intercos à la con à monter. Encore
que, on peut s'attendre à un "c'tro compliqué, les ingé systèmes, jamais
ils sauront gérer un xTR dans un serveur", donc on fera fall-back sur une
techno bien éprouvé, bien connue, bien merdique : le niveau 2 étendu. Mich
verrückt Lager !
Les opérateurs mobiles vont-ils y aller ? Aaaach nein !
C'est pas vraiment à eux de le demander, mais à 1) le 3GPP ("ça m'a pas
l'air bien 3GPP proof votre techno là, ça à pas l'air de couter une
couille, c'est pas dans l'esprit de ce qu'on fait d'habitude. Weg !") et 2)
aux fournisseurs, genre Ericsson, Alcatel et consort ("ça m'a pas l'air
d'aller dans mon sens votre truc là, faudra que je bosse avec les
constructeurs de téléphones, et tout ça pour vous vendre moins
d'appliances-qui-vont-vous-sauver-la-vie et en prime sans aucune
possibilité de vous vendre des prestations hors de prix pour la moindre
modification de configuration ... Fick dich."). Ach so nein.
A la limite, Free Mobile c'est encore le seul opérateur mobile qui est en
mesure d'imposer à ces constructeurs de faire ce que lui veut, et de faire
un bras d'honneur au 3GPP parce que "juste non".
Les grandes entreprises ? Mais mon bon monsieur, nous on fait ce que les
SSII nous disent de faire dans leur audits à 10 millions par jour. Zünden
Sie den Fackel-Banknote !
Les petites entreprises ? Arrf, y a pas l'argent/les ressources humaines/le
skill/le besoin. Wir sind arm, helfen Sie uns ...
Donc on en reparle dans 20 ans, mais à mon avis (j'espère me tromper) mais
LISP aura rejoint GSE/8+8, SHIM6 et autre HIP au Pantheon des technos qui
marchent, mais que bon, on sait pourquoi les faire marcher, quand faire du
caca traditionnel très très cher marche aussi bien.
Achso, Gute Nacht Freunde,
Gunther,
Le 14 juin 2014 06:22, Michel Py <mic...@arneill-py.sacramento.ca.us> a
écrit :
> > Arnaud Fenioux a écrit:
> > <troll>
> > Si ta question est : "Quand est ce que tout le monde utilisera LISP?"
> > Je dirais : c est comme le déploiement d'IPv6 ou de DNSSEC hein!
> > </troll>
>
> Je donne des croquettes :P
> Je mise €0.02 sur DNSSEC.
>
> Michel.
>
>
> ---------------------------
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>
---------------------------
Liste de diffusion du FRnOG
http://www.frnog.org/
