On 25/10/2012 09:05, Stephane Bortzmeyer wrote:
Le RFC 6769 ayant été publié, c'est l'occasion de revisiter le dossier
:-)
http://www.bortzmeyer.org/6769.html
Tiens, ça tombe à pic : pourquoi donc le FIR aurait besoin d'une FIB ?
Ca peut être un simple route-server, donc 100% logiciel, à partir du
moment ou les vues transmises aux FSR couvrent bien toute la DFZ de la
façon la moins destructrice possible.
L'autre point gênant à mon avis est le risque de ne pas voir arriver le
support de cette RFC sur des machines bien déployées mais un peu
anciennes (6k5 en 3b, BI4k, GSR/BFR anyone ?).
Avec un route-server en guise de FIR, et des vues optimisées envoyées
aux FSR en iBGP, les sessions externes en eBGP multihop, ça devient
possible.
Le principal problème d'implémentation que je rencontre en prototypage
c'est le délai de synchronisation entre le route-server et les ASBR (FSR
dans ce document), principalement lorsqu'un update externe requiert
beaucoup d'updates de la vue compressée pour la mettre en conformité.
Pour ça j'imagine qu'une session de feedback ou l'ASBR ré-annonce sa RIB
courante au FSR afin que ce dernier puisse calculer les updates minimaux
à envoyer pour converger vers la vue théorique.
On y gagne par contre une certaine facilité à implémenter le Path
Exploration Dampening puisque les RS peuvent facilement construire le
graphe d'adjacence et anticiper ou temporiser la prise en compte des
annonces des voisins.
Le problème devient alors purement algorithmique, et consiste à
maintenir une information de reachability réaliste quelque soit la
séquence de convergence calculée.
N'ayant pas encore épluché tous les posts de "grow", saurais tu me dire
si cette problématique a été adressée ?
Merci !
--
Jérôme Nicolle
06 19 31 27 14
---------------------------
Liste de diffusion du FRnOG
http://www.frnog.org/
