<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hola nico.<div><br></div><div><br><div><div>On May 27, 2008, at 6:45 PM, Nicolas Antoniello wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">-----BEGIN PGP SIGNED MESSAGE-----<br>Hash: SHA1<br><br>Sobre este tema, y continuando un poco la charla que inicio Roque en <br>su presentación de hoy, quería hacer un par de comentarios:<br><br>- - La desagregacion en algunos casos creo que no es evitable... por <br>ejemplo, del lado de operación, tenemos casos en los que un bloque / <br>21 asignado para un pool de direcciones de servicios DSL puede <br>generar un trafico entrante de mas de 200 megas. En ese caso, aun <br>cuando se tiene un solo carrier Tier-1, si se tienen por ejemplo 4 o <br>5 enlaces STM-1 y/o algun STM-4 se tiene que desagregar para evitar </blockquote><blockquote type="cite">saturar los enlaces.<br></blockquote><div><br></div><div>totalmente de acuerdo en que hay situaciones en que es necesario desagregar para tener enlaces hot-hot.</div><div><br></div><div>Ahora en el ejemplo que tu das es posible realizar configuraciones con comunidades BGP (particularmente no-export) para que la desagregación sea local entre el proveedor y su upstream, pero no se disemine al resto del mundo.</div><div><br></div><div>Ejemplo, tienes un /21 que ocupa 200 megas y dos enlaces STM-1. Anuncias 1x/22 en cada enlace (uno en cada uno) con comunidad "no export" correspondiente y un /21 sin esa comunidad.</div><div><br></div><div>El upstream ve los /22, pero el resto del mundo solo el /21. El resto del mundo solo sabe como llegar al /21, cuando los paquetes lleguen al upstream, el decide por longest-match por el enlace que tiene el /22 pertinente.</div><div><br></div><div>Esto no ocupa todos los casos, el mensaje que quería transmitir es... ponga la agregación como una meta en sus anuncios, por que tu upstream te permita publicar /24, no quiere decir que lo vas a hacer.</div><br><blockquote type="cite">Otras posibles soluciones podrían pasar por realizar un bundle (LAG) <br>con todos los enlaces, pero en ese caso, se sacrificaría posiblemente <br>la redundancia ya que seria casi necesario que los enlaces terminaran <br>todo en el mismo equipo del proveedor... o al menos, que los caminos <br>sean simétricos con alguna sesión BGP multihop contra un equipo <br>equidistante.<br><br>- - Parece claro que en caso de que sea necesaria la desagregacion a la <br>hora de publicar bloques a los carriers, se lograria que el resto del <br>mundo no viera esas rutas si ellas son publicadas utilizando una <br>comunidad proporcionada por el proveedor que evite que dichos bloques <br>se propaguen al resto del mundo. Obviamente tenemos que publicar al <br>proveedor el superbloque correspondiente sin marcarlo con dicha <br>comunidad. :)<br><br></blockquote><div><br></div>eso es lo que comente antes.</div><div><br><blockquote type="cite">- - Otro motivante de desagregacion es el mismo caso de múltiples <br>enlaces relativamente pequeños en un escenario de multihoming. Por <br>ejemplo, cuando se quiere dar cierta preferencia a bloques de <br>clientes "gold" frente a clientes "silver" por ejemplo.<br>Nuevamente podemos publicar los superbloques, pero en el caso de <br>multihoming igualmente tendríamos cierta desagregacion entre los <br>diferentes carriers pues si publicamos el mismo superbloque por <br>ambos, seguramente el protocolo BGP preferira uno de los 2 caminos.<br>En este sentido, el tema de dejar que BGP haga su trabajo, sin <br>ingeniería de trafico provocaría que uno de los carriers <br>prácticamente no tuviera trafico... sobre todo si se trata de <br>carriers "cercanos", o mas formalmente dicho, que poseen <br>prácticamente las mismas rutas con prácticamente igual numero de <br>saltos de ASs hacia los orígenes de trafico.<br><br>Que opinan?</blockquote><blockquote type="cite">Saludos,<br>Nicolas.<br><br><br><br>On 27/05/2008, at 06:11 PM, Roque Gagliano wrote:<br><br><blockquote type="cite">-----BEGIN PGP SIGNED MESSAGE-----<br></blockquote><blockquote type="cite">Hash: SHA1<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Hola,<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">para comentar sobre mi presentacion recibi algun comentario en el<br></blockquote><blockquote type="cite">piso, les cuento que los datos se hacen desde un router "cliente" sin<br></blockquote><blockquote type="cite">vinculos de peering y con su propio ASN, por lo que no conoce las<br></blockquote><blockquote type="cite">rutas internas de los tier-1, por lo que lo podemos considerar neutral<br></blockquote><blockquote type="cite">respecto a la topologia de cada cliente con algun proveedor de <br></blockquote><blockquote type="cite">transito.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">slds<br></blockquote><blockquote type="cite">r.<br></blockquote><blockquote type="cite">-----BEGIN PGP SIGNATURE-----<br></blockquote><blockquote type="cite">Version: GnuPG v1.4.8 (Darwin)<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">iEYEARECAAYFAkg8eRkACgkQnk+WSgHpbO53jACeMXwMCUiq4GwJ0o6WYppCZQy3<br></blockquote><blockquote type="cite">CDkAmwXHXhuXInCc7OsZgfGsO6UaBvW9<br></blockquote><blockquote type="cite">=fa/d<br></blockquote><blockquote type="cite">-----END PGP SIGNATURE-----<br></blockquote><blockquote type="cite">_______________________________________________<br></blockquote><blockquote type="cite">LACNOG mailing list<br></blockquote><blockquote type="cite"><a href="mailto:LACNOG@lacnic.net">LACNOG@lacnic.net</a><br></blockquote><blockquote type="cite"><a href="https://mail.lacnic.net/mailman/listinfo/lacnog">https://mail.lacnic.net/mailman/listinfo/lacnog</a><br></blockquote><br>-----BEGIN PGP SIGNATURE-----<br>Version: GnuPG v1.4.7 (Darwin)<br><br>iD8DBQFIPIDy1fu3N7aWArMRAjKxAJ0W3zQ6yEODnzu+6HxwlveSbAigrwCeMewf<br>tobzSAwOSmqt/nWuen4Rf28=<br>=rBMv<br>-----END PGP SIGNATURE-----<br>_______________________________________________<br>LACNOG mailing list<br><a href="mailto:LACNOG@lacnic.net">LACNOG@lacnic.net</a><br><a href="https://mail.lacnic.net/mailman/listinfo/lacnog">https://mail.lacnic.net/mailman/listinfo/lacnog</a><br></blockquote></div><br></div></body></html>