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

2011-02-27 Par sujet Thomas Mangin 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Bonsoir Michel,

> Processeurs: 2x 800-MHz Power PC symmetric multiprocessing (SMP). En faisant 
> mes petites recherches, j'ai trouvé que c'était ce qu'il y avait dans un Mac 
> G4 Serveur introduit en Septembre 2001: http://tinyurl.com/4snyns9
> Tu crois que c'est ce bousin qui gère BGP dans un CRS 16-slot?


Je crois que tu m'as donne des liens a lires, sans démontrer que ce que je dis 
est faux ou ce que tu défend est vrai ... 
A ce que je viens de googler, sans carte de "route processor" la réponse est 
probablement .. oui .. mais je n'ai pas de CRS, donc mon expérience est limite.

Les liens suivants semblent indiquer que le CRS est capable de lancers des 
processus sur des CPUs de cartes additionnelles.
Ces cartes supplémentaires utilisent probablement des processeurs a jeux 
d'instruction RISC ou CISC normale. 
Je ne sais pas ce qu'il y a dessous et peu importe si c'est MPI, erlang ou 
autre chose, comme  l'OS qui gère ces CPU/mémoire externe comme un Unix gère 
les cores, ou encore chaque carte qui fait tourner son OS et retourne le 
résultat.

Je ne cherche pas a avoir le dernier mot mais a moins de dire qu'un PC avec 
deux CPUs sur la carte mère est une accélération matérielle pour BGP - qui peut 
alors monopoliser un CPU, je n'ai pas change d'avis. 
Si un expert CRS veut nous sortir de notre trou .. merci bien :D

http://www.cisco.com/en/US/prod/collateral/routers/ps5763/product_data_sheet0900aecd80501c66.html
http://ccbnonprofits.com/Products/Cisco-CRS-Distributed-Route-Processor-CPU-Module-Control-processor-plug-in-module__CRS-DRP-B-CPU.aspx

Bonsoir,

Thomas

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (Darwin)

iEYEARECAAYFAk1qydgACgkQA/52wvuLgaEC2wCgy5G3zSkON2996j1RGlPnJyXl
aSgAoNT1s1x/8b5bG4IjWl47N9yWfKgx
=O34x
-END PGP SIGNATURE-
---
Liste de diffusion du FRnOG
http://www.frnog.org/

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 moins figé. 

> 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 le rendu graphique sur un PC :)


Bon regardons d'un peu plus près CRS-16-RP, Cisco CRS 16-Slot Line-Card Chassis 
Route Processor, une petite carte sympa à pas cher ($35000) 
http://tinyurl.com/4o2b3fp

Processeurs: 2x 800-MHz Power PC symmetric multiprocessing (SMP). En faisant 
mes petites recherches, j'ai trouvé que c'était ce qu'il y avait dans un Mac G4 
Serveur introduit en Septembre 2001: http://tinyurl.com/4snyns9

Tu crois que c'est ce bousin qui gère BGP dans un CRS 16-slot?
Le processeur sur ce genre de carte, ça gère le port console, les ventilos et 
la température du four. Le reste, c'est du hard ASIC propriétaire.

Michel.

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

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

C'est surtout pour faire du wire-speed .

-- 
Radu-Adrian Feurdean
 raf (a) ftml ! net

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

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
---
Liste de diffusion du FRnOG
http://www.frnog.org/

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 asic-qui-vont-bien.

C'est pour les ptits switchs l3 la TCAM...

--
Frédéric Gabut-Deloraine
---
Liste de diffusion du FRnOG
http://www.frnog.org/

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 Moins cher certes, mais mieux
> difficilement.

Ne pas oublier que "pas cher" c'est l'idée derrière packet shader, one ne parle 
pas ici de refaire Cisco ou Juniper, mais de faire presque aussi bien à 
considérablement moins cher.


> François-Frédéric Ozog a écrit:
> 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". Dès lors qu'il y a
> un "if", les threads sont sérialisés dans un "groupe" et du coup
> la puissance devient limitée.

Je pense que l'utilisation du GPU dans une machine du type de celle utilisée 
par packetshader serait bien adaptée à faire une boite NAT de proportions 
monstrueuses.

Michel.

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

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 Moins cher certes, mais mieux
difficilement.
Et pour faire du wire-speed, je crois qu'il faudra encore attendre
longtemps

