[lacnog] agregacion de rutas / routing aggregation

[Nicolas Antoniello]

Hola Ricardo y todos,
Que tal?

De este tema de agregación/desagregación de rutas creo que se ha hablado en innumerables
foros, innumerables veces en cada uno de ellos.
Tal vez, el problema de tener un factor tan grande de desagregación en nuestra región
responda no tanto a desinformación sino mas bien se me ocurren un par de factores, que
también pueden contribuir.
Uno de ellos puede ser el costo del ancho de banda y la tendencia a Multihoming con muchos
enlaces pequeños, consecuencia tal vez de la economía de muchas empresas de la región.
Si sumamos esto a que el uso de comunidades (que parece ser la solución mas "sensata" a la
desagregación) es cierto que no esta tan difundido en lo que respecta a nuestra región (al
menos eso creo), tenemos como resultado que el mecanismo mas simple y comunmente utilizado
 es justamente el que menciona en el texto que envías: publicar sub-prefijos de los
bloques, teniendo en cuenta el tráfico total de cada uno de esos sub-prefijos generado por
los equipos que lo integran.

Es decir, que si tenemos por ejemplo un prefijo /16 que un ISP utiliza como pool de ADSL
por ejemplo, y la conectividad a internet consiste en una serie de enlaces de ancho de
banda medianamente reducido (digamos que unos cuantos STM-1 y algun STM-4 con 2 o 3
Carriers) es bastante común y necesaria la desagregación (a menos que justamente utilicen
comunidades y algun otro "artilugio").

Ahora bien, que pasa con el uso de comunidades? Bueno, lo que creo es que en muchos casos,
esos enlaces a internet que mencionaba, terminan en una misma región (incluso cuando hago
multihoming), o incluso en un mismo país (USA por ejemplo)... entonces, se vuelve bastante
complicado el distribuir tráfico utilizando las comunidades que proveen los Carriers en el
sentido que probablemente los peers de cada uno sean bastante similares (o coincidan
bastante) con lo cual, puede que no logre el efecto de reparto de tráfico deseado.
Mas aún, el uso de comunidades requiere un diseño de la red en ppio. un poco mas fino que
el reparto utilizando subnets, y requiere también un monitoreo bastante periódico del
camino que esta siguiendo la información, del estado de carga de cada enlace, seguimiento
de los peers y de las comunidades que acepta cada carrier, etc... cosa que no todas las
empresas están dispuestas a realizar.

Algo que creo que podría mejorar eso, es el fomentar la interconexión regional y lo puntos
de intercambio de tráfico dentro de la región, ya que si economicamente es conveniente
aunque no lo sea inmediatamente (pero si a mediano y largo plazo) interconectarse
regionalmente o tener IXPs cercanos donde uno acceda a peering con mas empresas, en ese
caso, combinando eso con el uso de comunidades y con alguna forma de "partial routing",
creo que se podría reducir muchísimo el factor de desagregación.

Por supuesto que existen más factores, los que menciono son algunos de los que se me
ocurre pueden ser los mas incidentes.

Que opinan?

Saludos,
Nicolas.


Ricardo Patara wrote:
> Estimados Amigos.
> 
> ** [english version bellow] **
> 
> Ese es el primer email a la lista y por lo tanto, quería darles a todos
> la bienvenida.
> 
> Como todos saben, esa lista se trata de un foro para operadores de redes y creo
> que un tema muy interesante que quisiera discutir es lo de desagregación de
> rutas.
> 
> Existen algunos grupos que investigan las tablas de rutas y hacen cálculos de
> cuanto se podría "economizar" en espacio de memoria de ruteadores en caso de
> que se anunciara redes de forma agregada. Por ej, un ASN anuncia 16 bloques /24
> contiguos mientras podría perfectamente anunciar uno solo bloque /20.
> Eso representa una economía significativa en la cantidad de lineas en la tabla
> de rutas.
> 
> Estos estudios indican que en nuestra región hay un factor desagregación de
> 3.65. O sea, la tabla es 3.65 veces mas grande de que si se hiciera las posibles
> agregaciones de prefijos.
> 
> Ese factor de desagregación en otras regiones es mas bajo:
> APNIC: 2.65
> ARIN: 1.74
> RIPE: 1.55
> AFRINIC: 2.98
> 
> Seguramente existen casos que hay necesidad para la desagregación de las rutas.
> Pero no me parece que tengamos en nuestra región una situación especial que
> implique en valores de desagregación tan más altos que de otras regiones.
> Uno de los motivos puede ser falta de información.
> 
> Que les parece?
> 
> Igual, les envío en anexo la traducción de un documento muy interesante que es
> resultado de un grupo de trabajo acerca de routing en RIPE.
> El original esta en: http://www.ripe.net/ripe/docs/ripe-399.htm
> Lo que les envío es una "adaptación" que hice para el español.
> Desde de mi punto de vista, es una lectura recomendada :)
> 
> un saludo!
> Ricardo Patara
> 
> 
> 
> 
> ** [english version] **
> 
> Dear Friends
> 
> This is the first email to this list, so I would like to give everyone a
> welcome.
> 
> As you all know, this is a forum for network operators and I believe that
> routing aggregation is a good subject to be discussed among us.
> 
> There are some groups who study the routing table and produce indications
> about how many routing slots could be saved in case of announcing aggregated
> routes. For instance, suppose an ASN announcing 16 contiguous /24s while at the
> same time this ASN could perfectly announce just one /20. This would represent
> significant saving in number of lines needed in the routing table.
> 
> Those studies indicate that there is in our region a deaggregation ratio of
> 3.65. This means that the routing table is 3.65 bigger than it would be if
> routes were announced in aggregated fashion.
> 
> This deaggregation factor is smaller in other regions:
> APNIC: 2.65
> ARIN: 1.74
> RIPE: 1.55
> AFRINIC: 2.98
> 
> It is certain that there might be good reasons for deaggregation. But I don't
> think we have a special situation in our region to justify such bigger ratio
> compared to the other regions.
> One of the reasons could be lack of information.
> 
> What do you all think?
> 
> I am sending in attach a document in spanish which is an adaptation of the
> original produced by the RIPE routing working group available at:
> http://www.ripe.net/ripe/docs/ripe-399.htm
> In my point of view, it is recommended reading :)
> 
> regards
> Ricardo Patara
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> lacnog mailing list
> lacnog en lacnic.net
> https://mail.lacnic.net/mailman/listinfo/lacnog