From: Stefano Secci <[email protected]<mailto:[email protected]>> Date: Fri, 2 Sep 2011 22:26:58 +0200 To: Moi Maunier <[email protected]<mailto:[email protected]>> Cc: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Re: [FRnOG] Re: [FRnOG] Le troll de la liste du FRnOG est rentré de vacances!
:) en quelques mots avec ton peer tu associe un ou plusieurs flots de tes clients par le peering à un ou plusieurs flots de ton peer vers toi il faut qu'ils s'équivalent, par ex par rapport à la bande, ou réputation, ou autre... (ce peut se contrôler par usage des communautés BGP) Communautés BGP avec un peer ? Ou sur ton backbone ? juste pour les identifier de ton coté, mais pourquoi pas bilatérales si ça peut aider... Bilatérale, ça risque d'être super compliqué et surtout impossible à transcrire et surtout impossible de maitriser ton trafic. Si tu passes les communautés de tes peers ou de tes transit directement à tes clients, forcément il y aura forcément un moment ou tu n'aura plus le contrôle de ton backbone. pour ce(s) couple(s) de flots, vous faites conjointement du routage d'equilibre, disons du "mild potato", en utilisant les cout de transit IGP des deux cotés, éventuellement normalisés (ce peut se faire en utilisant différemment le MED et avec un petit changement aux décisions BGP sur certaines communautés - nb: eq. localpref et hop count, en anticipant le hotpotato De mémoire, le seul opérateur vraiment gros qui rentre dans les cases et qui acceptait les MED était Abovenet. De mémoire, ce n'était pas vraiment utilisé par les peers, mais je peux me tromper car je n'avais pas une vision complète du réseau quand on le gérait en France. oui oui, mais la c'est un objectif nouveau, pour utiliser différemment le MED la où normalement ça n'a pas de sens voir ce ppt un peu daté, mais toujours d'actualité: http://www-phare.lip6.fr/~secci/papers/NGI2009-Secci.ppt C'est chaud quand même. Sérieusement, c'est trop complexe pour l'implémenter. Utiliser les MED avec un gros peer , ça aurait du sens, mais sur l'ensemble de tes petits peers, tu ne le fera jamais. On ne s'est jamais pris la tête à faire autant de calcul pour équilibrer le trafic. On a préféré acheter Arbor qui le fait en 3 clics et ne pas se prendre la tête dessus Ceci étant, avec la chute vertigineuse des prix du transit et l'optimisation des couts, pourquoi pas étudier une nouvelle façon de gérer ces peerings avec des maths. A la rigueur, étant client Arbor, je pourrais leur demander d'implémenter ces fonctions dans les prochaines releases / beta. Déjà l'ingénierie a une réputation de geek au sein des opérateurs, si on embauche des matheux en plus, je crois que ça va être pire :) Pour Thomas, un ppt vaut mieux que mille paroles? ;) plus d'équilibres tu prends, plus cold (ou moins chaud) le routage de peering sera avec plusieurs équilibres, c'est du multi-chemin niveau AS, utile s'il y a bcp de liens de peering et si ça fluctue bcp peut-etre pas très néutrale, mais mieux que du paid peering partout, non? Dans la pratique, ou la vraie vie avec du vrai trafic. Tu montes des intercos un peu partout et tu surveilles avec ton netflow. Si ça pousse trop , soit tu upgrades soit tu contacte ton peer et tu trouve une solution ! Ensuite, si tu as beaucoup beaucoup de trafic, tu achètes Arbor et s'il te reste un peu de pognon, ben c'est Cariden en plus ! Cependant, ce serait intéressant de travailler sur le sujet avec du trafic sur un vrai AS. Le 2 sept. 2011 à 21:56, Raphael MAUNIER a écrit : Ah ouais quand même ! Si je prend autant de temps à analyser avec ces formules toutes les demandes de peering, je crois que ça risque de prendre du temps. J'ai eu mal à la tête rien qu'en faisant un "scroll" sur le document :) -- Raphaël Maunier NEO TELECOMS CTO / Directeur Ingénierie AS8218 From: Stefano Secci <[email protected]<mailto:[email protected]>> Reply-To: Stefano Secci <[email protected]<mailto:[email protected]>> Date: Fri, 2 Sep 2011 21:39:44 +0200 To: Michel Py <[email protected]<mailto:[email protected]>> Cc: <[email protected]<mailto:[email protected]>> Subject: [FRnOG] Re: [FRnOG] Le troll de la liste du FRnOG est rentré de vacances! Le 2 sept. 2011 à 19:04, Michel Py a écrit : Bien d'accord, mais en fait ce qui m'a le plus choqué c'est la suggestion de changer le hot potato pour du cold potato. A mon avis, c'est de la folie furieuse; hot potato est la manière dont ça marche naturellement, le changer ça va créer une usine à gaz. C'est de l'ingénierie de réseau par les droides des ventes, AMHA. Sérieusement, cold potato dans le core? in medio stat virtus, disaient les latins On peut modéliser analytiquement hot & cold potato, en contrôlant au même temps la congestion de peering, et en donnant la priorité à l'égoïsme sur l'altruisme, pour produire des solutions de routage efficaces et stratégiquement justifiées qui suivent un ou plusieurs équilibres du jeu non-coopératif correspondant. Tout est la: http://www-phare.lip6.fr/~secci/papers/SeRoPaPaMa-ToN-11.pdf Bonne lecture! Et tout commentaire bienvenu ;) -- Stefano Secci Associate Professor PHARE - LIP6 - UPMC - Sorbonne Universités Bureau 25-26/318, Boite Courrier 169 4 place Jussieu, 75005 Paris, France Tel: +33 (0) 1 4427 3678 Fax: +33 (0) 1 4427 8783 http://www-phare.lip6.fr/~secci/ -- Stefano Secci Associate Professor PHARE - LIP6 - UPMC - Sorbonne Universités Bureau 25-26/318, Boite Courrier 169 4 place Jussieu, 75005 Paris, France Tel: +33 (0) 1 4427 3678 Fax: +33 (0) 1 4427 8783 http://www-phare.lip6.fr/~secci/ -- Stefano Secci Associate Professor PHARE - LIP6 - UPMC - Sorbonne Universités Bureau 25-26/318, Boite Courrier 169 4 place Jussieu, 75005 Paris, France Tel: +33 (0) 1 4427 3678 Fax: +33 (0) 1 4427 8783 http://www-phare.lip6.fr/~secci/
