Re: [FRnOG] [TECH] RFC 7215: LISP Network Element Deployment Considerations
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
Re: [FRnOG] [TECH] RFC 7215: LISP Network Element Deployment Considerations
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
Re: [FRnOG] [TECH] RFC 7215: LISP Network Element Deployment Considerations
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
[FRnOG] [TECH] RFC 7215: LISP Network Element Deployment Considerations
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
