Salut David, LISP est déjà utilisé sur Internet! Par des entreprises, au moins pour l'implémentation Cisco. Quand au site http://eid.lisp-lab.org c est une "IP" (comprendre un identifiant) qui fait partie de l'EID Space, c est donc une utilisation de l'implémentation Open-Source OpenLISP et d'un proxy PxTR.
<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> Arnaud 2014-06-13 12:46 GMT+02:00 David Ponzone <david.ponz...@gmail.com>: > Dans le meilleur des cas, vous verriez quand le passage en production de > LISP sur Internet ? > 5 ans ? 10 ans ? 20 ans ? > > Le 13 juin 2014 à 12:24, Stefano Secci <stefano.se...@lip6.fr> a écrit : > > > Bonjour, > > > > je rebondis sur ce message d’Arnaud pour vous dire que le coeur de la > plate-forme LISP-Lab est désormais opérationnel avec tous les elements du > système de mapping strictement en logiciel (MS/MRs, racine DDT, PxTR). La > version de développement de OpenLISP avec toutes les fonctionnalités > nécessaires est ici: https://github.com/lip6-lisp > > > > Le site du projet est d’ailleurs en mirror sur un serveur LISP: > http://eid.lisp-lab.org > > > > En accord avec le plan de ce projet ANR, la plate-forme sera bientôt > ouverte à tous ceux qui voudrons tester LISP avant de le deployer dans leur > infra. Merci à ceux qui seraient intéressés de se manifester ! > > > > Cdlt, > > Stefano > > > > Le 28 avr. 2014 à 09:57, Arnaud Fenioux <afeni...@gmail.com> a écrit : > > > >> Salut Stéphane, > >> > >> Merci pour ton article, il y a en effet un projet d'implémentation > >> open-source www.openlisp.org > >> un consortium francais s'est monté avec des acteur publics tels que le > >> LIP6, ParisTech et RENATER ainsi que des acteurs privés : > >> lisplab.openlisp.org > >> Du coté de rezopole on commence tout juste le déploiement et les tests > donc > >> je ne peux pas encore te faire de retour d'expérience, mais ca pourrait > >> faire l'objet d'une présentation lors d'un prochain FRnOG! > >> > >> Arnaud > >> > >> > >> 2014-04-23 9:10 GMT+02:00 Stephane Bortzmeyer <bortzme...@nic.fr>: > >> > >>> Bon, qui ici, a déployé LISP et a une expérience à comparer aux > >>> conseils du RFC ? [Pas moi] > >>> > >>> RFC 7215 : LISP Network Element Deployment Considerations > >>> > >>> http://www.bortzmeyer.org/7215.html > >>> > >>> ---------------------------- > >>> > >>> Auteur(s) du RFC: L. Jakab (Cisco > >>> Systems), A. Cabellos-Aparicio, F. Coras, J. Domingo-Pascual > >>> (Technical University of Catalonia), D. Lewis (Cisco > >>> Systems) > >>> > >>> ---------------------------- > >>> > >>> > >>> Le protocole réseau LISP a été normalisé il y a plus d'un an et > >>> plusieurs déploiements de taille significative ont déjà eu lieu. La > >>> norme LISP n'impose pas un modèle unique de déploiement et laisse bien > >>> des choix à la discrétion de l'administrateur réseaux sur le terrain, > >>> notamment pour le placement des différents éléments qui composent un > >>> réseau LISP. Ce nouveau RFC fait le point sur les différents modèles de > >>> déploiement possibles. Il est donc orienté vers les opérationnels, ceux > >>> (et celles) qui vont déployer LISP en production. > >>> > >>> Petit rappel, LISP vise à résoudre le problème de la croissance de la > >>> table de routage globale de l'Internet (problème décrit dans le RFC > >>> 4984), par le moyen d'une séparation entre *identificateurs*, les EID > >>> ("Endpoint IDentifiers") et les *localisateurs*, les RLOC ("Routing > >>> LOCators"). LISP est normalisé dans le RFC 6830. À l'heure actuelle, > >>> les RFC sur LISP ont le statut « expérimental » (y compris ce RFC > >>> 7215), reflétant le caractère assez disruptif de ce protocole. Il n'y a > >>> notamment aucune solution aux différents problèmes de sécurité étudiés > >>> dans la section 15 du RFC 6830. > >>> > >>> Un principe essentiel de LISP est la distinction faite entre les > >>> réseaux de bordure, qui ne travaillent qu'avec des EID, et le cœur de > >>> l'Internet qui ne travaille qu'avec des RLOC. Mais où placer la > >>> frontière, frontière d'autant plus importante que c'est là où vont > >>> devoir se situer les routeurs LISP (les routeurs de bordure et du cœur > >>> sont, eux, des routeurs IP non modifiés) ? L'idée initiale était que la > >>> frontière était aux limites des AS « feuille », ceux qui n'ont pas de > >>> trafic de transit. Mais, en fait, LISP permet plusieurs choix. Un > >>> « site LISP » peut être un AS feuille mais peut aussi être un simple > >>> réseau local. > >>> > >>> LISP tunnele les paquets d'un site LISP à l'autre, à travers le cœur. > >>> Le routeur LISP, connecté à la fois à la bordure et au cœur se nomme un > >>> ITR ("Ingress Tunnel Router") à l'entrée (encapsulation des paquets) et > >>> un ETR ("Egress Tunnel Router") à la sortie (décapsulation des > >>> paquets). Quand on veut parler des deux types en même temps, on dit > >>> juste « un xTR ». > >>> > >>> Passons maintenant aux scénarios, section 2.1. Premier scénario > >>> possible de déploiement, le « "Customer Edge" ». Le routeur LISP est > >>> dans les locaux du client, contrôlé par lui, et sur la frontière entre > >>> réseau du client et réseau de l'opérateur. Ce sera a priori le cas le > >>> plus fréquent chez les LISPiens et c'est la solution recommandée par > >>> notre RFC. A priori, si on déploie LISP, c'est qu'on a un réseau de > >>> grande taille, "multi-homé", et qu'on souhaite faire de la gestion de > >>> trafic (faire entrer le trafic Internet préferentiellement par un des > >>> opérateurs, par exemple). Dans le scénario "Customer Edge", le client a > >>> le complet contrôle des xTR et peut déployer les politiques qu'il veut > >>> sans rien demander à personne. L'information de joignabilité des ETR, > >>> si importante en LISP, peut être maintenue correctement, tous les > >>> routeurs LISP étant sous le contrôle de la même organisation. Les > >>> "Locator Status Bits" mis par l'ITR sont également toujours conformes à > >>> la réalité. > >>> > >>> Autre avantage, le réseau interne, son plan d'adressage, son protocole > >>> de routage et ses régles de filtrage ne changent pas. > >>> > >>> Comme toutes les techniques utilisant des tunnels, LISP est très > >>> sensible aux problèmes de MTU (RFC 4459), le tunnel consommant quelques > >>> octets qui vont diminuer la MTU du lien. Si la connexion entre le > >>> client et son opérateur a une MTU supérieure aux traditionnels 1 500 > >>> octets d'Ethernet, il n'y a pas de problème. Sinon, ce scénario peut > >>> entraîner des problèmes de MTU. > >>> > >>> Second scénario possible, le « "Provider Edge" ». Cette fois, on met > >>> les xTR chez l'opérateur, sous son contrôle. Le client n'a pas à mettre > >>> à jour ses routeurs, ou à les configurer. Et, avec un seul xTR, > >>> l'opérateur peut servir plusieurs clients LISP. > >>> > >>> Par contre, cela fait perdre à LISP une de ses principales qualités, la > >>> possibilité de contrôler la répartition du trafic entrant ("ingress > >>> traffic engineering"). En effet, les xTR ne sont plus sous le contrôle > >>> du client. Et si le client est "multi-homé", c'est encore pire, les xTR > >>> étant chez des opérateurs concurrents. > >>> > >>> Les xTR qui servent un site LISP n'étant plus coordonnés, ils ne vont > >>> pas forcément avoir de l'information correcte et à jour sur la > >>> joignabilité, et ne pourront donc pas servir cette information. > >>> > >>> Par contre, ce scénario peut limiter les risques d'un problème de MTU, > >>> les xTR étant directement dans le réseau de l'opérateur, où la MTU > >>> disponible est souvent plus grande. > >>> > >>> Mais on peut commettre des perversions bien pires avec LISP. Par > >>> exemple, on peut mettre les xTR derrière des routeurs NAT, par exemple > >>> si on n'a pas assez d'adresses IPv4. Dans ce troisième scénario, l'ITR > >>> encapsule les paquets qui sont ensuite NATés. Attention, les paquets > >>> LISP "Map Requests" n'auront alors pas le même en-tête IP que les "Map > >>> Reply" correspondants, qui seront alors jetés par le routeur NAT. Il > >>> faudra une configuration explicite (par exemple diriger tous les > >>> paquets UDP de port source 4342 vers l'ITR) pour éviter cela. > >>> > >>> Ce RFC ne s'arrête pas à ces trois scénarios possibles. Il décrit aussi > >>> comment les fonctions LISP peuvent être réparties dans divers > >>> équipements. Par exemple, les fonctions d'ITR et d'ETR ne sont pas > >>> forcément présentes dans le même boîtier. On a le droit de les placer > >>> dans deux routeurs différents, par exemple pour mettre les ITR très > >>> près des machines terminales, afin d'encapsuler le plus tôt possible. > >>> > >>> Comme toutes les solutions de séparation de l'identificateur et du > >>> localisateur, LISP dépend énormément des mécanismes de correspondance > >>> (RFC 6833), permettant de trouver un localisateur (RLOC) lorsqu'on > >>> connait l'identificateur (EID). Pour résoudre le problème de > >>> "bootstrap", les serveurs de correspondance doivent être désignés par > >>> des RLOC uniquement. Le système de correspondance a deux composants, > >>> les "Map Servers" et les "Map Resolvers". Voyons d'abord les premiers > >>> (section 3.1). > >>> > >>> Les "Map Servers" apprennent la correspondance EID->RLOC de leurs ETR > >>> (message "Map Register") et publient ensuite cette information, par > >>> exemple via le protocole ALT (RFC 6836) ou via le protocole DDT. ALT > >>> s'inspire plutôt de BGP, DDT plutôt du DNS. Les gérants des "Map > >>> Servers" se nomment les MSP ("Mapping Service Provider"). Ils peuvent > >>> être opérateurs réseaux ou bien des organisations spécialisées dans le > >>> service de correspondance, se faisant payer pour publier un préfixe EID > >>> (section 5.2). A priori, les bonnes pratiques existantes pour la > >>> gestion de BGP s'appliquent à ALT, et celles pour le DNS à DDT. Mais > >>> notre RFC ne va pas plus loin : il est encore trop tôt pour graver dans > >>> le marbre de strictes politiques pour les gérants de "Map Servers". > >>> > >>> DDT est arborescent et repose donc sur une racine > >>> <http://ddt-root.org/>. Cette racine est actuellement gérée par > >>> plusieurs organisations volontaires. Comme pour la racine du DNS, elle > >>> est servie par plusieurs serveurs, chacun géré par une organisation > >>> différente, et désignés par une lettre de l'alphabet grec. Au moins un > >>> de ces serveurs est "anycasté". La racine doit normalement vérifier que > >>> les organisations qui enregistrent un EID sont autorisés à le faire, > >>> via un RIR qui leur a attribué le préfixe en question. > >>> > >>> Et les "Map Resolvers" (section 3.2) ? Leur travail (RFC 6833) est de > >>> recevoir des requêtes "Map Request", typiquement envoyées par un ITR, > >>> de trouver une correspondance EID->RLOC dans la base de données > >>> distribuée, et de la renvoyer au demandeur. (Les habitués du DNS > >>> peuvent se dire qu'un "Map Server" est un « serveur faisant autorité » > >>> et un "Map Resolver" un « résolveur » ou « serveur récursif ».) Vu > >>> leurs « clients », les "Map Resolvers" ont tout intérêt à être situés > >>> près des ITR qu'ils servent. > >>> > >>> Les ITR vont devoir être configurés avec les adresses de leurs "Map > >>> Resolvers". Un préfixe "anycast" (RFC 4786) commun faciliterait cette > >>> tâche, l'ITR trouvant ainsi automatiquement le résolveur le plus proche > >>> et donc en général le plus rapide. > >>> > >>> Comme toute technologie nouvelle sur le réseau, LISP doit faire face au > >>> problème de la coexistence avec les anciens systèmes. Aujourd'hui, il y > >>> a peu de sites LISP. Ceux-ci doivent donc se poser la question de la > >>> coexistence avec les sites non-LISP. Plusieurs techniques sont > >>> envisagées pour cela, comme les P-ITR, "Proxy ITR" du RFC 6832. Un site > >>> LISP qui veut envoyer des paquets à un site non-LISP peut le faire > >>> simplement en n'utilisant pas l'encapsulation LISP. Par contre, pour en > >>> recevoir, il *doit* déployer une technique comme le P-ITR. > >>> > >>> Et puisqu'on parle de coexistence avec les sites non-LISP, il faut > >>> aussi envisager le processus de migration provisoire depuis l'état > >>> actuel vers LISP (section 5 et annexe A). Le RFC est ambitieux, partant > >>> de l'état initial (peu de sites LISP) en allant vers un état > >>> intermédiaire où il y aurait une majorité de sites LISP, pour terminer > >>> par un Internet complètement LISPisé. > >>> > >>> Au début, un site LISP n'a pas le choix. Sauf à ne communiquer qu'avec > >>> les autres sites LISP, il a intérêt à annoncer ses préfixes dans le > >>> "Map system" LISP mais aussi en BGP, pour que les sites non-LISP > >>> sachent où le trouver. On notera donc que, dans cette situation, LISP > >>> ne contribue guère à la réduction de la table de routage globale, > >>> puisque tous les réseaux doivent toujours être publiés dans BGP. > >>> Heureusement, au fur et à mesure que le nombre de sites LISP augmente, > >>> il y aura de moins en moins besoin d'utiliser les techniques de > >>> "traffic engineering" pour contrôler les flux de données. Comme ces > >>> techniques (par exemple la désagrégation des préfixes) sont largement > >>> responsables de la croissance de la table de routage globale, LISP aura > >>> donc déjà un intérêt concret à ce stade (encore lointain). > >>> > >>> On l'a vu, l'inconvénient de cette méthode (annoncer les préfixes en > >>> BGP) est qu'on ne diminue pas la taille de la DFZ. Pire, si on est un > >>> nouveau réseau sans infrastructure BGP existante, on augmente cette > >>> taille. Pour ces réseaux neufs, notre RFC recommande donc plutôt de ne > >>> pas déployer BGP du tout et d'utiliser les P-ITR. C'est alors le > >>> titulaire d'un préfixe englobant qui annonce le préfixe et le route > >>> vers les ETR du client. Ainsi, il n'y a pas de désagrégation des > >>> préfixes. Par contre, l'opérateur qui fournit ce service doit router > >>> tout le trafic non-LISP du client, ce qui n'est pas forcément > >>> raisonnable si c'est un gros client (comparez cela aux tunnels IPv6 que > >>> fournissent gratuitement des opérateurs comme Hurricane Electric : cela > >>> n'est réaliste que si le trafic est faible). Le problème disparaitra > >>> petit à petit si LISP se développe, lorsqu'il n'y aura plus que des > >>> reliquats non-LISP (on en est très loin). > >>> > >>> L'annexe A du RFC décrit un plan de migration concret pour les > >>> responsables opérationnels, sous forme d'une liste d'étapes, avec des > >>> points à vérifier à chaque étape : > >>> * Faire un état des lieux quantitatif du réseau, pour avoir combien de > >>> paquets par seconde et de bits par seconde il faudra acheminer. > >>> * Vérifier les capacités LISP des routeurs existants : peuvent-ils être > >>> utilisés ou bien va t-il falloir en acheter d'autres ? > >>> * Faire bien attention aux questions de MTU, LISP utilisant des > >>> tunnels. Si tous les liens externes peuvent accepter une MTU de 1 556 > >>> octets, parfait. Dans tous les cas, testez que cela passe et qu'il n'y > >>> a pas un pare-feu trop zélé qui bloque les messages ICMP indispensables > >>> à la découverte de la MTU du chemin. > >>> * Vérifiez que vos préfixes IP sont utilisables pour LISP. Si c'est du > >>> PI, pas de problème. > >>> * Configurez les routeurs LISP. > >>> * Testez la joignabilité des ETR (par exemple avec ping) et > >>> l'enregistrement des préfixes avec lig (RFC 6835). > >>> * etc (la liste est longue...) > >>> > >>> > >>> --------------------------- > >>> Liste de diffusion du FRnOG > >>> http://www.frnog.org/ > >>> > >> > >> --------------------------- > >> Liste de diffusion du FRnOG > >> http://www.frnog.org/ > >> > > > > -- > > Stefano Secci > > Associate Professor > > Univ. Pierre and Marie Curie > > LIP6 - Bureau 25-26/318, BC 169 > > 4 place Jussieu, 75005 Paris, France > > Tel: +33 (0) 1 4427 3678 > > http://www-phare.lip6.fr/~secci/ > > > > > > --------------------------- > > Liste de diffusion du FRnOG > > http://www.frnog.org/ > > --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
