Le vendredi 02 septembre 2011 à 21:17 +0000, Raphael MAUNIER a écrit : > > > > > > > > From: Stefano Secci <[email protected]> > > Date: Fri, 2 Sep 2011 22:26:58 +0200 > > To: Moi Maunier <[email protected]> > > Cc: "[email protected]" <[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.
Tu ne ferais pas ca. Tu donnerais au mieux des moyens à tes clients d'influencer un peu ta redistribution de ses routes vers ton peer (toujours modulo ton deal avec ton peer, voilà). Cheers, mh > > > > > > > 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]> > > > Reply-To: Stefano Secci <[email protected]> > > > Date: Fri, 2 Sep 2011 21:39:44 +0200 > > > To: Michel Py <[email protected]> > > > Cc: <[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/ > > --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
