Le vendredi 02 septembre 2011 à 21:34 +0000, Raphael MAUNIER a écrit :
> 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 )


Vrais.
mh

> 
> >
> >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/
> 


---------------------------
Liste de diffusion du FRnOG
http://www.frnog.org/

Répondre à