<br>    Creo que independientemente del multihoming (que es un problema para agregar rutas) una buena parte del exceso de rutas no agregadas es que no somos ordenados como operadores. Yo tengo un rato de no revisar las tablas de BGP pero recuerdo haber visto muchos /24 (y menores) de bloques que podrian ser agregados facilemnte. En este caso el dueño del bloque era el anunciante, asi que no habia problemas de multihoming o necesidad de anunciar particionado.
<br><br>   Espero que esta lista y el correo de Ricardo Patara pueda servir para que cada quien le eche un ojo a sus anuncios y empiece labores de limpieza. ;- )<br><br>Saludos,<br>-as<br><br><div class="gmail_quote">On Dec 12, 2007 2:00 PM,  <
<a href="mailto:lacnog-request@lacnic.net">lacnog-request@lacnic.net</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Send lacnog mailing list submissions to
<br>        <a href="mailto:lacnog@lacnic.net">lacnog@lacnic.net</a><br><br>To subscribe or unsubscribe via the World Wide Web, visit<br>        <a href="https://mail.lacnic.net/mailman/listinfo/lacnog" target="_blank">https://mail.lacnic.net/mailman/listinfo/lacnog
</a><br>or, via email, send a message with subject or body 'help' to<br>        <a href="mailto:lacnog-request@lacnic.net">lacnog-request@lacnic.net</a><br><br>You can reach the person managing the list at<br>        
<a href="mailto:lacnog-owner@lacnic.net">lacnog-owner@lacnic.net</a><br><br>When replying, please edit your Subject line so it is more specific<br>than "Re: Contents of lacnog digest..."<br><br><br>Today's Topics:
<br><br>   1. Re:  agregacion de rutas / routing aggregation<br>      (Nicolas Antoniello)<br><br><br>----------------------------------------------------------------------<br><br>Message: 1<br>Date: Wed, 12 Dec 2007 10:19:12 -0200
<br>From: Nicolas Antoniello <<a href="mailto:nicolas@antel.net.uy">nicolas@antel.net.uy</a>><br>Subject: Re: [lacnog] agregacion de rutas / routing aggregation<br>To: Latin America and Caribbean Region Network Operators Group
<br>        <<a href="mailto:lacnog@lacnic.net">lacnog@lacnic.net</a>><br>Message-ID: <<a href="mailto:475FD1C0.90709@antel.net.uy">475FD1C0.90709@antel.net.uy</a>><br>Content-Type: text/plain; charset=ISO-8859-1
<br><br>Hola Ricardo y todos,<br>Que tal?<br><br>De este tema de agregaci?n/desagregaci?n de rutas creo que se ha hablado en innumerables<br>foros, innumerables veces en cada uno de ellos.<br>Tal vez, el problema de tener un factor tan grande de desagregaci?n en nuestra regi?n
<br>responda no tanto a desinformaci?n sino mas bien se me ocurren un par de factores, que<br>tambi?n pueden contribuir.<br>Uno de ellos puede ser el costo del ancho de banda y la tendencia a Multihoming con muchos<br>enlaces peque?os, consecuencia tal vez de la econom?a de muchas empresas de la regi?n.
<br>Si sumamos esto a que el uso de comunidades (que parece ser la soluci?n mas "sensata" a la<br>desagregaci?n) es cierto que no esta tan difundido en lo que respecta a nuestra regi?n (al<br>menos eso creo), tenemos como resultado que el mecanismo mas simple y comunmente utilizado
<br> es justamente el que menciona en el texto que env?as: publicar sub-prefijos de los<br>bloques, teniendo en cuenta el tr?fico total de cada uno de esos sub-prefijos generado por<br>los equipos que lo integran.<br><br>
Es decir, que si tenemos por ejemplo un prefijo /16 que un ISP utiliza como pool de ADSL<br>por ejemplo, y la conectividad a internet consiste en una serie de enlaces de ancho de<br>banda medianamente reducido (digamos que unos cuantos STM-1 y algun STM-4 con 2 o 3
<br>Carriers) es bastante com?n y necesaria la desagregaci?n (a menos que justamente utilicen<br>comunidades y algun otro "artilugio").<br><br>Ahora bien, que pasa con el uso de comunidades? Bueno, lo que creo es que en muchos casos,
<br>esos enlaces a internet que mencionaba, terminan en una misma regi?n (incluso cuando hago<br>multihoming), o incluso en un mismo pa?s (USA por ejemplo)... entonces, se vuelve bastante<br>complicado el distribuir tr?fico utilizando las comunidades que proveen los Carriers en el
<br>sentido que probablemente los peers de cada uno sean bastante similares (o coincidan<br>bastante) con lo cual, puede que no logre el efecto de reparto de tr?fico deseado.<br>Mas a?n, el uso de comunidades requiere un dise?o de la red en ppio. un poco mas fino que
<br>el reparto utilizando subnets, y requiere tambi?n un monitoreo bastante peri?dico del<br>camino que esta siguiendo la informaci?n, del estado de carga de cada enlace, seguimiento<br>de los peers y de las comunidades que acepta cada carrier, etc... cosa que no todas las
<br>empresas est?n dispuestas a realizar.<br><br>Algo que creo que podr?a mejorar eso, es el fomentar la interconexi?n regional y lo puntos<br>de intercambio de tr?fico dentro de la regi?n, ya que si economicamente es conveniente
<br>aunque no lo sea inmediatamente (pero si a mediano y largo plazo) interconectarse<br>regionalmente o tener IXPs cercanos donde uno acceda a peering con mas empresas, en ese<br>caso, combinando eso con el uso de comunidades y con alguna forma de "partial routing",
<br>creo que se podr?a reducir much?simo el factor de desagregaci?n.<br><br>Por supuesto que existen m?s factores, los que menciono son algunos de los que se me<br>ocurre pueden ser los mas incidentes.<br><br>Que opinan?<br>
<br>Saludos,<br>Nicolas.<br><br><br>Ricardo Patara wrote:<br>> Estimados Amigos.<br>><br>> ** [english version bellow] **<br>><br>> Ese es el primer email a la lista y por lo tanto, quer?a darles a todos<br>
> la bienvenida.<br>><br>> Como todos saben, esa lista se trata de un foro para operadores de redes y creo<br>> que un tema muy interesante que quisiera discutir es lo de desagregaci?n de<br>> rutas.<br>>
<br>> Existen algunos grupos que investigan las tablas de rutas y hacen c?lculos de<br>> cuanto se podr?a "economizar" en espacio de memoria de ruteadores en caso de<br>> que se anunciara redes de forma agregada. Por ej, un ASN anuncia 16 bloques /24
<br>> contiguos mientras podr?a perfectamente anunciar uno solo bloque /20.<br>> Eso representa una econom?a significativa en la cantidad de lineas en la tabla<br>> de rutas.<br>><br>> Estos estudios indican que en nuestra regi?n hay un factor desagregaci?n de
<br>> 3.65. O sea, la tabla es 3.65 veces mas grande de que si se hiciera las posibles<br>> agregaciones de prefijos.<br>><br>> Ese factor de desagregaci?n en otras regiones es mas bajo:<br>> APNIC: 2.65<br>
> ARIN: 1.74<br>> RIPE: 1.55<br>> AFRINIC: 2.98<br>><br>> Seguramente existen casos que hay necesidad para la desagregaci?n de las rutas.<br>> Pero no me parece que tengamos en nuestra regi?n una situaci?n especial que
<br>> implique en valores de desagregaci?n tan m?s altos que de otras regiones.<br>> Uno de los motivos puede ser falta de informaci?n.<br>><br>> Que les parece?<br>><br>> Igual, les env?o en anexo la traducci?n de un documento muy interesante que es
<br>> resultado de un grupo de trabajo acerca de routing en RIPE.<br>> El original esta en: <a href="http://www.ripe.net/ripe/docs/ripe-399.htm" target="_blank">http://www.ripe.net/ripe/docs/ripe-399.htm</a><br>> Lo que les env?o es una "adaptaci?n" que hice para el espa?ol.
<br>> Desde de mi punto de vista, es una lectura recomendada :)<br>><br>> un saludo!<br>> Ricardo Patara<br>><br>><br>><br>><br>> ** [english version] **<br>><br>> Dear Friends<br>><br>
> This is the first email to this list, so I would like to give everyone a<br>> welcome.<br>><br>> As you all know, this is a forum for network operators and I believe that<br>> routing aggregation is a good subject to be discussed among us.
<br>><br>> There are some groups who study the routing table and produce indications<br>> about how many routing slots could be saved in case of announcing aggregated<br>> routes. For instance, suppose an ASN announcing 16 contiguous /24s while at the
<br>> same time this ASN could perfectly announce just one /20. This would represent<br>> significant saving in number of lines needed in the routing table.<br>><br>> Those studies indicate that there is in our region a deaggregation ratio of
<br>> 3.65. This means that the routing table is 3.65 bigger than it would be if<br>> routes were announced in aggregated fashion.<br>><br>> This deaggregation factor is smaller in other regions:<br>> APNIC: 
2.65<br>> ARIN: 1.74<br>> RIPE: 1.55<br>> AFRINIC: 2.98<br>><br>> It is certain that there might be good reasons for deaggregation. But I don't<br>> think we have a special situation in our region to justify such bigger ratio
<br>> compared to the other regions.<br>> One of the reasons could be lack of information.<br>><br>> What do you all think?<br>><br>> I am sending in attach a document in spanish which is an adaptation of the
<br>> original produced by the RIPE routing working group available at:<br>> <a href="http://www.ripe.net/ripe/docs/ripe-399.htm" target="_blank">http://www.ripe.net/ripe/docs/ripe-399.htm</a><br>> In my point of view, it is recommended reading :)
<br>><br>> regards<br>> Ricardo Patara<br>><br>><br>> ------------------------------------------------------------------------<br>><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" target="_blank">https://mail.lacnic.net/mailman/listinfo/lacnog</a><br><br><br>------------------------------
<br><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" target="_blank">https://mail.lacnic.net/mailman/listinfo/lacnog
</a><br><br><br>End of lacnog Digest, Vol 1, Issue 3<br>************************************<br></blockquote></div><br>