Re: [FRnOG] Pb Cogent/OpenTransit
Le 3 oct. 09 à 03:32, Fabien Dedenon a écrit : Arthur Fernandez a écrit : Bonsoir, La question n'est pas de chercher à savoir si c'est ou non obligatoire d'avoir une peering policy fully open... mais de reconnaitre que pour joindre 3215 la seule solution convenable est d'acheter la bande passante à opentransit, transitaire détenu par le même groupe que FT, et ce fait pour l'immense majorité des opérateurs. Dans un monde libéral ça ne pose aucun soucis et la réponse typique est plutot va chier, t'avais qu'à être à leur place mais dans un autre un chouilla différent, on pourrait voir ici de la vente forcée et de l'abus de position dominante. Et autrement dit, pour un opérateur qui a construit son réseau sur les fonds publiques, moi, j'ai un peu mal à le gober. ++ Arthur. Il y a quelques années, nous étions client 5511, je n'ai jms compté le nombre de pertes de visibilité de 3215 (surtout en ayant toujours les annonces des pref) qu'on a eut mais c'était clairement pas reluisant, je ne qualifierai pas cela de solution convenable dans ces conditions. Reste qu'aujourd'hui avec un bon choix de transitaires tout se passe pas trop mal quand Ft ne fait pas sauter les peers sur les plateformes PARIS/LDN/AMS en même temps ... du vécu au début de cette année via 3257 et 6453 (bon ok India telecom on pourrait dériver) ... Cette visibilité étant très importante pour nous, pas en terme d'AsPath (on s'en fou on est fournisseur de contenu) mais de dispo/perf, la recherche d'un bypass 5511 sera certainement un projet a mener un de ces quatre. Franchement ce n'est pas pour te contredire, mais en fait si :). Je n'ai jamais connu de soucis vers 3215 depuis exactement 1 an que mes 10G sont en place avec eux. Le 2 octobre 2009 19:15, Raphael Maunier rmaun...@neotelecoms.com a écrit : 3215 ne vend pas. C'est 5511 donc pas pareil, c'est ca l'astuce Il me semblait que l'As Domestique faisait du bgp (au moins paid peer tres tres cher) il y quelques années pourtant. oui effectivement, mais quand tu prend prix moyen du marche et tu fais *15 je n'appelle pas ca une offre :) Le soucis se situe la a mon sens J'ai vu passer une propale pourtant, mais tu as raison, ça devait être l'autre AS ;) Bah c'est ton choix, generalement on dit : Price. Speed. Quality.Pick two. Price. Speed. Quality.Pick ***Neo***, je sors?:) J'aimerai bien, mais tu vois chez nous aussi on a fait les frais avec les boites noires. On a du remettre un peu plus a la poche pour les remplacer par des boites d'une autre couleur. On a ausi essayer de faire les trois d'un coup, mais franchement ca ne marche pas :) A priori, la plupart d'entre nous est paye pour tenter d'arriver a mettre les trois ensemble. Ce qui est le plus dommage c'est que les competences multiples ( et il y en a beaucoup) de la FRNog ne sont pas assez canalises afin de faire en sorte que tout le monde progresse :) Tiens ca pourrait etre un sujet du prochain FrNog : Creation de groupe de travail, ou un truc du genre ! -- Raphaël Maunier NEO TELECOMS Engineering Manager 21 rue La Boétie 75008 Paris Tel : +33 1.49.97.07.44 Mob : +33 6.86.86.81.76 rmaun...@neotelecoms.com --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Pb Cogent/OpenTransit
Raphael Maunier a écrit : Juste pour dire que on ne peut pas definir une politique de peering. On ne veut pas. Les points de peering pourraient définir une politique de peering pour leurs membres, ce qui faciliterait pas mal de procédures. Et aussi définir des critères de qualité (stabilité) à respecter, en contrepartie. Mais on, communauté d'opérateurs, pourrait aussi définir des bonnes pratiques de peering. J'achete du 5511 et je peux te dire que sans faire de la pub, je sais que si je dois basculer beaucoup de traffic vers eux, ca fonctionne sans me poser de questions ( sauf vers Cogent, ok) Sauf Cogent, sauf OVH, sauf le prochain qui saturera son port en fait. Pour ma part, je considère que laisser volontairement un port saturer c'est tout simplement ignorer sa responsabilité et son obligation de moyens, autrement dit c'est arnaquer ses propres clients. On est selective, et je ne peer pas avec tout ce qui bouge. Vu le volume que j'ai sur le reseau, rajouter 50 sessions pour 200/300 meg de direct peering et au final ca ne me fera que 50 meg de transit en moins. Je prefere securiser mes peerings sur plusieurs IX et etre presque certain de la qualite. Logique plutôt financière en fait, parce que de traiter séparément ces 50 peers sur un routeur à part permet d'épargner le CPU de ses core, tout en ayant une politique ouverte et pas forcément beaucoup plus de taf (les route-server sont là pour faciliter les choses). La qualité (pour ses clients) on l'obtient aussi en amont en ayant une politique de routage citoyenne, en interne en dimensionnant correctement ses routeurs, et en aval en livrant ses client correctement et dans les délais, de manière transparente, voire en évitant de leur marcher sur la gueule. A la base ce projet n'a RIEN a voir avec Neo. Sauf qu'a partir d'un moment, pour que le projet prenne forme et etre legitime (serieusement sans bidouilles), il faut de l'argent et donc, le groupe d'origine s'est ouvert a des societes et j'ai naturellement demande a mon boss qui a dit oui :) Bon en même temps je crois que personne n'est dupe. On entend même plus parler de Google. Puisque tu as ouvert la parenthèse, j'ai juste le sentiment qu'on a pas besoin de yet another private peering point où le pouvoir est détenu soit par celui qui a mis tout le pognon, soit par celui qui fait les choses (or ça marche comme ça dans les associations quand le pouvoir n'est pas correctement distribué, et j'attends de lire les statuts de ton France-IX). Or déjà savoir qui monte réellement ce projet, c'est pas facile. Si le France-IX est dépendant de Néo, alors il n'est pas neutre. On ne parle pas d'une simple sous-traitance là, on parle de toute l'infra si je ne m'abuse. Est-ce que le France-IX pourra quitter Néo sans mourrir ? Si oui alors le projet m'intéresse. Sinon, yet another FreeIX. Rien ne t'oblige a ne pas servir les clients d'Orange depuis ta plateforme, rien ne t'y oblige ... Si, j'y suis obligé, ça s'appelle la neutralité du réseau, auquel nous sommes contraints par le code de communications électronique et des postes (en France en tout cas). Appliquer un filtrage arbitraire est illégal, même si la mode est à l'accepter benoîtement parce que le président pense que c'est bien, sans comprendre à quel point ça va nuire au réseau. Excellent argument pour l'élargissement du peering, ça devrait même intéresser l'Arcep et la DGCCRF. Finalement pour un opérateur d'accès, faire payer l'interco de l'opérateur de contenu c'est une sorte de racket sur la valeur ajoutée que celui-ci détient. Je n'ai pas de soucis vers FT moi :) De quoi on parle ? Ah, d'argent, je comprends mieux De domination. Opérateur puissant, surpuissant, toussa. Du gros qui marche sur son client, oublie ce qu'est une pratique loyale, des trucs assez fréquente chez certains opérateurs en *télécom. Bon WE. lulu --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Pb Cogent/OpenTransit
Le 3 oct. 09 à 13:03, Sylvain Vallerot a écrit : Raphael Maunier a écrit : Juste pour dire que on ne peut pas definir une politique de peering. On ne veut pas. Les points de peering pourraient définir une politique de peering pour leurs membres, ce qui faciliterait pas mal de procédures. Et aussi définir des critères de qualité (stabilité) à respecter, en contrepartie. Je suis plus partisan du point d'echange qui interdit aux membres de saturer leurs ports et les oblige a upgrader si on arrive a x % Faciliter les procedures avec un vrai route-server, pkoi pas Mais on, communauté d'opérateurs, pourrait aussi définir des bonnes pratiques de peering. J'achete du 5511 et je peux te dire que sans faire de la pub, je sais que si je dois basculer beaucoup de traffic vers eux, ca fonctionne sans me poser de questions ( sauf vers Cogent, ok) Sauf Cogent, sauf OVH, sauf le prochain qui saturera son port en fait. C'est pour ca que j'ai plusieurs transitaires :) Pour ma part, je considère que laisser volontairement un port saturer c'est tout simplement ignorer sa responsabilité et son obligation de moyens, autrement dit c'est arnaquer ses propres clients. On est selective, et je ne peer pas avec tout ce qui bouge. Vu le volume que j'ai sur le reseau, rajouter 50 sessions pour 200/300 meg de direct peering et au final ca ne me fera que 50 meg de transit en moins. Je prefere securiser mes peerings sur plusieurs IX et etre presque certain de la qualite. Logique plutôt financière en fait, parce que de traiter séparément ces 50 peers sur un routeur à part permet d'épargner le CPU de ses core, tout en ayant une politique ouverte et pas forcément beaucoup plus de taf (les route-server sont là pour faciliter les choses). Ce n'est pas aussi simple. Quand tu arrives a un certain volume ( plus de 100gig), tu te dois d'etre un peu plus selectif et concentrer tes peers. Par principe, on ne peer pas avec les clients de nos peers. C'est un choix et c'est l'un des notres. Et tres franchement, nous avons des Juniper MX, ce n'est pas 200 sessions de peerings supplementaire qui vont leur faire peur, La qualité (pour ses clients) on l'obtient aussi en amont en ayant une politique de routage citoyenne, en interne en dimensionnant correctement ses routeurs, et en aval en livrant ses client correctement et dans les délais, de manière transparente, voire en évitant de leur marcher sur la gueule. Tout a fait d'accord avec toi pour le dimensionnement, mais je ne vois pas le rapport avec la politique de routage citoyenne. Tu te dois d'avoir les meilleurs partenaire et ne pas multiplier les possibilites d'incidents. Le peering ( et pour avoir fait les EPF, GPF, RIPE,Nanog ...) fonctionne en respectant une polique de respect de tes peers ( reseau stable, port pas sature, ne pas peerer avec les clients de ce peer et bien d'autres criteres) Je suis plutot partisant du keep it simple. A la base ce projet n'a RIEN a voir avec Neo. Sauf qu'a partir d'un moment, pour que le projet prenne forme et etre legitime (serieusement sans bidouilles), il faut de l'argent et donc, le groupe d'origine s'est ouvert a des societes et j'ai naturellement demande a mon boss qui a dit oui :) Bon en même temps je crois que personne n'est dupe. On entend même plus parler de Google. Google ne communique jamais avant la fin d'un projet. C'est une societe enorme ( et cote en bourse) et ils ne peuvent pas faire n'importe quoi avec leur communication. Puisque tu as ouvert la parenthèse, j'ai juste le sentiment qu'on a pas besoin de yet another private peering point où le pouvoir est détenu soit par celui qui a mis tout le pognon, soit par celui qui fait les choses (or ça marche comme ça dans les associations quand le pouvoir n'est pas correctement distribué, et j'attends de lire les statuts de ton France-IX). Or déjà savoir qui monte réellement ce projet, c'est pas facile. Si le France-IX est dépendant de Néo, alors il n'est pas neutre. On ne parle pas d'une simple sous-traitance là, on parle de toute l'infra si je ne m'abuse. Est-ce que le France-IX pourra quitter Néo sans mourrir ? Si oui alors le projet m'intéresse. Sinon, yet another FreeIX. Neo, Interxion, Google, Akamai, Jaguar ne seront pas proprietaire du France-IX. Nous sommes en train de nous orienter vers un GI(qq chose). Au debut, pour faire le truc carre il faut une societe qui prenne le lead pour avoir la legitimite afin de pouvoir parler serieusement a des gens comme Panap, Free et pourquoi pas Sfinx et Equinix s'ils veulent egalement atteindre le meme but a savoir un peering performant en France. Tu vois je prefere laisser les gens competent pour gerer les parties legale ( status et autre) , et negociation legale avec les gros. Ce n'est pas mon metier et franchement ca ne me passionne pas des masses. Le but c'est clairement de faire un modele a l'AMS-IX et vraiment permettre a
Re: [FRnOG] Pb Cogent/OpenTransit
On ne veut pas. Les points de peering pourraient définir une politique de peering pour leurs membres, ce qui faciliterait pas mal de procédures. Et aussi définir des critères de qualité (stabilité) à respecter, en contrepartie. Il y a un membre de Euro-IX qui fait ça. Je ne suis plus sur duquel mais cela pourrait bien être TIX. https://www.euro-ix.net/member/m/ixp/show/49/profile Thomas --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Pb Cogent/OpenTransit
Raphael Maunier a écrit : Imagine la difficulter a gerer les milliers de peers si c'etait open, franchement ca deviendrait une usine competement instable Gérer quelques milliers de peers ? Je ne vois pas exactement pourquoi ca représenterait un volume de travail plus que proportionnel au nombre de ces peers. Or pour moi qui en ai 150 à 200, c'est grosso modo peanuts. Donc pour FT, gérer quelques milliers de peers, non, on ne me fera pas croire que ce soit une charge de travail significative. J'ai une peering policy ouverte (*hint*, *hint* ;-), donc je peere justement avec les petits que FT ne veut pas, je ramasse quelques milliers de routes sur ces peers ; ca fait en général pas beaucoup de routes par peer. Alors qu'est-ce que peut craindre un opérateur comme FT, que la table de ses routeurs de bordure (et encore, seulement ceux qui sont sur les GIX) double ? Même dans le principe, ça ne tient pas : comment des petits opérateurs parviendraient-ils à gérér un max de peers en open policy, et FT ne serait-il pas capable de le faire ? Quand tu arrives a un certain volume (plus de 100gig), tu te dois d'etre un peu plus selectif et concentrer tes peers. Je ne vois pas bien ce que tu entends par concentrer tes peers, ni la contrainte technique dont la complexité rend cela nécéssaire ? Par principe, on ne peer pas avec les clients de nos peers. C'est un choix et c'est l'un des notres. Un choix moui, on peut aussi voir ça comme une entente entre opé de même taille : je peere avec toi donc ça ne nous coute rien, mais tu seras gentil de ne pas peerer avec mes clients comme ça je pourrai mieux les facturer. Entre nous on peere, on s'arrange, mais un client mon cher ami, ça doit rester captif. Puisqu'on parlait du monde de oui-oui, je dirais même rester captif ou être détruit, puisque c'est la politique de certains opérateurs en situation de trop-puissance, de détruire ce dans quoi ils ne trouvent pas leur intérêt. Ca se fait même au détriment de leur mission, fut-elle de service public (ce qui leur a permi d'accéder à leur position dominante), je pense à la tuée-dans-l'oeuf initiative Radiophare qui visait à apporter le haut débit sur l'Ile de Ré, ou à l'exploitation déplorable (en terme de neutralité) du réseau Dorsal en Limousin. Je veux dire par-là qu'il ne faut pas voir dans la policy de certains opérateurs que des motifs d'ordre technique. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Cablage pour ADSL
Athias Jerome wrote: Note amusante: sur de la plus courte distance, j'ai vu ponter en laser dans ma région (Franche-Comté). C'est très amusant par temps de brouillard ^_^ Juste par curiosité : cette technologie (optique en air libre) est-elle accessible à un particulier sans coûter un rein ? -- Etienne Dechamps / e-t172 - AKE Group Phone: +33 6 20 41 09 29 attachment: e-t172.vcf smime.p7s Description: S/MIME Cryptographic Signature
Re: [FRnOG] Pb Cogent/OpenTransit
Même dans le principe, ça ne tient pas : comment des petits opérateurs parviendraient-ils à gérér un max de peers en open policy, et FT ne serait-il pas capable de le faire ? (Disclaimer : ce que je dis est évidement une simplification) Car quand FT passe du trafic pour mon réseau (via L3 ou TATA) si il y un problème, il savent que leur peers vont le regler (je les paye pour un service). Si on avait une relation de peering, il faudrait que FT me contacte et gère le problème. Comme FT n'a pas de revenu de ma part comme on peer, ca revient a dire que chaque problème avec mon reseau de peering leur coute. Dans le cas ou il ne peer qu'avec les gros, ce n'est pas le cas. Si tu es eux tu fait quoi ? Un choix moui, on peut aussi voir ça comme une entente entre opé de même taille : je peere avec toi donc ça ne nous coute rien, mais tu seras gentil de ne pas peerer avec mes clients comme ça je pourrai mieux les facturer. Entre nous on peere, on s'arrange, mais un client mon cher ami, ça doit rester captif. La relation de peering est bases sure une relation de force mais a` la fois demande une coopération de intervenants. Je n'ai pas d'information - a` par ce qui est publique - mais voici une spéculation de pourquoi un grand reseau aurait pu avoir les problèmes avec ses peers. Je m'excuse aupres du grand reseau si mon analyse est fausse, j'essaye simplement d'expliquer pq ne pas peerer avec les clients de ses peers est une règle qui n'est pas prête de disparaitre. J'assume que dans la relation de force le grand reseau est le réseau est le plus vulnerable en cas de depeering. Le grand reseau vend du traffic moins cher que ses concurrents. Les autres opérateurs arrivent a la conclusion que leurs sessions de peering sert a` au grand reseau pour vendre a` bas prix a` leur depend - en gros ils ne sont pas content (la situation a ne pas atteindre). Les autres opérateurs décident qu'ils ne veulent plus aider ce grand reseau - car cela affecte leur propre reseau, ou autre chose, et refusent de mettre a` jour leurs connections de peering quand elles arrivent a` saturation, ou quand leur contrats depeering (c'est une relation _commerciale_) arrivent a` expiration. Le service du grand reseau en prend un coup, leurs clients ralent - le grand reseau fait pression sur ses peers, la relation en prend un cout, aucun compromis n'est atteint - pouf ! depeering ! Avec un depeering, le grand reseau risque de maxer d'autres connections de peering et doit peut-etre meme passer du trafic pas cher en transit peut-etre même a` perte, ce qui est surement le case si d'autre operateurs ont atteint la même conclusion et n'ont pas récemment mis a jour leur peering avec eux - peut-etre même dans ce but. Comme ça fait mal, ça force le grand reseau a renégocier ses relation de peering pour un monde plus juste dans les yeux de ses peers :D Conclusion : énerver ses peers, c'est pas un bon plan. Donc ne pas peerer avec les clients de ses peers - c'est un bon plan surtout si dans la relation de peering tu es le plus vulnérable. Non, Oui-Oui, le monde du peering, ce n'est pas pour les Bisounours :D Thomas --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Pb Cogent/OpenTransit
Thomas Mangin a écrit : Car quand FT passe du trafic pour mon réseau (via L3 ou TATA) Si on avait une relation de peering, il faudrait que (snip) Ces deux phrases décrivent une situation qui ne peut pas se produire, on n'attend normalement pas le réseau d'un tiers opérateur via une session de peering. Du coup, j'ai pas compris ton exemple. La relation de peering est bases sure une relation de force mais a` la fois demande une coopération de intervenants. Ah... ça vient de là alors, moi je vois ça comme une relation de coopération, technique et économique, avec aussi une jolie dimension diversité, pluralité, qui est de moins en moins dénuée de sens politique. La relation de force, moi, non, je l'ai pas vue dans les peering agreements jusqu'ici. Désolé les mecs on va shutdown les sessions et reprendre à zero, j'ai loupé un truc, my fault. Dorénavant, plus de session sans bras de fer. J'assume que dans la relation de force le grand reseau est le réseau est le plus vulnerable en cas de depeering. Le grand reseau vend du traffic moins cher que ses concurrents. Les autres opérateurs arrivent a la conclusion que leurs sessions de peering sert a` au grand reseau pour vendre a` bas prix a` leur depend - en gros ils ne sont pas content (la situation a ne pas atteindre). C'est assez étrange ces calculs qui font que il y a du traffic qui passe entre nous donc j'essaie de calculer ce que je peux te racketter. De deux choses l'une, soit je passe du traffic via un opérateur de transit, et il me facture du transit, soit c'est vers les clients directs d'un peer, et, ils ont pas le service gratuit ces gens-là, à priori ? A un moment donné, on vend une presta d'hébergement à un client, il paie. On vend de l'accès à un client, il paie. Et si on le fait pas payer assez, c'est qu'on le facture pas comme on devrait... Je ne m'étends pas sur les 20 à 100 Mbps qu'on promet aux gens (best effort de merde, traffic assymétrique et hadopi) il n'y a que des avocats hyper spécialisés pour comprendre pourquoi les peines pour escroquerie ne sont pas applicables, bref appelons-ça des raisons marketing. Quand on s'interconnecte pour échanger du traffic mieux, et à moindre frais, c'est gagnant-gagnant. Je rejette à 100% cette logique de l'extorsion par laquelle on demande à l'opérateur voisin de payer sous prétexte qu'on est plus puissant. Ca ne se justifie *que* par une situation de domination du marché. Quand FT vend l'accès à son réseau, pour moi c'est le même abus que quand Rani clame que le traffic de ses abonnés vers les fournisseurs de contenu, merde ça coûte cher. Parce que, vers ou depuis, notez bien que ca change rien au discours. Les FAI fournissent aussi des contenus vis-à-vis d'autres FAI. Est-ce que Free accepterait de se faire facturer pour le traffic des abonnés de FDN vers ses saletées d'hébergement de masse, oui ? Chouette, je vous prépare la facture tout de suite, l'asso a justement besoin de financer un avocat. Non, Oui-Oui, le monde du peering, ce n'est pas pour les Bisounours :D Effectivement, je confirme, quand la logique financière vient se mêler de quelque chose qui ne devrait obéïr qu'à des besoins techniques dans le respect de la Net Neutrality, on arrive a un thread qui s'appelle comme celui-ci. Messieurs les opérateurs renvoyez donc vos commerciaux facturer leurs chers clients et nous lâcher la grappe, s'il vous plait. Qu'ils mettent la liste des IX sur leur outils de marketing préféré, mais alors qu'ils vous laissent vous en servir ! Après, s'il y a des raisons techniques a limiter les peering, ça se tient, je suis peut-être trop petit pour y être confronté, je veux bien les entendre. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Une route, deux ASN
Benjamin BILLON a écrit : Mettons que la route 1.2.3.4/24 soit annoncée par l'as 123 et l'as 456 (comme indiqué par exemple dans la db du ripe) Quelles en seraient les applications concrètes ? De l'anycast du pauvre ? --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Une route, deux ASN
De l'anycast du pauvre Ca me semble bien risqué, le pauvre risquant de ne pas garantir l'intégrité des données sur les différents sites (mais je ne dis pas que ça ne peut pas être ça) Ca pourrait aussi être des bribes de fusions de plusieurs réseaux, donc une anomalie et non une feature ... --- Liste de diffusion du FRnOG http://www.frnog.org/
