[LACNIC/Politicas] Politica de publicaciones de bloques IPv6 (propuesta para modificacion de politica)

[Nicolás Ruiz]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hola Nicolás:

Nicolás Antoniello wrote:
> Estimados,
> 
> Recorto el thred porque se esta volviendo ilegible...  :)
> 
> Bueno, aclaro algunas cosas segun mi punto de vita y comento otras:
> 
> 1 - El "texto" que propongo, en realidad no es ningun texto, sino mas
> bien la eliminacion del inciso d.
> 
> 2 - Jordi, el tema que mencionas y que sugiere Iljitsch es una
> alternativa, si, pero requiere un monton de ajustes para que sea
> realmente aplicable y esto esta mencionado y analizado en el texto que
> sugerí leer al final de la propuesta (se analiza el uso de comunidades
> para el caso de multi-home).
> 
> 3 - El hecho de participar o no en las políticas y luego "quejarse" o
> no, creo que no tiene nada que ver en esto...

Me da la impresión que Jordi no se refiere a la participación en la
creación de políticas (menciona la participación en IETF), sinó en la
creación de soluciones técnicas que luego no son aceptadas por los
operadores, perpetuando así el problema que se busca resolver en primer
lugar.

> las politicas deben servir
> como marco regulatorio y mecanismo para poder imponer reglamentaciones
> cuando se presentan los problemas, pero nunca deben ir en contra de algo
> que por naturaleza, hoy en dia (y remarco lo de "HOY", porque claramente
> la idea es llegar a una solucion) no puede cumplirse.
> Que sentido tiene una politica que no puede cumplirse?, es mas, de
> hecho, el mantenimento de una politica asi, va en contra de la misma
> politica pues le quita seriedad al admitir que todos o caci todos la
> violaran en la practica (de hecho, como tu mencionas, el propio autor la
> viola en su propio sitio... y creo que esto es mucho mas nocivo que
> admitir que por el momento no hay soluciones practicas (si academicas
> pero no directamente aplicables en operacion).
> Si como se decia anteriormente: "este no es un foro tecnico" sino que es
> politico, bueno, creo que el argumento es mas que valido: no promovamos
> una politica que nisiquiera nosotros cumplimos !

Ese no es un argumento válido. La mayoria de las políticas sugeridas y
aprobadas en este y otros foros no se cumplen antes de ser adoptadas. La
idea es precisamente cumplirlas.

> Volviendo sobre el tema de la participacion en el momento que se "crea
> la tecnologia" y no luego... bueno, sobre eso tengo un sinnumero de
> observaciones, algunas en pro y otras en contra de ese comentario...
> pero por lo general, los grupos destinados a "crear e imponer
> tecnologias" son bastante reducidos, con intereses mucho mas grandes que
> cualquiera de nosotros y donde se juegan tanto argumentos tecnicos como
> politico-economicos.
> 
> Pero por sobre todo y mas en esto de Networking, la historia ha
> demostrado que es bastante impredecible (en tiempo de diseño) el
> comportamiento, como para poder asegurar (al momento de sacar el
> estandar) la aplicabilidad 100% de lo que se diseño. Por ello, creo que
> siempre es positivo el obsevar y cuestionar las tecnologias, las
> politicas y los criterios de diseño en el caso de Redes sin importar si
> se participo o no del diseño... en esto de IPv6, creo que cuando muchas
> de estas cosas se pensaron por primera vez, nosotros no sabiamos ni lo
> que era un enlace BGP.  :)
> 
> 4 - Para resumir un poco:
> Analizando este asunto veo lo siguiente: se detecta y reconoce el
> problema de la agregación y el posible desbordamiento de las tablas de
> ruteo (si se desagrega mucho) o la imposibilidad practica de
> multi-homing (si se agrega mucho), lo cual es claramente un problema
> tecnico ... luego, creamos una politica que pretende imponer (pues lo
> tiene como requerimiento para acceder a la adjudicacion de refijos) la
> agregación al 100% del bloque asignado a la hora de publicarlo al mundo
> ... luego, como esto es impracticable (al dia de hoy) tecnicamente,
> pretendemos aplicar y buscar soluciones tecnicas para "cumplir con la
> politica"...

al contrario, se busca aplicar soluciones técnicas al problema que
actualmente se resuelve desagregando, lo que crea un problema distinto.
Lo que se busca es resolver el problema de ingenieria de tráfico sin
desagregar.

La política es simplemente una formalización de (uno de) los objetivos
que se buscan.

> Ahora bien, no nos olvidemos de que estas politicas deben siempre tener
> base tecnica y practicable que las sustente, y en este caso, a la fecha,
> no veo que nadie lo haga (digamos que no solo eso... poque si no, no
> seria argumentable modificar una politica por una mala practica... sino
> que no se trata de una "mala practica", se trata de una imposibilidad
> real que NO se tuvo en cuenta a la hora de escribir esa frase en los
> requerimientos).
> Creo que lo que esta mal es defender esa frase solamente pensando en que
> ella soluciona el problema. Por el contrario, impone reglas que ni el
> que la escribio cumple (como el caso de APNIC segun menciona Jordi).

Nuevamente, la política no resuelve nada. El problema técnico de
crecimiento de las tablas de enrutamiento se resuelve (indirectamente)
estableciendo mecanimos que permitan ingenieria de tráfico (yo no he
revisado los documentos que envio Jordi, y no recuerdo lo que se
menciona al respecto en el libro de Iljistsch).

El problema (tal como yo lo veo) es la resistencia a buscar una solución
al problema de fondo (más flexibilidad en el enrutamiento).

> Busquemos la solucion tecnica... hasta entonces, sigo pensando que la
> politica debe modificarse y no imponer algo que no se puede cumplir por
> el momento. Creo que politicamente no es correcto decir que de debe
> anunciar el bloque como uno solo... de hecho, si hoy en dia las TODOS
> hicieramos eso y todos pasaramos a IPv6, tendríamos mucho menos rutas
> que las que tenemos en IPv4 ya que actualmente desagregamos bloques. :)
> A lo que voy, es que incluso limitando la cantidad de prefijos en lugar
> del tamaño de los mismo se llega a una solucion mucho mas practica
> (incluso podria ser mejor a priori que la de las comunidades) que no
> aumentaría en nada el tamaño de las tablas de ruteo (aunque como se
> menciona en el mismo documento que les recomende, tiene también sus
> contras esta metodología).
> 
> Finalmente, creo que de todas formas, la publicación como bloque unico
> nunca sera (al menos al mediano plazo) algo practicable.
> 
> Saludos,
> Nicolas.
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Politicas mailing list
> Politicas at lacnic.net
> https://mail.lacnic.net/mailman/listinfo/politicas


- --
A: Because it destroys the flow of conversation.
Q: Why is top posting dumb?
- --
Juan Nicolás Ruiz    | Corporación Parque Tecnológico de Mérida
                     | Centro de Cálculo Cientifico ULA
nicolas at ula.ve       | Avenida 4, Edif. Gral Masini, Ofic. B-32
+58-(0)274-252-4192  | Mérida - Edo. Mérida. Venezuela
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFF/o0NmjsZS9ZBxv8RAgiLAJ9Ou4WaX3VonEZ/oTWGzRiikL+r0gCfR8+2
SDxQxIgz6FA5JgK+2gvtzvI=
=veh4
-----END PGP SIGNATURE-----