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
