[LACNIC/Politicas] Pol í tica de publicaciones de bloques IPv6 (propuesta para modificacion de politica)

Sun Mar 18 16:04:55 BRT 2007

Si efectivamente, no se si es esa la ultima version. Sorry, lo comente
cuando hablamos por primera vez de este tema hace un mes o dos, y ahora yo
lo tenia en mente, pero quizas para otros participantes de la lista estaba
fuera de contexto.

> De: Roque Gagliano <rgaglian at antel.net.uy>
> Responder a: <rgaglian at antel.net.uy>
> Fecha: Sun, 18 Mar 2007 14:50:53 -0300
> Para: <jordi.palet at consulintel.es>, LACNIC Policy mailling list
> <politicas at lacnic.net>
> Asunto: Re: [LACNIC/Politicas] Pol í tica de publicaciones de bloques IPv6
> (propuesta para modificacion de politica)
> 
> Jordi,
> 
> Cuanda hablas del documento dentro del v6ops, te refieres a:
>   draft-ietf-v6ops-routing-guidelines-01.txt?
> 
> slds
> r.
> 
> 
> On Mar 18, 2007, at 7:48 AM, JORDI PALET MARTINEZ wrote:
> 
>> Hola Roque,
>> 
>> Te contesto debajo, entre-lineas.
>> 
>> Saludos,
>> Jordi
>> 
>> 
>> 
>> 
>>> De: Roque Gagliano <rgaglian at antel.net.uy>
>>> Responder a: LACNIC Policy mailling list <politicas at lacnic.net>
>>> Fecha: Sat, 17 Mar 2007 10:51:50 -0300
>>> Para: LACNIC Policy mailling list <politicas at lacnic.net>
>>> Asunto: Re: [LACNIC/Politicas] Pol í tica de publicaciones de
>>> bloques IPv6
>>> (propuesta para modificacion de politica)
>>> 
>>> Jordi,
>>> 
>>> Te contesto entre líneas.
>>> 
>>> On Mar 17, 2007, at 7:09 AM, JORDI PALET MARTINEZ wrote:
>>> 
>>>> Hola Nicolas,
>>>> 
>>>> Ademas de que opino que lo que propones va en contra del diseño
>>>> original de
>>>> IPv6 por parte de IETF (y por tanto quizas debiera de ser algo
>>>> realizado
>>>> alli antes que en los RIR, pues no creo que sea logico que las
>>>> politicas
>>>> sean contrarias a los estandares)
>>>> 
>>> 
>>> Creo que estamos confundiendo el tema. La politica no apunta a
>>> resolver el problema de qué pasa con prefijos menores a un /32 (site
>>> multi-homing) sino eliminar de la política IPv6 la "obligación" de
>>> que un proveedor deba publicar su bloque asignado (por ejemplo un /
>>> 28) como un sólo prefijo. Todo aquello menor a un /32 sabemos que en
>>> general no va a ser ruteado.
>> 
>> Creo que no lo he confundido. No me estoy refiriendo a prefijos mas
>> pequeños
>> de /32 (en realidad mas largos, bloques de direcciones mas
>> pequeños), sino
>> al texto propuesto por Nicolas, asunto que ya comentamos
>> anteriormente en la
>> lista.
>> 
>>> 
>>> Cuanda hay un BCP que resuelva el problema, podemos simplemente
>>> referenciarlo como hemos hecho en otros casos. Por ahora no lo hay y
>>> no podemos desde una política hacerlo.
>> 
>> Lo logico es trabajar en ese BCP en IETF (y de hecho hay un
>> documento en
>> curso al respecto en v6ops), asi que lo suyo es contribuir a ese
>> documento y
>> si la conclusion es que hay que cambiar la politica, pues se cambia
>> una vez
>> que IETF haga una recomendación al respecto, pero hoy por hoy, la
>> recomendación es no romper la agregacion (no realizar anuncios
>> desagregados).
>> 
>> Si un ISP desda romper la agregacion, como de hecho ya lo hacen
>> algunos,
>> nadie le va a impedir que lo haga, y sera la comunidad la que
>> decida, bien
>> mediante la exigencia de la aplicación rigurosa de la politica, o
>> bien el
>> mercado (el filtrado de las desagregaciones, como asi ya ocurre a
>> algunos).
>> 
>> En casi todas las politicas hay facetas que los RIRs no aplican
>> estrictamente, y me parece logico hasta cierto punto, pero creo que
>> se deben
>> de mantener como medida de seguridad, porque nos permite controlar
>> el uso de
>> los recursos. Y como recursos aquí tambien me refiero a los slots
>> en las
>> tablas de routing, que tienen un coste en cierto modo oculto que
>> pagamos
>> TODOS los que tenemos BGP. Sin embargo, cuando un ISP desagrega, no
>> compensa
>> por ello a todos los demas, verdad ? Hasta que punto es eso
>> logico ? Yo
>> diria que es logico siempre y cuando no este suponiendo un
>> incremento de
>> coste "notable" al resto de los participantes de la red, pero si se
>> produce
>> una explosion y por ello llegamos a tener 100.000 entradas nuevas de
>> routing, debe de pagarse por ello, y esta politica permite que si
>> no se
>> logra "cobrar" ese perjuicio, se pueda exigir su aplicación.
>> 
>>> 
>>> La política actual además genera una injusticia importante,
>>> imaginemos que a mí me asignan un /32 y luego al año me asignan
>>> otro /
>>> 32. Yo podría publicar los dos en forma independiente. Ahora si de
>>> primera me asignan un /31, no puedo separarlo en dos /32. ¿esto es
>>> justo?, ¿realmente los RIR deberian controlar esto?, ¿acaso son la
>>> "policía" del routing?.
>>> 
>> 
>> Creo que discrepo. De la forma en la que se estan haciendo las
>> adjudicaciones y las reservas contiguas, y vosotros mismos habeis
>> pasado por
>> ello, al igual que al menos otros dos ISPs en la region que yo
>> recuerde
>> ahora mismo, si necesitas un prefijo mas grande, se te amplia la
>> asignacion.
>> Es decir, no se te entrega un nuevo /32, sino que tu /32 se
>> convierte en un
>> /31, /30, etc.
>> 
>> Luego no se produce una injusticia. De hecho, pienso que en ningun
>> RIR ha
>> habido este caso hasta el momento, y espero que no ocurra.
>> 
>> Es mas, diria que si un ISP intenta "jugar sucio" y pide un /32, a
>> sabiendas
>> de que necesita un /30, y por cualquier motivo ello no fuera
>> posible, pienso
>> que deberia de plantearse que se le exija renumerar su red a un /30
>> nuevo,
>> para evitar que alguien intente dicho "juego".
>> 
>>>> Como es evidente, yo en principio estoy en contra de esta propuesta
>>>> y creo
>>>> que no se deben usar politicas para "corregir" *supuestos*
>>>> defectos de
>>>> diseño, cuando en realidad lo que pretendemos es duplicar errores
>>>> cometidos
>>>> con IPv4, en lugar de buscar otras soluciones tecnicas como es
>>>> debido, y
>>>> crear un nuevo factor de explosion de crecimiento de tablas de
>>>> routing, que
>>>> sera un importante coste para TODAS las redes, incluso aquellas
>>>> que no
>>>> desagreguen.
>>> 
>>> No veo que sea un problema de diseño de IPv6 sino es un tema de cómo
>>> se hace el routing en internet (el tema del "hot potatoes" bgp). Lo
>>> que se busca es ingeniería de tráfico. De vuelta no son los RIR el
>>> ámbito para imponer políticas de routing a los proveedores, no lo han
>>> sido en IPv4 y no lo deben ser ahora.
>> 
>> Una de las premisas del diseño de IPv6 fue evitar la desagregacion.
>> 
>> La cuestion de la ingenieria de trafico es un "defecto" tal como se
>> esta
>> haciendo con IPv4, y no debemos duplicar los errores. Ayer en la
>> reunion del
>> RRG, precisamente estuvimos viendo este tema y posible
>> alternativas. Parece
>> que pueda pasar forzosamente por la separcion de Locator/ID.
>> 
>> Tambien como te decia antes, se esta trabajando en un documento en
>> v6ops.
>> 
>> Pero en definitiva creo que nos hemos acostumbrado a hacer
>> "chapuzas" para
>> solucionar mas que los problemas, los *intereses* de cada
>> proveedor, aunque
>> esto suponga un coste para el resto de la red, y creo que esto si
>> que es
>> realmente *injusto*. Dejamos de ser buenos "netcitizens" con tal de
>> ser mas
>> competitivos a costa de cargar esos costes no solo a nuestra
>> competencia
>> sino al resto de la red. Fijate, que no lo habia pensado nunca,
>> pero en
>> muchos paises estas practicas podrian ser incluso constitutivas de
>> delito
>> (anti-competencia, anti-trust). Creo que es mejor evitar que
>> ocurra, al
>> menos desde el punto de vista *normativo* (politicas), para evitar
>> que los
>> gobiernos o los reguladores quieran meterse en ello, no te parece ?
>> 
>>> 
>>>> 
>>>> Por otro lado, esta politica SOLO tendria sentido si se logra
>>>> aprobar en
>>>> todas las regiones. Imaginemos que solo LACNIC la aprueba. Cuando
>>>> tus
>>>> prefijos desagregados lleguen a transitos de otras regiones, tu
>>>> trafico
>>>> seria filtrado, porque la desagregacion no coincide con las
>>>> asignaciones de
>>>> tu RIR. Creo que eso, en lugar de ayudarte, empeora tu situacion,
>>>> no ? De
>>>> hecho no es algo teorico, es algo que aquellos ISPs que ya
>>>> desagregan (en
>>>> contra de la politica), ya estan sufriendo (puedo poner varios
>>>> ejemplos,
>>>> pero el mas evidente es el de la propia infraestructura de APNIC,
>>>> que tiene
>>>> un /32, pero anuncian como 2x/33, en contra de su propia politica,
>>>> y dia si
>>>> dia no, no es alcanzable).
>>> 
>>> De vuelta, estamos errando a la intensión de la política. La idea es
>>> que si tenes un /28 puedas publicar 4x/30, no habría problemas con
>>> los filtros. Si vamos a lo que pasa en IPv4, no hay politica al
>>> respecto en los RIR (como deben ser) y hay un BCP no escrito donde se
>>> establece que un /24 es lo mínimo que se puede anunciar.
>> 
>> Precisamente, en IPv6 hay una politica porque es parte del diseño
>> de IPv6,
>> aprendiendo de los errores en IPv4.
>> 
>> Los filtros deben de configurarse en funcion de las adjudicaciones.
>> Un ISP
>> puede abrir la mano, pero no debemos de obligar a los demas ISPs,
>> que no
>> quieran a hacerlo, y si la consecuencia es que si el ISP A decide
>> hacerlo,
>> parte de la red no le pueda alcanzar, se lo pensara dos veces.
>> 
>> De hecho, tras mucho insistir, APNIC creo que ya se ha apuntado
>> esto en
>> serio y posiblemente se resuelva, pues dificulta el acceso a su
>> propia web y
>> considero que es muy mal ejemplo que un RIR incumpla su propia
>> politica.
>> 
>>> 
>>>> 
>>>> El problema empeorara cuando empecemos a utilizar la certificacion
>>>> de los
>>>> prefijos, ya que en ese caso, de forma automatica, todos los
>>>> routers que
>>>> usen esa tecnologia, te filtrarian.
>>>> 
>>>> Por otro lado, creo que seria bueno tener un resumen en la lista de
>>>> los
>>>> comentarios que hayas tenido de Nanog u otros foros.
>>> 
>>> Recordemos que ya hemos tenido esta discusión hace unos meses y la
>>> realidad es que los proveedores lo están haciendo pues...no hay otra
>>> solución con el sistema de routing existente. Recordemos que estamos
>>> en Sudamérica, que el BW cuesta mucha $$$ y por ende necesitamos
>>> poder hacer ingeniería de tráfico para sacarle el mayor provecho a
>>> cada enlaces. En otras regiones para grandes operadores, simplemente
>>> se publican los superprefijos en todos los enlaces y que la red lo
>>> resulve, nosotros NO podemos hacer esto.
>>> 
>> 
>> No solo en LAC el BW cuesta mucho, pero como digo, hasta que punto
>> es justo
>> que tu ahorres a costa de los demas ?
>> 
>>> 
>>>> 
>>>> Saludos,
>>>> Jordi
>>>> 
>>>> 
>>>> 
>>>> 
>>>>> De: Nicolás Antoniello <nicolas at antel.net.uy>
>>>>> Organización: MEI - ANTELDATA
>>>>> Responder a: <nantoniello at antel.net.uy>, LACNIC Policy mailling
>>>>> list
>>>>> <politicas at lacnic.net>
>>>>> Fecha: Fri, 16 Mar 2007 17:53:44 -0300 (UYT)
>>>>> Para: <politicas at lacnic.net>
>>>>> Asunto: [LACNIC/Politicas] Política de publicaciones de bloques
>>>>> IPv6
>>>>> (propuesta para modificacion de politica)
>>>>> 
>>>>> Estimados,
>>>>> 
>>>>> Envío la propuesta formal para la modificación de la política de
>>>>> asigancion de prefijos IPv6:
>>>>> 
>>>>> Propuesta:
>>>>> 
>>>>> Se propone eliminar el punto 5.1.1.d:
>>>>> 
>>>>> 5.1 Adjudicación inicial
>>>>> 5.1.1 Criterio de adjudicación inicial
>>>>> d) Anunciar en el sistema de rutas inter-dominio de Internet un
>>>>> único
>>>>> bloque, que agregue toda la asignación de direcciones IPv6
>>>>> recibida, en un
>>>>> plazo no mayor de 12 meses.
>>>>> 
>>>>> Y promover la remoción de los equivalentes a nivel de todo los RIR.
>>>>> 
>>>>> 
>>>>> 
>>>>> Motivación:
>>>>> 
>>>>> (Adjunto la redacción en ingés que envié al foro de nanog)
>>>>> 
>>>>> The problem raises when a RIR assign a /28 prefix (for example) to
>>>>> an ISP
>>>>> which has 3 internet links with 3 different carriers (tier 1
>>>>> carriers, for
>>>>> example) using BGP publications.
>>>>> 
>>>>> Acording to ARIN (and most other RIRs) policy, the ISP must
>>>>> advertise
>>>>> through all the 3 links the /28 without the possibility of
>>>>> dissagregation.
>>>>> The problem with this policy is that by doing this, the ISP loses
>>>>> control
>>>>> of the traffic, not being able to distribute the traffic over the 3
>>>>> different links.
>>>>> 
>>>>> A /28 prefix may have a lot of incoming traffic associated to it,
>>>>> so I
>>>>> believe the dissagregation (subnets) of the prefix should be
>>>>> allowed by
>>>>> the policy.
>>>>> 
>>>>> Please read http://nro.org/documents/nro42.html for information
>>>>> about
>>>>> possible multi-homing solutions being analysed.
>>>>> 
>>>>> 
>>>>> Saludos,
>>>>> Nicolas Antoniello
>>>>> _______________________________________________
>>>>> Politicas mailing list
>>>>> Politicas at lacnic.net
>>>>> https://mail.lacnic.net/mailman/listinfo/politicas
>>>> 
>>>> 
>>>> _______________________________________________
>>>> Politicas mailing list
>>>> Politicas at lacnic.net
>>>> https://mail.lacnic.net/mailman/listinfo/politicas
>>> 
>>> _______________________________________________
>>> Politicas mailing list
>>> Politicas at lacnic.net
>>> https://mail.lacnic.net/mailman/listinfo/politicas
>> 
>> 
>> 
>> 
>> **********************************************
>> The IPv6 Portal: http://www.ipv6tf.org
>> 
>> Bye 6Bone. Hi, IPv6 !
>> http://www.ipv6day.org
>> 
>> This electronic message contains information which may be
>> privileged or confidential. The information is intended to be for
>> the use of the individual(s) named above. If you are not the
>> intended recipient be aware that any disclosure, copying,
>> distribution or use of the contents of this information, including
>> attached files, is prohibited.
>> 
>> 
>> 
>> _______________________________________________
>> Politicas mailing list
>> Politicas at lacnic.net
>> https://mail.lacnic.net/mailman/listinfo/politicas
> 

**********************************************
The IPv6 Portal: http://www.ipv6tf.org

Bye 6Bone. Hi, IPv6 !
http://www.ipv6day.org

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.