RE: [FRnOG] RE: RFC 6115: Recommendation for a Routing Architecture

2011-02-27 Par sujet Michel Py
Michel Py a écrit: Aujourd'hui (sur le haut de gamme): le processus BGP lui-même est assisté par le hard. >>> Thomas Mangin a écrit: >>> Tu expliques ce que tu veux dire STP ? >> Jerome Benoit a écrit: >> Offloading hardware, des ASICs quoi. Le hard est juste du >> logiciel plus ou

Re: [FRnOG] RE: RFC 6115: Recommendation for a Routing Architecture

2011-02-26 Par sujet Radu-Adrian Feurdean
On Sat, 26 Feb 2011 23:11:15 +0100, "Frédéric Gabut-Deloraine" said: > Les gros routeurs n'utilisent pas de TCAM mais de la DRAM / SRAM avec > les asic-qui-vont-bien. Dois-je comprendre que les "gros routeurs" en question sont tres sensibles au pps ? > C'est pour les ptits switchs l3 la TCAM.

Re: [FRnOG] RE: RFC 6115: Recommendation for a Routing Architecture

2011-02-26 Par sujet Frédéric Gabut-Deloraine
le Sat, Feb 26, 2011 at 11:11:15PM +0100, Frédéric Gabut-Deloraine a écrit: Les gros routeurs n'utilisent pas de TCAM mais de la DRAM / SRAM avec les asic-qui-vont-bien. Et bien sûr, la RLDRAM, qui emplit les DPC de nos MX préférés ! -- Frédéric Gabut-Deloraine --- List

Re: [FRnOG] RE: RFC 6115: Recommendation for a Routing Architecture

2011-02-26 Par sujet Frédéric Gabut-Deloraine
le Sat, Feb 26, 2011 at 08:38:32PM +0100, Radu-Adrian Feurdean a écrit: Pour l'instant, en matiere d'acceleration de route lookup, il n'y a pas vraiment mieux que le TCAM Moins cher certes, mais mieux difficilement. Les gros routeurs n'utilisent pas de TCAM mais de la DRAM / SRAM avec les a

RE: [FRnOG] RE: RFC 6115: Recommendation for a Routing Architecture

2011-02-26 Par sujet Michel Py
>> Jerome Benoit a écrit: >> C'est dans les cartons, regardes ce qu'on peut faire avec un GPU >> récent pour accélérer les recherches dans la table de routage. > Radu-Adrian Feurdean a écrit: > Pour l'instant, en matiere d'acceleration de route lookup, il n'y > a pas vraiment mieux que le TCAM

Re: [FRnOG] RE: RFC 6115: Recommendation for a Routing Architecture

2011-02-26 Par sujet Radu-Adrian Feurdean
On Fri, 25 Feb 2011 22:26:38 +0100, "Jerome Benoit" said: > C'est dans les cartons, regardes ce qu'on peut faire avec un GPU > récent pour accélérer les recherches dans la table de routage. Pour l'instant, en matiere d'acceleration de route lookup, il n'y a pas vraiment mieux que le TCAM Mo

RE: [FRnOG] Re: RFC 6115: Recommendation for a Routing Architecture

2011-02-26 Par sujet François-Frédéric Ozog
Un thread GPU n'a rien à voir avec un thread de Xeon: il faut imaginer une seule instruction SSE qui est exécutée des centaines de fois en parallèle sur des données différentes par des unités de calcul séparées. Du coup, pour être efficace l'accélération par GPU actuel impose un algorithme sans "if

RE: [FRnOG] RE: RFC 6115: Recommendation for a Routing Architecture

2011-02-25 Par sujet Michel Py
> Le mec qui a bu tout le pinard de Michel a écrit: > - Sur certains RSP la mémoire pour la FIB est séparée. > - Aussi il y a un "machin" qui s'occupe des basses besognes comme > copier le contenu filtré de la FIB dans la mémoire du RSP sur > la(les) RIB(s) dans la(les) linecard(s) sans que ce soit

RE: [FRnOG] RE: RFC 6115: Recommendation for a Routing Architecture

2011-02-25 Par sujet Michel Py
> Thomas Mangin a écrit: > Autant que je sache, avec IPv6, les machines vont avoir plus > d'une IP : avec deux routeurs avec RA connecte a deux FAI, tu > va te retrouver avec deux IPs et deux gateway ... et tu as > ton multihoming sans besoin de PI et de polluer la table de > routage de tes upstrea

Re: [FRnOG] RE: RFC 6115: Recommendation for a Routing Architecture

2011-02-25 Par sujet Jerome Benoit
Le Fri, 25 Feb 2011 20:55:33 +, Thomas Mangin a écrit : > Tu as une séparation entre routing engine (qui fait tourner le demaon BGP > entre autre) et forwarding qui est accéléré par le hard (ASIC, FPGA, etc.). > BGP n'est pas aide par le hard. Du moins pas plus que le TCP Offloading aide >

Re: [FRnOG] RE: RFC 6115: Recommendation for a Routing Architecture

2011-02-25 Par sujet Thomas Mangin
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 >>> Aujourd'hui (sur le haut de gamme): le processus BGP lui-même est assisté >>> par le hard. >> Tu expliques ce que tu veux dire STP ? > Offloading hardware, des ASICs quoi. Le hard est juste du logiciel plus > ou moins figé. Tu as une séparation

Re: [FRnOG] RE: RFC 6115: Recommendation for a Routing Architecture

2011-02-25 Par sujet Jerome Benoit
Le Thu, 24 Feb 2011 22:50:09 -0800, Michel Py a écrit : > Mon opinion: > BGP: pas vraiment. Pas depuis BGP4, avant c'est la préhistoire. Et moi qui croyait que MPLS 4 da people aller tout résoudre : autant reporter les pbs à la couche en dessous et ajouter une couche d'indirection, la fameuse c

Re: [FRnOG] Re: RFC 6115: Recommendation for a Routing Architecture

2011-02-25 Par sujet Jerome Benoit
Le Wed, 23 Feb 2011 12:03:30 +0100, Stephane Bortzmeyer a écrit : > > C'est le modèle popularisé par HIP > et je l'ai toujours trouvé > très cool. Franchement, çà me laisse dubitatif. On dirait une extension d'IPSeC un peu hasardeuse, à vrai dire le t

Re: [FRnOG] RE: RFC 6115: Recommendation for a Routing Architecture

2011-02-25 Par sujet Jerome Benoit
Le Fri, 25 Feb 2011 09:03:42 +, Thomas Mangin a écrit : > > Aujourd'hui (sur le haut de gamme): le processus BGP lui-même est assisté > > par le hard. > > Tu expliques ce que tu veux dire STP ? > Offloading hardware, des ASICs quoi. Le hard est juste du logiciel plus ou moins figé. a +

Re: [FRnOG] RE: RFC 6115: Recommendation for a Routing Architecture

2011-02-25 Par sujet Thomas Mangin
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > Un vendredi, ce n'est pas prudent de me tendre le bâton pour te faire battre > :P > Dans le genre raccourci de chez raccourci: IPv6: "supposons un mécanisme de > multihoming qui ne fasse pas gonfler la table de routage, soit sûr, bon > marché et s

Re: [FRnOG] Re: RFC 6115: Recommendation for a Routing Architecture

2011-02-23 Par sujet Rémi Bouhl
Le 23/02/2011 10:36, Stephane Bortzmeyer a écrit : > La section 17 est fort intéressante aussi (si on ne tient pas compte > de la sécurité, séparer Identificateur et Localisateur est aujourd'hui > trivial). C'est comme la résolution de noms en DHT. À part le léger > problème sans importance de la