> David Ponzone a écrit : > Tu essaies de faire passer pour simple un truc très compliqué. L’AS-PATH > permet pas vraiment de faire > un choix pertinent. Un lien de transit peut être un chemin saturé, de même > pour un peering, etc... > L’idée d’un prepend entrant c’est juste de ré-équilibrer le sortant vers un > tier-2 (qui dépend donc de > tier-1) plutôt que vers mon tier-1, puisque les AS-PATH venant du tier-2 > feront souvent 1 AS de plus.
Je comprends parfaitement ta logique : avec prepend en entrée, tu rajoutes un handicap aux routes d'un transit, et çà traite toutes les routes pareil et dont elles ont toujours une chance d'être évaluées et préférées ou pas plus tard quand l'AS-PATH est comparé. Alors que quand tu changes localpref, c'est un peu "tout ou rien", et donc que pour être granulaire il faut choisir les routes qu'on défavorise, avec des critères plus ou moins arbitraires. Le prepend, c'est plus égalitaire, ce que ça fait c'est de mettre tout le monde à niveau en rajoutant un handicap au transit(s) qui de part leur tier sont favorisés par un AS-PATH généralement plus court, donc qui ont tendance à attirer le trafic comparé à un transit plus petit. Je suis relativement d'accord pour dire que les critères de sélection utilisés pour changer localpref sont souvent aléatoires ou arbitraitres, mais reste le problème suivant : quelles routes tu donnes aux clients downstream qui t'achètent du transit ? Si tu me donnes un feed avec les routes venant de ton transit tier-1 prependées, je vais hurler. Là on est en train de parler des limites fondamentales de BGP et du système Path Vector : le processus de décision est trop déterministe; au lieu de dire "on regarde localpref, si c'est la même on regarde la longueur de l'AS-PATH", il aurait été plus souple de construire un metric composite du genre "localpref compte pour x% des points, la longueur de l'AS-PATH compte pour y%". Mais c'est pas comme ça que ca marche; et il y a plein d'inconvénients et de produits dérivés pas sympa (par exemple : le trafic asymétrique) > Si tu as une autre idée, je prends. Je te retourne la faveur : tu veux remplacer BGP ? :P Le système n'a pas que des inconvénients, et il y a beaucoup de choses qui en dépendent. Bon an mal an ça marche pas si mal, a part les abominations du genre optimiseur qui injecte des préfixes longs et les bachibouzouks qui ne connaissent ni no-export ni max-prefix, avec RPKI ça reste potable. Ca me rappelle un autre protocole, pour remplacer le système en place, c'est pas facile; faut qu'il y ait des avantages significatifs et un plan de transition qui tient la route, ce que je ne vois pas ni aujourd'hui ni demain. > Ceci dit, tout cela est assez futile car même en B2B, le plus gros du trafic > vient d’une poignée d’AS, que tu peux généralement avoir en peering. Je t'envie. > En GP, j’en parle même pas, on pourrait presque vivre sans transit avec 10 > peelings :) J’exagère, à peine... Pas ici; j'ai l'impression que la notion même de peering est en train de disparaitre. Ici, pour peerer il faut souvent payer, à un niveau qui fait que ça ne vaut pas souvent le coup et qu'acheter du transit est souvent préféré. Michel. --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
