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