On 9/2/11 11:28 PM, "Michael Hallgren" <m.hallg...@free.fr> wrote:


>Le vendredi 02 septembre 2011 à 21:17 +0000, Raphael MAUNIER a écrit :
>> 
>> 
>>         > 
>>         > 
>>         > From: Stefano Secci <stefano.se...@lip6.fr>
>>         > Date: Fri, 2 Sep 2011 22:26:58 +0200
>>         > To: Moi Maunier <rmaun...@neotelecoms.com>
>>         > Cc: "frnog@frnog.org" <frnog@frnog.org>
>>         > 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à).

Ben justement, si tous tes clients pour une raison X décident de ne plus
annoncer vers tel ou tel peer sur tel IXP, tu pourrais basculer des
dizaines de giga d'un point A vers un point B et sans aucun contrôle sur
ce trafic.

Un Tier-1 pour lui c'est plus simple, car la plupart ont moins de 60 peers
unique, non ?
Si tu as 250 peers ou un truc du genre, comment tu sais à un instant T ou
va aller ton traf ? ( approximativement )

J'ai du mal à voir comment tu peux avoir un minimum de vision si tu
laisses trop de possibilités de controle de routage vers tout tes peers à
tes clients ( si tu n'es pas Tier-1 )

>
>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 <stefano.se...@lip6.fr>
>>         >         > Reply-To: Stefano Secci <stefano.se...@lip6.fr>
>>         >         > Date: Fri, 2 Sep 2011 21:39:44 +0200
>>         >         > To: Michel Py <mic...@arneill-py.sacramento.ca.us>
>>         >         > Cc: <frnog@frnog.org>
>>         >         > 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/

Répondre à