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

[JORDI PALET MARTINEZ]

Hola Nicolas,

Te contesto abajo, entre lineas.

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: Mon, 19 Mar 2007 09:44:53 -0300 (UYT)
> Para: <politicas at lacnic.net>
> Asunto: Re: [LACNIC/Politicas] Politica de publicaciones de bloques IPv6
> (propuesta para modificacion de politica)
> 
> 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.

Si bueno, aunque sea "eliminar" me referia a como quedaria el texto de la
politica actual con esa eliminacion.

> 
> 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).

Entiendo que requiere basicamente la cooperacion de los upstreams. Si los
upstreams, a los que pagas, no quieren cooperar, entonces, cambia a otros.
Hay que ser practico. Si un ISP cambia de upstream por esto, la proxima vez
el upstream se lo pensara mejor. Si los ISPs ceden, al final desagregan y en
lugar de pagar el coste ellos que son los directamente beneficiados, pagamos
todos. Creo que es un acto de coherencia.

> 
> 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... las politicas deben servir como

No me referia a las politicas, sino a la definicion de estandars. Ni
siquiera hace falta acudir a las reuniones, si los operadores opinaran en
las listas del IETF, las cosas serian bastante diferentes.

Que conste que no es una queja hacia ti en concreto, ni mucho menos. Es una
afirmacion generica, que cada vez tengo mas clara que desafortunadamente es
una realidad, y cada vez los operadores (de nuevo en general) se quejan mas,
pero no contribuyen a buscar que soluciones les son mas eficaces y porque
otras no les son validas, etc.

> 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).

Bueno, el RIR no es el autor, aunque si que deberia de dar ejemplo.

Yo creo que las politicas se hacen para ser cumplidas y debe ser asi, pero
tambien entiendo que a veces, la dificultad de verificar su cumplimiento, si
quienes la ofenden no son muchos (como es el caso, al menos de momento),
puede ser mayor que el ser estricto en exigir ese cumplimiento.

Esto es especialmente relevante si los que la incumplen corren el riesgo de
ser filtrados. Pasa a ser mas su problema que el de la comunidad, y hace
innecesario, en cierto modo, una vigilancia estricta por parte de la
comunidad.

> 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 !
> 
> 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.

En IETF no es precisamente asi. Sin embargo, dado que la mayoria de los que
participan son los fabricantes, es mas facil que se decida el camino que a
ellos les interesa (en este caso equipos mucho mas grandes, complejos y
caros), mientras que la participacion de los operadores promoveria
mecanismos de acuerdo ("peering"), que haria innecesario el otro camino. En
definitiva, la participacion en la estandarizacion por parte de los
"verdaderos" usuarios, haria que su masa critica pesara MUCHO mas que la de
los fabricantes (compara numero de fabricantes con numero de ISPs en el
mundo y como esto podria cambiar drasticamente).

> 
> 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.  :)

Si hasta cierto punto, pero una mayor participacion hace que este menos
"dirigido" y por tanto menos desviado hacia intereses de unos pocos. Vamos,
lo dicho en el parrafo anterior.

> 
> 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"...
> 
> 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).
> 
> 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.

Quizas seria posible ver ejemplos concretos, com he comentado antes, de
vuestro caso y otros ISPs en la region que necesiten desagregar por TE, para
ver si se puede conseguir la misma funcionalidad con comunidades. Si
realmente tecnicamente no es viable, desde luego, sere el primero en
rendirme a la evidencia :-)

> 
> Saludos,
> Nicolas.
> _______________________________________________
> 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.