-- 
Radu-Adrian Feurdean
 raf (a) ftml ! net

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

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". Dès lors qu'il y a un "if", les threads sont
sérialisés dans un "groupe" et du coup la puissance devient limitée.

Il y a donc des domaines candidats "faciles" comme faire trouver le port de
sortie pour un paquet et des domaines pas adaptés comme faire tourner BGP.
Le GPU est adapté pour calculer des clé en brute force , mais beaucoup moins
efficace pour crypter/décrypter un bloc (byte n+1 dépenden de byte n ->
difficile de mettre au point des algos parallèles: la pratique montre que
coût transfert mémoire + encryptage/décryptage fait que c'est plus rapide en
Xeon!).

FF

-Message d'origine-
De : owner-fr...@frnog.org [mailto:owner-fr...@frnog.org] De la part de
Stephane Bortzmeyer
Envoyé : vendredi 25 février 2011 22:36
À : Jerome Benoit
Cc : frnog@frnog.org
Objet : [FRnOG] Re: RFC 6115: Recommendation for a Routing Architecture

On Fri, Feb 25, 2011 at 10:26:38PM +0100,
 Jerome Benoit  wrote 
 a message of 39 lines which 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.

Si c'est une allusion à PacketShader (voir par exemple
<http://www.bortzmeyer.org/packetshader.html>), alors, il s'agit bien
de "Forwarding plane" et pas de "Control Plane" et Thomas Mangin a
donc raison, ce n'est certainement pas une aide pour BGP.
---
Liste de diffusion du FRnOG
http://www.frnog.org/

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

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 le CPU 
> de la RSP qui s'en occupe.

Euhhh swap FIB <-> RIB

Michel.

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

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 upstreams.

Parce que je t'aime bien: no comment.


> Stephane Bortzmeyer a écrit:
> Si c'est une allusion à PacketShader (voir par exemple
> ), alors, il s'agit
> bien de "Forwarding plane" et pas de "Control Plane" et Thomas
> Mangin a donc raison, ce n'est certainement pas une aide pour BGP.

Correct; ceci dit si je comprends bien PacketShader, il serait en théorie 
possible de recompiler Quagga pour utiliser le GPU aussi; SI ça devenait le 
cas, on pourrait AMHA appeler çà une aide hardware (même si le but original du 
GPU était les graphiques, ça serait néanmoins un ASIC du pauvre).


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

Ca serait sympa que quelqu'un de chez Cisco lise ce qui suit et commente. Pour 
Juniper, je ne m'aventurerai pas sur un terrain que je ne connais pas.

D'après ce que je comprends:

- 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 le CPU de la RSP qui s'en occupe.

Dans les deux cas, ça me semble bien être une assistance par le hardware des 
fonctions de la control plane. Comme d'habitude, si je dis des conneries que 
quelqu'un me détrompe SVP.

Michel.

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

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

2011-02-25 Par sujet Jerome Benoit 
Le Fri, 25 Feb 2011 22:36:15 +0100, 
Stephane Bortzmeyer a écrit :

> On Fri, Feb 25, 2011 at 10:26:38PM +0100,
>  Jerome Benoit  wrote 
>  a message of 39 lines which 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.
> 
> Si c'est une allusion à PacketShader (voir par exemple
> ), alors, il s'agit bien
> de "Forwarding plane" et pas de "Control Plane" et Thomas Mangin a
> donc raison, ce n'est certainement pas une aide pour BGP.

Effectivement. 

J'avais lu un papier sur un FPGA (HyperChip si je me souviens bien) qui
pouvait faire de l'offload de la maintenance des tables de routage
(RTM -> Local RTM et Global RTM), çà rentrait dans le cadre d'une
implémentation de ForCes ou le FPGA était une carte de contrôle dédiée
à la maintenance des tables. Si je le retrouve, je le poste
mais pas ce soir :) 

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


pgpc8l5NFs7AC.pgp
Description: PGP signature

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

2011-02-25 Par sujet Stephane Bortzmeyer 
On Fri, Feb 25, 2011 at 10:26:38PM +0100,
 Jerome Benoit  wrote 
 a message of 39 lines which 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.

Si c'est une allusion à PacketShader (voir par exemple
), alors, il s'agit bien
de "Forwarding plane" et pas de "Control Plane" et Thomas Mangin a
donc raison, ce n'est certainement pas une aide pour BGP.
---
Liste de diffusion du FRnOG
http://www.frnog.org/

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

