Re: BGP design flaw, was: (Re: [FRnOG] Re: RFC 5963: IPv6 Deployment in Internet Exchange Points)
On Sat, 4 Sep 2010 13:26:50 +0200, Jerome Benoit jerome.ben...@grenouille.com said: Je vais le formuler autrement : ta politique de routage dynamique pour les échanges en Unicast est conditionnée par les fonctionnalités proposées par les logiciels qui l'implémenteront. Ma politique de routage est surtout conditionne par mes interets (enfin, ceux de mon entreprise). Le fait que le BGP manque une moyen efficace pour specifier le chemin entrant, ca m'embete moins que le fait que les politiques de routage des autres suivent des interets qui sont parfois differents (lire opposes) des miens. Si a ce jour il n'y a pas (ou c'est juste un truc de labo) d'EGP qui permet de specifier un chemin en multi-hop, dans les deux sens, c'est probablement aussi parce-que certains operateurs (certains tres grands, certains petits) n'en veulent pas sur leur reseau. Supposant que j'ai a ma disposition ton super-mega protocole, et qu'en tant que client Cogent et non-client Telia, je decide de specifier que le Chemin de vmi vers FT doit etre Cogent-Telia-FT. Tu crois que tout le monde sur le chemin sera d'accord ? Ou tu crois qu'expliquer via ton protocole a TGN(je suis client) et GBLX(pas client) que le traffic en *provenance* d'amerique du sud doit suivre le meme chemin que celui a *destination* d'amerique du sud c'est du doimaine du realisable ? digression /digression TON noyau, TON systeme, TA modification du noyau, pour TES besoin. Tu as le loisir de faire ce que tu veux. En l'occurrence, je voudrais surtout que la personne en face prenne réellement en considération les faiblesses de BGP de manière objective :) Le BGP ne sait pas non plus laver la vaiselle et la linge ce que tu appelles faiblesse certains appellent une non-issue/non-probleme. -- Radu-Adrian Feurdean raf (a) ftml ! net --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: BGP design flaw, was: (Re: [FRnOG] Re: RFC 5963: IPv6 Deployment in Internet Exchange Points)
Le Mon, 06 Sep 2010 10:44:34 +0200, Radu-Adrian Feurdean r...@ftml.net a écrit : Je me suis tâter avant de répondre mais finalement ... Je vais le formuler autrement : ta politique de routage dynamique pour les échanges en Unicast est conditionnée par les fonctionnalités proposées par les logiciels qui l'implémenteront. Ma politique de routage est surtout conditionne par mes interets (enfin, ceux de mon entreprise). Le fait que le BGP manque une moyen efficace pour specifier le chemin entrant, ca m'embete moins que le fait que les politiques de routage des autres suivent des interets qui sont parfois differents (lire opposes) des miens. Si a ce jour il n'y a pas (ou c'est juste un truc de labo) d'EGP qui permet de specifier un chemin en multi-hop, dans les deux sens, c'est probablement aussi parce-que certains operateurs (certains tres grands, certains petits) n'en veulent pas sur leur reseau. Supposant que j'ai a ma disposition ton super-mega protocole, et qu'en tant que client Cogent et non-client Telia, je decide de specifier que le Chemin de vmi vers FT doit etre Cogent-Telia-FT. Tu crois que tout le monde sur le chemin sera d'accord ? Ou tu crois qu'expliquer via ton protocole a TGN(je suis client) et GBLX(pas client) que le traffic en *provenance* d'amerique du sud doit suivre le meme chemin que celui a *destination* d'amerique du sud c'est du doimaine du realisable ? La réalisation est possible dans la limite ou il existe une concurrence sur les protos et/ou implémentation de gestion du routage dynamique entre AS. Pour le moment, elle n'existe pas. Donc toutes manières de penser autrement les échanges entre AS n'est pas possible. digression /digression TON noyau, TON systeme, TA modification du noyau, pour TES besoin. Tu as le loisir de faire ce que tu veux. Nullement, quand j'administre des machines, je le fais en suivant les codes éthiques élémentaires des admin sys et les conditions légales contractuelles éventuelles que j'ai signé avec mon client. Les données sur la machine ne sont pas à moi ainsi que l'OS, si je dois surveiller ce qu'il se passe dessus, je le fais de la manière la plus éthique et élégante possible en respectant les conditions légales contractuelles. En clair, si je peux appliquer contractuellement des patches pour optimiser certaines contraintes d'exploitation, je le fais. Mais je dois être un dinosaure ... :) En l'occurrence, je voudrais surtout que la personne en face prenne réellement en considération les faiblesses de BGP de manière objective :) Le BGP ne sait pas non plus laver la vaiselle et la linge ce que tu appelles faiblesse certains appellent une non-issue/non-probleme. Tu iras expliquer çà à l'admin qui gère BGP sur chaque peering/transit d'un gros opérateur quand il sera averti par son cacti/whatever d'un pic inattendue de trafic entrant sur son AS que son infra a du mal à encaisser malgré tous ses efforts en amont pour essayer de gérer ce cas de figure et qu'il devra rapidement intervenir sans se rater sur les configs BGP. a +. -- Jérôme Benoit aka fraggle La Météo du Net - http://grenouille.com OpenPGP Key ID : 9FE9161D Key fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D pgpb5jfjs5nL2.pgp Description: PGP signature
Re: BGP design flaw, was: (Re: [FRnOG] Re: RFC 5963: IPv6 Deployment in Internet Exchange Points)
Le Sat, 04 Sep 2010 06:58:58 +0200, Radu-Adrian Feurdean r...@ftml.net a écrit : Ca n'a rien a voir avec le BGP. Par son nature, l'IP (v4 et v6) est route selon la destination, et uniquement le next-hop est controlable. Pour suivre un chemin precis, il faut *UNE* politique de routage (pas plusieurs), ce qui est possible a l'interieur d'un AS, mais totalement irealiste entre plusieurs AS. Je vais le formuler autrement : ta politique de routage dynamique pour les échanges en Unicast est conditionnée par les fonctionnalités proposées par les logiciels qui l'implémenteront. Et c'est pas parce que tu as l'habitude de la définir avec le logiciel Z et que avec le logiciel Z, tu arrives à faire à avoir ce qu'il te convient en ajustant certains paramètres du logiciel Z. Moi je te dis que le logiciel Z a des limitations (de celles qui n'ont rien à voir avec la nature du réseau de commutation de paquets sous-jacent) et certaines de ces limitations conduisent à des choix sub-optimaux de politique de routage. Si tu veux pas entendre cet argument, on va briser là cette discussion. digression POSIX ne définit aucune interface pour surveiller les modifications dans un filesytem. Solution 1 : je programme cette surveillance en scannant comme un bourrin les fichiers de mes FS et en les contrôlant par checksumming. Solution 2 : j'ajoute dans le noyau de mon OS un appel système ancré proprement dans le couche de gestion des FS qui me permet de récupérer par exemple un tableau de pointer vers le nom des fichiers modifiés pendant un interval de temps ce qui me permet de scanner de manière incrémentale mes FS. Je te le dis tout de suite, le préfère la solution 2 même si les deux sont viables. /digression Ah, si tu veux passer de X a Y en passant par Z (X, Y, Z = AS), tu n-as qu'a bidouiller le localpref, et ca en supposant que tes upstreams/peers *VEULENT* faire passer le traffic pas as Z. S'ils veulent pas, cherche un autre. Essaye de peerer/acheter du transit chez Z !!! En l'occurrence, je voudrais surtout que la personne en face prenne réellement en considération les faiblesses de BGP de manière objective :) a +. -- Jérôme Benoit aka fraggle La Météo du Net - http://grenouille.com OpenPGP Key ID : 9FE9161D Key fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D pgp2Ath17OW7p.pgp Description: PGP signature
Re: BGP design flaw, was: (Re: [FRnOG] Re: RFC 5963: IPv6 Deployment in Internet Exchange Points)
On Thu, 2 Sep 2010 21:01:35 +0200, Jerome Benoit jerome.ben...@grenouille.com said: Je vois pas comment tu résous _proprement_ les autres pbs de BGP sans introduire un minimum de notion de symétrie dans les échanges de prefix. J'ai mon AS, X, et j'ai du traffic avec l'AS Y. Dans enormement de cas, AS Y ne sait meme pas que j'existe, alors qu mois j'envoie plus de 10% de mon traffic vers eux. Le traffic d'eux vers moi passe par des endroits que je controle pas, et il n'y a pas beaucou [de moyen de faire changer ca. De mon cote, par contre, j'ai mon propre interet que ca sort par un endroit precis. Si les deux ne sont pas les memes (j'envoie vers Y via AS A, mais je recois le traffic de chez eux via AS B) et qu'il n'y a pas moyen de fair changer le routage cote AS Y, je fais quoi ? Supposant que je trouve un moyen de regler le probleme vers l'AS Y, comment je fais pour faire ca en meme temps vers les AS Z, T, W et Q ? Pour moi, l'asymetrie est quelque-chose de tres important, comme pour beaucoup d'autres reseaux content. Si je voulais de la symetrie, j'aurais reste end user, sans AS, en utilisant les PA d'un certain operateur. Bien-sur, pas de multi-homing dans ce cas-la, et epargnez-moi des histoires du style LISP co. -- Radu-Adrian Feurdean raf (a) ftml ! net --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: RFC 5963: IPv6 Deployment in Internet Exchange Points
On Thu, Sep 02, 2010, Jrme Nicolle wrote: Autre cas typique, imagine un grand réseau national d'eyeball qui reçoit tout youredpornmotiontube via l'AMS-IX. Les vendeurs de video se chient dessus, ou l'AMS-IX plante (un jour ou le RIPE a le vent dans le dos, par exemple), et pouf, tout le trafic se reporte sur un autre IX, en général DECIX ou LINX. 500 Gbps qui changent de route d'un coup. Tous les liens qui se mettent à saturer. Ca te rapelle quelque chose ? Comment tu fais, dans ce genre decas de figure pour t'entendre avec tous les fournisseurs de contenus pour équilibrer entre les IX plutot que de tout balancer sur un ou deux seuls liens ? S'il y a vraiment 500 Gbit/s de trafic qui passent à un endroit unique, les différents réseaux (celui qui émet, celui qui transporte, celui qui reçoit pour ses utilisateurs) doivent faire en sorte que ces 500 Gbit/s puissent passer ailleurs. Il est trop facile de dire ouiii ça sature partout dans mon réseau, c'est la faute à BGP. De manière plus vraissemblable, avec un volume de 500 Gbit/s, il y a de fortes chances que le trafic soit déjà réparti un peu partout en entrée de l'AS, disons 50 Gbit/s par PoP d'entrée. De nombreux contrats de peering demandent d'ailleurs un envoi du trafic au plus proche. Et il n'y a rien de plus facile à faire avec BGP. Dans ce cas, si un PoP passe dans le noir, les autres reçoivent alors environ 55,55 Gbit/s de trafic. Si on ne remplit pas à plus de 70-75 % les points d'entrée de son AS, ça ne posera pas de problème. La vraie difficulté, c'est que TOUT le monde se conforme à ces bonnes pratiques. Et ce n'est pas un nouveau protocole qui pourra changer la politique de gestion des réseaux. -- Raphael Bouaziz. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: BGP design flaw, was: (Re: [FRnOG] Re: RFC 5963: IPv6 Deployment in Internet Exchange Points)
Le Fri, 03 Sep 2010 14:57:36 +0200, Radu-Adrian Feurdean r...@ftml.net a écrit : Pour moi, l'asymetrie est quelque-chose de tres important, comme pour beaucoup d'autres reseaux content. J'ai pas dit que c'était pas important, j'ai dit que çà entraine des choix sub-optimaux de routes pour les échanges en Unicast dès qu'on traverse plusieurs AS. C'est juste un fait. Je peux le dire sans me faire écharper SVP ? ;) Que çà soit un choix raisonné du design de BGP pour répondre à un besoin en son temps n'exclue pas que çà pose des pbs. Si je voulais de la symetrie, j'aurais reste end user, sans AS, en utilisant les PA d'un certain operateur. Si tu avais eu l'option d'avoir de la symétrie là ou tu en aurais eu besoin, tu l'aurais jeté à la poubelle par principe ? :) Bien-sur, pas de multi-homing dans ce cas-la, et epargnez-moi des histoires du style LISP co. Je vois pas le rapport avec le multi-homing, et LISP parle d'autre chose. a +. -- Jérôme Benoit aka fraggle La Météo du Net - http://grenouille.com OpenPGP Key ID : 9FE9161D Key fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D pgpAFLiCFwMW4.pgp Description: PGP signature
Re: BGP design flaw, was: (Re: [FRnOG] Re: RFC 5963: IPv6 Deployment in Internet Exchange Points)
Le 03/09/2010 22:07, Radu-Adrian Feurdean a écrit : Routage symetrique pour moi c'est juste de la coincidence. Tu veux de la symmetrie ? Essaye le reseau telephonique (et encore.) Je te confirme en réseau téléphonie on est bien symétrique :) Bon d'accord je sorts ;) --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: BGP design flaw, was: (Re: [FRnOG] Re: RFC 5963: IPv6 Deployment in Internet Exchange Points)
On Fri, 3 Sep 2010 23:22:33 +0200, Jerome Benoit jerome.ben...@grenouille.com said: Le Fri, 03 Sep 2010 22:07:28 +0200, Radu-Adrian Feurdean r...@ftml.net a écrit : Routage symetrique pour moi c'est juste de la coincidence. Je parlais pas de çà, ni du fait que le reverse path doit être identique au forward path. Je parle de la manière dont BGP calcule un Justement, NON ! Si jamais ca arrive, c'est du pur hazard. routage stable entre AS *sans* prendre en compte ce qu'il fait rentrer dans un AS et j'ai franchement du mal à appeler çà une fonctionnalité pour toutes les raisons sus-citées. Ca n'a rien a voir avec le BGP. Par son nature, l'IP (v4 et v6) est route selon la destination, et uniquement le next-hop est controlable. Pour suivre un chemin precis, il faut *UNE* politique de routage (pas plusieurs), ce qui est possible a l'interieur d'un AS, mais totalement irealiste entre plusieurs AS. Ah, si tu veux passer de X a Y en passant par Z (X, Y, Z = AS), tu n-as qu'a bidouiller le localpref, et ca en supposant que tes upstreams/peers *VEULENT* faire passer le traffic pas as Z. S'ils veulent pas, cherche un autre. Essaye de peerer/acheter du transit chez Z !!! -- Radu-Adrian Feurdean raf (a) ftml ! net --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: RFC 5963: IPv6 Deployment in Internet Exchange Points
On Wed, Sep 01, 2010 at 10:48:58PM +0200, Jerome Benoit wrote: Ça serait franchement plus simple de corriger les pbs inhérents à la conception de BGP. Peux-tu détailler ces problèmes ? -- Bertrand Yvain http://www.IELO.net/ signature.asc Description: Digital signature
Re: [FRnOG] Re: RFC 5963: IPv6 Deployment in Internet Exchange Points
Le Thu, 2 Sep 2010 10:06:51 +0200, Bertrand Yvain p...@ielo.net a écrit : On Wed, Sep 01, 2010 at 10:48:58PM +0200, Jerome Benoit wrote: Ça serait franchement plus simple de corriger les pbs inhérents à la conception de BGP. Peux-tu détailler ces problèmes ? Par design asymétrique (un AS sait ce qu'il fait sortir, c'est plus difficile pour lui de savoir ce qu'il fait rentrer). * Aucune capacité native d'équilibrage de charge entre chemins; * Pas de gestion de la congestion sur les chemins. On peut travailler autour de ces pbs mais çà reste des workarounds. a +. -- Jérôme Benoit aka fraggle La Météo du Net - http://grenouille.com OpenPGP Key ID : 9FE9161D Key fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D pgpYi0nNdSowl.pgp Description: PGP signature
RE: [FRnOG] Re: RFC 5963: IPv6 Deployment in Internet Exchange Points
Bertrand Yvain p...@ielo.net a écrit : On Wed, Sep 01, 2010 at 10:48:58PM +0200, Jerome Benoit wrote: Ça serait franchement plus simple de corriger les pbs inhérents à la conception de BGP. Peux-tu détailler ces problèmes ? Par design asymétrique (un AS sait ce qu'il fait sortir, c'est plus difficile pour lui de savoir ce qu'il fait rentrer). * Aucune capacité native d'équilibrage de charge entre chemins; * Pas de gestion de la congestion sur les chemins. Certain opérateurs te permettent de setter des communauté aux prefix annoncé pour changer les Local-Pref sur leur réseaux ou pour choisir des politique d'annonce (tes prefix seront ou pas annoncé dans les zone Géographique NA,AP,EMEA). Il est donc possible de gérer par ces mécanismes les flux entrant, il serait possible de généraliser ce principe. On peut travailler autour de ces pbs mais çà reste des workarounds. a +. -- Jérôme Benoit aka fraggle La Météo du Net - http://grenouille.com OpenPGP Key ID : 9FE9161D Key fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D15 FAA0 CB50 9FE9 161D Michael VILLAR -- --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: RFC 5963: IPv6 Deployment in Internet Exchange Points
Le Thu, Sep 02, 2010 at 10:58:39AM +0200, Jerome Benoit [jerome.ben...@grenouille.com] a écrit: Peux-tu détailler ces problèmes ? Par design asymétrique (un AS sait ce qu'il fait sortir, c'est plus difficile pour lui de savoir ce qu'il fait rentrer). Forcément, puisque la décision relève de l'émetteur. Note bien que c'est pareil dans la vraie vie, tu ne choisis pas si quelqu'un va tenter de te joindre par fax, par téléphone, par courrier postal, ... Les communautés proposées par la plupart des transitaires permettent déjà d'ajuster pas mal par où on veut (ou pas) être joint. * Aucune capacité native d'équilibrage de charge entre chemins; Ca, c'est pas vraiemnt à BGP de s'en préoccuper. C'est à l'étape « je mouline les annonces, je fais un choix, je transpose dans la FIB ». Des implémentations capables de mettre plusieurs chemins (multipath) existent déjà. * Pas de gestion de la congestion sur les chemins. Ca je suis d'accord. Mais c'est pareil, ça serait plus au niveau du moteur de décision de tenir compte de la charge des liens et de modifier les scores en fonction. Dans les vrais manques, il y aurait à mentionner une notion de signature des annonces faites. Un peu sur le principe de DKIM en SMTP. Qui permettent d'authentifier que les annonces pour tel préfixe sont bien issus de l'AS qui fait autorité pour le faire. Et j'ai cru comprendre que c'était précisément le sujet d'expérimentation de Duke University qui a tout pété l'Internet :-p -- Dominique Rousseau Neuronnexion, Prestataire Internet Intranet 50, rue Riolan 8 Amiens tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: RFC 5963: IPv6 Deployment in Internet Exchange Points
Michael, Le 02/09/10 11:15, Michael VILLAR a écrit : Certain opérateurs te permettent de setter des communauté aux prefix annoncé pour changer les Local-Pref sur leur réseaux ou pour choisir des politique d'annonce (tes prefix seront ou pas annoncé dans les zone Géographique NA,AP,EMEA). Il est donc possible de gérer par ces mécanismes les flux entrant, il serait possible de généraliser ce principe. Le problème, c'est que c'est assez rare et pas assez granulaire. Tu peux effectivement éviter des allers-retours trans-océaniques avec ce genre de configs, quoique typiquement, c'est pas en place chez certains transitaires quasi-T1. Mais il n'y a pas de consensus pour la mise en place de ce genre de politique sur des zones plus réduites, genre FR ou EU. Cas typique : le peering en région. Entre Free et OVH, ça s'est fait (si j'ai bien tout compris) parce que Free utilisait déjà pas mal de communautés et d'AS privés, et qu'OVH est centralisé. Du coup, ça doit faire 40Gbps de moins à transporter sur les 600km de l'aller retour Lille-Paris. Autre cas typique, imagine un grand réseau national d'eyeball qui reçoit tout youredpornmotiontube via l'AMS-IX. Les vendeurs de video se chient dessus, ou l'AMS-IX plante (un jour ou le RIPE a le vent dans le dos, par exemple), et pouf, tout le trafic se reporte sur un autre IX, en général DECIX ou LINX. 500 Gbps qui changent de route d'un coup. Tous les liens qui se mettent à saturer. Ca te rapelle quelque chose ? Comment tu fais, dans ce genre decas de figure pour t'entendre avec tous les fournisseurs de contenus pour équilibrer entre les IX plutot que de tout balancer sur un ou deux seuls liens ? (bon, c'est encore plus compliqué de s'entendre quand tu veux le faire payer son transport et qu'il te réponds toi tu vas disparaitre du Net) Donc, plusieurs possibilités : - Tu analyses avec un maximum de précision toutes les routes actives de ton réseau et tu modules tes annonces pour chaque session BGP : * Ca oblige à superviser TOUS les liens avec une grande précision, et à scripter des modifications d'annonces assez fines, tout en anticipant les congestions classiques * Tu t'interdis l'usage des route-servers de certains IX qui ne feront pas forcement la distinction entre tes annonces et les routes fournies par tous les peers * Tu dois être proactif et anticiper les variations d'usage (patch-day, botnet,... ) pour pas être pris au dépourvu * Enfin, tu vas fragmenter tes annonces et donc contribuer au morcellement de la table de routage globale. Enfoiré. Mais le principal problème, c'est que ça rends ton réseau statique. A force d'y ajouter des règles d'optimisation et de répartition, tu vas au mieux pas pouvoir t'adapter à un gros incident, faire exploser tes coûts d'exploit et au pire, a force d'ajouter de l'intelligence dans le réseau, en faire une boite noire pas neutre. BOOUHOUHOU ! - Autre option, tu utilises des boitiers d'optimisation BGP. Sur le principe, c'est sensé faire la même chose que ce que je viens d'énoncer, mais en mal. Comme tout est automatisé, forcement, c'est moins efficace. Ces boitiers coutent un bras (ticket d'entrée à 40k€) mais peuvent être de bons compléments car pas de mauvais outils pour la supervision. - Reinventer BGP en y intégrant une meilleur connaissance de l'entourage de l'instance. En fait, ça consisterait à intégrer la supervision des liens et des sessions dans le protocole de base. Le problème là dedans c'est la nécessité pour chaque bordure de connaitre l'état de tout l'interne. Ca induit des contraintes d'interopérabilité énormes parce que la découverte par chaque routeur de toute la topologie est nécessairement complexe. La mise à jour de la topologie interne serait lourde et la moindre erreur aurait un impact énorme. Alors elle pourrait être faite au moins en partie manuellement, et dans ce cas ça ajoute encore une couche d'erreur et un coût à l'exploitation. Outre les problèmes de fragmentation, de quantité de données de supervision à analyser en temps réel, d'interopérabilité, et le risque qu'il y a à rendre les routeurs trop intelligents, tu vas aussi avoir un problème de sécurité et d'exposition de ton réseau. Pour bien fonctionner, et proposer aux voisins des routes efficaces, tu dois leur fournir pas mal d'infos dans tes annonces. A priori suffisamment pour voir, de l'extérieur, tous les points faibles de ta topologie... Il y a enfin le problème du Least Cost Routing. Ce genre de protocoles ou d'approches d'optimisation a principalement pou bute de maximiser l'usage des routes les moins chères, tout en conservant un niveau de qualité acceptable. Price, Speed, Quality, pick two. Ca, tout le monde connait. Qui qui paye cette route là ?, ça viendrait ensuite. Puisque tout le monde a intérêt à optimiser le coût de ses intercos, et que le paid-peering est plus à la mode que les peering-policies constructives, on pourrait finir par assister à un jeu ou je t'envoie les
BGP design flaw, was: (Re: [FRnOG] Re: RFC 5963: IPv6 Deployment in Internet Exchange Points)
Le Thu, 2 Sep 2010 11:21:21 +0200,
Dominique Rousseau d.rouss...@nnx.com a écrit :
Le Thu, Sep 02, 2010 at 10:58:39AM +0200, Jerome Benoit
[jerome.ben...@grenouille.com] a écrit:
Peux-tu détailler ces problèmes ?
Par design asymétrique (un AS sait ce qu'il fait sortir, c'est plus
difficile pour lui de savoir ce qu'il fait rentrer).
Forcément, puisque la décision relève de l'émetteur.
Note bien que c'est pareil dans la vraie vie, tu ne choisis pas si
quelqu'un va tenter de te joindre par fax, par téléphone, par courrier
postal, ...
Le routage sur Internet n'a pas grand chose à voir avec çà.
Les communautés proposées par la plupart des transitaires permettent
déjà d'ajuster pas mal par où on veut (ou pas) être joint.
Je vois pas comment tu résous _proprement_ les autres pbs de BGP sans
introduire un minimum de notion de symétrie dans les échanges de
prefix.
--- path 1 ---
/ \
/\
A - path i B
\/
\ /
--- path n ---
path i = liste hiérarchique d'éléments réseau reliés {(R1,L1);...;
(Rk,Lk)}
Si le système au milieu qui te permet de choisir le chemin optimum
entre A et B en Unicast n'est pas capable de faire le même choix dans
le sens inverse aussi, je vois pas comment tu garanties de manière
optimale les échanges entre A et B, enfin si je vois mais je trouve çà
vraiment pas propre :)
Ceci dit, je vois pas non plus de solution simple sans refaire un BGP
from stratch qui soit par design capable de plus de symétrie ou bien ne
plus avoir de notion d'AS du tout (ahaha) (qui eux en interne gèrent
très bien le pb).
a +.
--
Jérôme Benoit aka fraggle
La Météo du Net - http://grenouille.com
OpenPGP Key ID : 9FE9161D
Key fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D
pgp7ybZ5pjaGE.pgp
Description: PGP signature
[FRnOG] Re: RFC 5963: IPv6 Deployment in Internet Exchange Points
On Tue, Aug 31, 2010 at 02:52:02PM +0200, Julien Reveret shad...@c0a8.org wrote a message of 12 lines which said: Si Internet se transformait en un immense réseau Ethernet, alors je n'imagine même pas la congestion des liens à cause des broadcasts ARP. Tout à fait d'accord. La couche 2 ne passe pas à l'échelle (car tout le monde voit les diffusions). C'est bien justement une plaie des points d'échange (Hello OSPF, ARP dans tous les sens...) --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: RFC 5963: IPv6 Deployment in Internet Exchange Points
On Wed, Sep 01, 2010 at 01:42:25PM +0200, michel hostettler michel.hostett...@telecom-paristech.fr wrote a message of 13 lines which said: Les domaines ont en particulier la possibilité d'être restreints, en particulier au moyen des indicateurs S-VLAN, B-VLAN. Je soupçonne que la configuration de VLAN au niveau planétaire, nécessitant la coopération de Level 3, Pakistan Telecom, Facebook, NTT et OpenTransit, soit bien plus compliquée que l'Internet existant :-) --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: RFC 5963: IPv6 Deployment in Internet Exchange Points
Le Wed, 1 Sep 2010 16:29:05 +0200, Stephane Bortzmeyer bortzme...@nic.fr a écrit : On Wed, Sep 01, 2010 at 01:42:25PM +0200, michel hostettler michel.hostett...@telecom-paristech.fr wrote a message of 13 lines which said: Les domaines ont en particulier la possibilité d'être restreints, en particulier au moyen des indicateurs S-VLAN, B-VLAN. Je soupçonne que la configuration de VLAN au niveau planétaire, nécessitant la coopération de Level 3, Pakistan Telecom, Facebook, NTT et OpenTransit, soit bien plus compliquée que l'Internet existant :-) VTP on steroids ? Ça serait franchement plus simple de corriger les pbs inhérents à la conception de BGP. Personne travaille sur un BBGP (Better Border Gateway Protocol) ? a +. -- Jérôme Benoit aka fraggle La Météo du Net - http://grenouille.com OpenPGP Key ID : 9FE9161D Key fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D pgpxI57mCnyf9.pgp Description: PGP signature
