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

Sun Mar 18 14:50:53 BRT 2007

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