2011-02-25 Par sujet Stephane Bortzmeyer 
On Fri, Feb 25, 2011 at 09:03:42AM +,
 Thomas Mangin  wrote 
 a message of 34 lines which said:

> 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
> upstreams.

Euh, c'est très très loin d'un vrai multihoming. Supposons qu'on ne
soit pas vendredi, voici les principales différences :

- les connexions (par exemple SSH ou SIP) en cours sont resettées si
un des deux FAI tombe en panne après l'établissement de la connexion.

- pire, si un des deux FAI est en panne, les nouvelles connexions
entrantes ne se feront que si le client gère les adresses multiples
(et essaie les deux adresses, en parallèle, pour ne pas poireauter des
heures s'il a commencé par la mauvaise).

L'un des buts principaux du multi-homing étant la résistance aux
pannes d'un FAI, appeler cette technique multi-homing me parait très
trolloïde.
---
Liste de diffusion du FRnOG
http://www.frnog.org/

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 
> le rendu graphique sur un PC :)

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.
C'est pas actuellement de l'ASIC pur mais le Routing Control Plane fait
dans le matos pensé uniquement pour sa fonction. 

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


pgpbV73fmSpUM.pgp
Description: PGP signature

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 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 le 
rendu graphique sur un PC :)

Thomas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (Darwin)

iEYEARECAAYFAk1oF0YACgkQA/52wvuLgaGz/wCdGArMRAmLTrNnBJ9fPYBf7wp1
fyEAoOPeQsz/0a0qYBTXyOR/qIaO5CW+
=vSVj
-END PGP SIGNATURE-
---
Liste de diffusion du FRnOG
http://www.frnog.org/

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 couche d'indirection magique :)

Je connais la sortie ... 

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


pgpdYCfwnwltv.pgp
Description: PGP signature

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 tout me parait bancale pour faire la
séparation sur IP. D'ailleurs çà m’étonnerait pas que ce premier
réutilise une partie du code noyau de IPSeC. 

> 
> ILNP a une approche différente : il n'impose pas une politique
> particulière d'authentification. L'identificateur peut être une
> adresse MAC (car elles sont uniques, sans créer de nouveaux mécanismes
> d'allocation).

Oui mais non. Pas vrai dans la vrai vie.

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


pgp1Ha3u7cZB7.pgp
Description: PGP signature

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 +.

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


pgpw2OvUwv7VK.pgp
Description: PGP signature

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 soit déployable".

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 upstreams.

> Mon opinion:
> BGP: pas vraiment. Pas depuis BGP4, avant c'est la préhistoire.

BGP change beaucoup mais a moins de suivre les drafts ce n'est pas très visible 
car aucune compatibilité n'est cassée.

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

Thomas

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (Darwin)

iEYEARECAAYFAk1ncG4ACgkQA/52wvuLgaFBPwCg553sQxBpfSvRaE+LraJR6z0P
ORkAn2J2uMo5kWNce27xx2bbt86Ac/iC
=0oKu
-END PGP SIGNATURE-
---
Liste de diffusion du FRnOG
http://www.frnog.org/

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

2011-02-24 Par sujet Michel Py 
>> Michel Py a écrit:
>> La seule chose que j'ajouterai: les solutions (comme INLP)
>> fondées sur la séparation entre identificateur et localisateur
>> ne sont pas nouvelles. 

> Stephane Bortzmeyer a écrit:
> Certes. Elles ne prétendent d'ailleurs pas l'être. Ceci dit,
> entre dire « il faut séparer l'identificateur et le localisateur »
> et une norme complète, cohérente, gérant les cas vicieux et
> raisonnablement sécurisée, il y a de la marge.

C'est très vrai, mais ne pas oublier l'effet d'horizon: tu as une idée, tu 
écris un draft pas très complet, tu te prends une volée de bois vert. Pourquoi 
perdre du temps à pondre la norme complète, alors que même les gens qui ont de 
la sympathie pour ton idée te disent que tu perds ton temps?


> Le travail du RRG était justement de passer d'une vieille idée « dos
> de l'enveloppe » à une architecture correctement définie et réaliste

Avec 15 ans de retard. Les drafts de "requirements", "taxonomy", etc etc j'en 
ai plein mes tiroirs, dont certains étaient carrément nuls et d'autres très 
bons et écrits par des gens très compétents. Note que je ne dénigre pas le 
travail, bien au contraire. Mais comme tu le disais toi-même, c'est déjà un 
demi-échec avant même d'avoir un WG; franchement je ne vois rien de 
révolutionnaire par rapport à ce qui n'aurait pas déjà été écrit. Le RRG 
n'ayant ni "rough consensus" ni "working code", je les vois mal barrés. 
J'espère que tu m'accorderas le droit d'avoir une opinion qualifiée en la 
matière, ayant pris ma ration de volées de bois vert. Ecrire une lettre au Père 
Noël, c'est une chose. Qu'il la lise, c'en est une autre. Croire qu'il va venir 
en personne de porter tes cadeaux, j'ai essayé; depuis, j'ai grandi.

Ceci dit, je répète ce que j'ai dit hier:
http://www.bortzmeyer.org/6115.html
Très bon article, ceux qui ne l'ont pas (encore) lu méritent des coups de pied 
au cul.


> (je rappelle que plusieurs des propositions de séparation entre
> identificateur et localisateur contenaient des raccourcis du genre
> « supposons un mécanisme de correspondance entre I et L qui passe à
> l'échelle, soit sûr, bon marché et soit déployé »...)

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 soit déployable".


>> Toutes ces solutions se sont régulièrement fait tailler
>> en pièces par l'IETF dans le passé.

> Pour de bonnes raisons.

C'est vrai, et plein de mauvaises aussi. Genre, process troll.


>> Je n'ai remarqué depuis 15 ans aucun changement qui
>> permettrait d'espérer qu'une de ces idées voie le jour.

> Là, je ne suis pas d'accord, la science a progressé
> pendant ces 15 ans.

En théorie, la science et la manière dont L'IETF fonctionne, c'est très 
similaire. En pratique, beaucoup moins.

Question sérieuse (vendredi, on fait mieux de préciser):
Qu'est-ce qui a progressé? (dans le domaine du routage)

Mon opinion:
BGP: pas vraiment. Pas depuis BGP4, avant c'est la préhistoire.

Le hardware: oui. Je vois 3 époques:
La préhistoire: tout par soft. Ah, la bonne vieille époque de l'AGS et IGS 
(voix chevrotante).
Hier: disons l'époque CEF / dCEF / 7500. C'est toujours le CPU qui s'occupe de 
BGP et possiblement du premier paquet d'un flux, après ça c'est la linecard qui 
pousse le paquet avec un chip spécialisé.
Aujourd'hui (sur le haut de gamme): le processus BGP lui-même est assisté par 
le hard.

Je ne suis pas sûr qu'on puisse appeler çà du progrès. De l'évolution, 
certainement. Mais c'est une arme à double-tranchant: le CPU qui marche plus 
vite, la mémoire qui ne coûte presque plus rien, et le 10GigE pour pas trop 
cher c'est une évolution mais ça peut être contraire au progrès, dans le sens 
que finalement c'est la loi de Moore qui permet au routeur de gérer plus de 
merde qu'avant, mais que finalement c'est toujours la même merde qu'hier sauf 
qu'on en mange plus en moins de temps.

Peut-être que je me mélange les pinceaux entre progrès et évolution, aussi.

Michel.

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

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

2011-02-23 Par sujet Stephane Bortzmeyer 
On Wed, Feb 23, 2011 at 11:24:06AM +0100,
 Rémi Bouhl  wrote 
 a message of 36 lines which said:

> À ce sujet, comment les différentes solutions envisagées comptent
> authentifier l'identificateur?

Cela dépend. 

> Sur le modèle des clefs SSH ou GPG, où la clef publique servirait
> d'identificateur?

C'est le modèle popularisé par HIP
 et je l'ai toujours trouvé
très cool.

ILNP a une approche différente : il n'impose pas une politique
particulière d'authentification. L'identificateur peut être une
adresse MAC (car elles sont uniques, sans créer de nouveaux mécanismes
d'allocation), dans ce cas elle n'est pas authentifiée, mais il peut
aussi être un CGA  et, dans ce
cas, ça fonctionne un peu comme HIP.

Comme, avec ILNP, tout est mis dans le DNS, on peut aussi faire des
vérifications comme les actuelles (adresse IP -> PTR -> ) et voir
si on retrouve le point de départ.

Pour LISP, euh, je ne me souviens pas, faut que je relise les
Internet-Drafts.
---
Liste de diffusion du FRnOG
http://www.frnog.org/

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 sécurité, cela marche très bien.
> 


À ce sujet, comment les différentes solutions envisagées comptent
authentifier l'identificateur?

Sur le modèle des clefs SSH ou GPG, où la clef publique servirait
d'identificateur?

Cette solution aurait l'avantage de rendre totalement indépendant de
tout fournisseur le client final. Je crée mon identificateur, et je
garde mon identité numérique à vie, même en changeant de terminal, de
pays, de FAI.. Si ça peut être routé automatiquement dès que je me
connecte dans un cybercafé, ou chez un ami, et qu'il y a en plus une
couche de sécurité, on tient un système parfait.

Le système des "Freemails" sur Freenet ressemble à ça, si on considère
qu'un "node" de plusieurs Go, et une machine virtuelle Java, sont
portables.

Ou bien, on peut se retrouver avec un/des organismes qui distribuent et
signent les identificateurs, comme c'est le cas avec la hiérarchie des
DNS ou des certificats SSL, ou encore des numéros de téléphone
(fussent-ils portables). C'est beaucoup moins indépendant..

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

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

2011-02-23 Par sujet Stephane Bortzmeyer 
On Tue, Feb 22, 2011 at 08:04:22PM -0800,
 Michel Py  wrote 
 a message of 53 lines which said:

> La seule chose que j'ajouterai: les solutions (comme INLP) fondées
> sur la séparation entre identificateur et localisateur ne sont pas
> nouvelles. 

Certes. Elles ne prétendent d'ailleurs pas l'être. Ceci dit, entre
dire « il faut séparer l'identificateur et le localisateur » et une
norme complète, cohérente, gérant les cas vicieux et raisonnablement
sécurisée, il y a de la marge. Le travail du RRG était justement de
passer d'une vieille idée « dos de l'enveloppe » à une architecture
correctement définie et réaliste (je rappelle que plusieurs des
propositions de séparation entre identificateur et localisateur
contenaient des raccourcis du genre « supposons un mécanisme de
correspondance entre I et L qui passe à l'échelle, soit sûr, bon
marché et soit déployé »...)

> La plus ancienne dont je me rappelle (avant la mienne) est 8+8 de
> Mike O'Dell, en
> 1996. http://arneill-py.sacramento.ca.us/ipv6mh/draft-odell-8+8-00.txt. A
> noter dans 16. Closing Comments, bien des noms familiers.

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 sécurité, cela marche très bien.

> Toutes ces solutions se sont régulièrement fait tailler en pièces
> par l'IETF dans le passé. 

Pour de bonnes raisons. À noter que les opérateurs (ceux dans les
tranchées) n'étaient pas forcément enthousiastes non plus. Quel abonné
à FRNOG a commencé à déployer LISP ?

> Je n'ai remarqué depuis 15 ans aucun changement qui permettrait
> d'espérer qu'une de ces idées voie le jour.

Là, je ne suis pas d'accord, la science a progressé pendant ces 15
ans.

> En ce qui concerne ILNP, je prédis que le consensus concernant
> l'utilisation de DNS sera difficile à obtenir. Beaucoup y ont pensé,
> et encore plus respectent ceci:
> 
> > For example, routing must not depend on look-ups in the Domain
> > Name System (DNS), since the updating of DNS servers depends on
> > successful routing. [RFC 1958]

Résultat, les propositions non-DNS (comme LISP) reposent toutes sur un
nouveau système de correspondance entre noms et valeurs, qu'il va
falloir spécifier (avec passage à l'échelle, résistance aux pannes et
sécurité), développer, déployer, et sans que ledit système ait un
modèle économique établi. Qui est irréaliste ? :-)

> Imaginez les enfants, les route-maps de redistribution entre BGP et
> {OSPF|ISIS} il faudrait rajouter ILNP, donc au lieu de 2 route-maps
> on en aurait 6, quel pied géant.

Mauvais troll, changer de troll. ILNP, comme HIP (mais contrairement à
LISP), est purement dans les machines terminales (et, dans certains
cas, dans les routeurs de connexion du réseau local à l'Internet). Les
routeurs du coeur, ceux des abonnés de FRNOG, continuent à router
comme avant.

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