[LAC-TF] FAQ: Grupo2 - Pregunta "a"

[Alvaro Vives Martinez]

Hola a todos,

La respuesta de Nicolas me parece correcta para la FAQ ya que permite situar
a la persona que se haga esa pregunta.

En otro orden de cosas, repondiendo a Jorge, yo diría que tal vez haya que
jugar con la semántica aquí. Yo diría que SI es posible ESTIMAR el coste,
pero que NO es posible CALCULARLO con seguridad. En general siempre se puede
estimar, la cosa es que luego se acierte :-)

Por eso la respuesta debe ir en la línea informativa de Nicolas, diciendo
que se puede estimar de manera aproximada en cada caso concreto y basándose
en el conocimiento de diversos factores (apuntados por Jorge).

La cuestión es identificar ahora mismo cuáles son esos factores que deberán
tenerse en cuenta. Eso lo veo de mucha utilidad para el lector de la FAQ que
se haga esa pregunta.

Un saludo,
Alvaro

> -----Mensaje original-----
> De: lactf-bounces at lacnic.net [mailto:lactf-bounces at lacnic.net] En
> nombre de Jorge Villa
> Enviado el: lunes, 09 de marzo de 2009 21:19
> Para: lactf at lac.ipv6tf.org
> Asunto: Re: [LAC-TF] FAQ: Grupo2 - Pregunta "a"
> 
> Nicolas, como estas?
> 
> Pues bueno, la pregunta esta formulada de la manera mas generica
> posible, y
> pienso que NO es posible estimar "de forma general" la cantidad de
> dinero
> requerida para actualizar aplicaciones, porque los procesos son
> diferentes
> por completo (segun la complejidad de cada aplicacion) y las
> condiciones en
> las que se hace el proceso para cada aplicacion tambien es diferente, y
> todo
> ello influye. En mi respuesta anterior me habia referido a 5 topicos,
> que
> por lo general de una manera u otra influyen en el proceso, y ya eso te
> genera una buena aleatoriedad en los costos asociados. Por tanto la
> estimacion tendra que hacerla cada quien para su situacion particular.
> 
> En este caso, no es como estimar el costo de una camara fotografica,
> digamos
> de 8 megapixels de una marca conocida (Sony, Canon, Fuji, Panasonic,
> Kodak,
> etc). Es cierto que los precios pueden variar, pero una camara de una
> marca
> conocida, de las normalitas (para uso domestico) de esa resolucion
> puede
> andar entre los 150 y 400 dolares, segun donde se compre y segun la
> marca y
> modelo. A lo mejor en Estados Unidos la consigues en 150 dolares
> minimo, y
> en otros paises la misma camara sale en el doble, pero mas o menos
> puedes
> dar una idea a grosso modo de cuanto se requiere para tener una camara
> asi.
> 
> En el caso de lograr que aplicaciones actualmente IPv4 funcionen
> correctamente en IPv6, por lo menos yo, no me atreveria a dar una cifra
> y
> que fuera algo real. No se si Fernando, Alvaro o alguno de los que han
> estado participando en el FAQ, o de los que no lo han hecho pero si lo
> van
> siguiendo, pueden dar otra luz al respecto.
> 
> Por lo demas, me siento satisfecho por la respuesta que ha ido
> estructurando
> Guillermo, porque aporta elementos a quien esta buscando "la respuesta
> magica" a esta pregunta. O sea, uno puede decirle a cualquiera: No te
> puedo
> decir cuanto te cuesta llevar tu aplicacion a IPv6 (haria falta una
> bola de
> cristal); pero si puedes sacar tus propias cuentas teniendo en cuenta
> estos
> factores, y ademas, te sugiero que la valoracion la pueda hacer un
> equipo
> multidisciplinario, pues aunque se hable de aplicaciones no solo los
> desarrolladores de software estan involucrados"; asi que aqui copio la
> respuesta de Guillermo.
> 
> "No es posible estimar la inversion desde un punto de vista generico,
> ya que dependera de varios factores, tales como
> 
> - arquitectura de la aplicacion
> - tecnologias empleadas
> - calidad del codigo fuente
> - capacitación del personal
> - sistemas operativos
> - arquitectura de red
> 
> Sin embargo, en cada caso particular se podra hacer una estimacion de
> la inversion necesaria, de acuerdo a los factores que correspondan.
> Como recomendacion general, es conveniente pensar en que intervenga un
> equipo multidisciplinario ya que no esta involucrado solo un
> conocimiento de programacion, sino tambien cuestiones referentes a la
> tecnología IP, sistemas operativos, etc."
> 
> 
> Saludos,
> Jorge
> ----- Original Message -----
> From: "Nicolas Antoniello" <nantoniello at gmail.com>
> To: <lactf at lac.ipv6tf.org>
> Sent: Monday, March 09, 2009 3:04 PM
> Subject: Re: [LAC-TF] FAQ: Grupo2 - Pregunta "a"
> 
> 
> > Hola Jorge,
> >
> > Justamente yo decia que para mi SI se puede estimar, siempre que se
> > tengan en cuenta los factores correspondientes a cada caso en
> > particular.
> > Ahora me pregunto si la pregunta (aunque suene redundante) ¿apunta a
> > estimarlos en un caso genérico o en cada caso?
> >
> > Saludos,
> > Nicolas.
> >
> >
> > 2009/3/6 Jorge Villa <villa at reduniv.edu.cu>:
> >> Hola a tod at s, como estan?
> >>
> >> Pues como que se quedo en el aire la respuesta de la nueva pregunta
> del
> >> FAQ,
> >> luego de la ultima respuesta de Fernando haciendo referencia a la
> >> RFC5461.
> >>
> >> La pregunta a responder es la siguiente:
> >>
> >> ¿Es posible estimar la inversión de dinero requerida para actualizar
> >> aplicaciones, de manera que funcionen correctamente sobre IPv6?
> >>
> >> Pienso que se han aportado muchos elementos acerca de que seria
> necesario
> >> modificar o de aspectos tecnicos de implementacion, pero seguimos
> sin
> >> responder exactamente la pregunta.
> >>
> >> Yo creo que NO es posible estimar la inversion de dinero que se
> requiere
> >> para actualizar aplicaciones IPv4, de manera que funcionen
> correctamente
> >> sobre IPv6, producto que ello dependera de varios factores. Entre
> ellos,
> >> creo fundamentales los siguientes:
> >>
> >> - arquitectura de la aplicacion
> >> - tecnologias empleadas
> >> - calidad del codigo fuente
> >> - capacitación del personal
> >> - sistemas operativos
> >> - arquitectura de red
> >>
> >> La arquitectura de la aplicacion se relaciona con si la aplicacion
> es
> >> monolitica, o es una aplicacion cliente-servidor (basadas o no en
> web), y
> >> por supuesto de la modularidad con que haya sido diseñada la
> aplicacion.
> >> En
> >> algunos casos puede necesitarse rehacer un modulo, pero en otros
> casos
> >> puede
> >> necesitar rehacerse un porciento significativo del producto. Si la
> >> aplicacion tiene clientes Web, entonces sera necesario rehacer solo
> el
> >> servidor, pero si tiene un cliente personalizado, con seguridad
> habra que
> >> trabajar tanto en el cliente como en el servidor.
> >>
> >> Tambien existen multiples tecnologias con las que puede construirse
> una
> >> aplicacion. Algunas son mas simples y otras mas complejas. En muchos
> >> casos
> >> se emplean bibliotecas estandares y en otras bibliotecas diseñadas a
> la
> >> medida. Puede suceder que tambien alguna de las tecnologias con que
> se ha
> >> construido una aplicacion se haya descontinuado por sus fabricantes,
> y
> >> por
> >> tanto haya que rehacer el producto con base en una nueva plataforma.
> >>
> >> Los codigos fuentes son otro dolor de cabeza para muchas
> aplicaciones, ya
> >> que en algunos casos estos no estan disponibles, otras veces estan
> >> disponibles pero no estan hechos con calidad o no estan comentados
> >> adecuadamente, y eso complica la legibilidad del codigo, sobre todo
> >> cuando
> >> quien tiene que actualizar la aplicacion no fue su diseñador
> original.
> >>
> >> El personal que participa en el proceso tiene que estar bien
> capacitado.
> >> Hay
> >> programadores que no dominan ni siquiera aceptablemente la
> tecnologia IP,
> >> y
> >> logran hacer aplicaciones que funcionen en red adecuadamente
> confiando en
> >> las librerias de comunicacion de los paquetes de desarrollo de
> >> aplicaciones.
> >> Para entender correctamente la RFC5461 y algunos de los otros draft
> al
> >> respecto, hay que saber de tecnologia IP. Por lo general, en este
> proceso
> >> de
> >> actualizacion debe intervenir un equipo multidisciplinario.
> >>
> >> Los sistemas operativos tambien influyen, segun la calidad de la
> >> implementacion del stack IPv6 en los mismos. Tambien puede existir
> un
> >> costo
> >> asociado a sistemas operativos, ya que si la aplicacion actual se
> ejecuta
> >> en
> >> Windows 98 o 2000, en W98 no hay soporte IPv6 y en W2K hay soporte
> >> limitado,
> >> por tanto habra que crear al menos a nivel experimental, una
> >> infraestructura
> >> basada en XP o Vista.
> >>
> >> La arquitecturas de red puede complicar en mayor o menor medida el
> >> proceso
> >> de desarrollo de aplicaciones. Es mucho mas facil crear un entorno
> de
> >> desarrollo y/o actualizacion a nivel local (para aplicacion para
> Internet
> >> desde PCs) que cuando hablamos de aplicaciones para dispositivos
> moviles,
> >> donde hay otros aspectos a tener en cuenta.
> >>
> >> Como quiera que tras cada aplicacion hay un cerebro diferente, las
> formas
> >> de
> >> pensar y de llegar a las soluciones difieren y por esto es muy
> dificil
> >> cuantificar el proceso (a grosso modo). Tambien las condiciones
> tecnicas
> >> en
> >> que se desarrolle el proceso influyen, y por supuesto que la
> inversion en
> >> capacitacion es fundamental.
> >>
> >> Bueno, hasta aqui mi respuesta a la pregunta A del grupo 2 del FAQ.
> Que
> >> siga
> >> la ronda.
> >>
> >> Saludos,
> >> Jorge
> >> ----- Original Message -----
> >> From: "Fernando Gont" <fernando at gont.com.ar>
> >> To: <lactf at lac.ipv6tf.org>
> >> Sent: Monday, March 02, 2009 1:34 PM
> >> Subject: Re: [LAC-TF] FAQ: Grupo2 - Pregunta "a"
> >>
> >>
> >>> Hola, Nicolás,
> >>>
> >>> Comentarios entre lineas....
> >>>
> >>>
> >>>> Le había echado un vistazo hace un tiempo a la RFC que tu
> propusiste.
> >>>> La consulta que te hago es sobre que es lo que te parece que
> >>>> tendríamos que agregar o tener en cuenta, en particular para las
> >>>> aplicaciones.
> >>>> ¿Te referís en estos casos a entornos mixtos IPv4-IPv6, donde por
> >>>> ejemplo, una aplicación debe "lidiar" con los errores derivados de
> >>>> time-outs,
> >>>
> >>> En aquellos casos en que una se publican RRs (resource records)
> AAAA
> >>> apra un determinado nombre de dominio, y la conectividad IPv6 es
> >>> limitada, se corre el peligro de caer en el escenario de "grandes
> >>> esperas antes de poder establecer una conexion" que se describe en
> el
> >>> RFC mencionado. Para el caso de aplicaciones interactivas, esto es
> >>> directamente intolerable (ver referencias en el RFC.. aunque
> tambien
> >>> puedo aportar otras).
> >>>
> >>>
> >>>
> >>>> que no sean manejados directamente por los módulos que
> >>>> manejan las conexiones correspondientes o por ejemplo para
> >>>> aplicaciones de tiempo real o similares?
> >>>
> >>> Esta cuestion es muy dificil de manejar. En primer lugar, porque
> >>> tradicionalmente NO se maneja a nivel TCP, entonces termina siendo
> >>> responsabilidad de la aplicación. EN segundo lugar, porque la
> mayoria de
> >>> las aplicaciones no imponen timeouts apra el establecimiento de
> >>> conexión.
> >>>
> >>> Ajeno al workaround explicado en RFC 5461 (que puede NO funcionar,
> en
> >>> caso que no se generen mensajes ICMP), hay algunas otras
> alternativas,
> >>> como las descriptas en este I-D:
> >>> http://tools.ietf.org/id/draft-gont-tcpm-connection-delays-00.txt
> >>> Si bien recuerdo, la gente de Mac hace algo de esto.
> >>>
> >>> En cualquiera de los casos, todavia no existe una solucion completa
> a
> >>> esta cuestion, y conozco de proveedores de Internet que han
> encontrado
> >>> grandes problemas debido a esta cuestión. Por ej., la gente de NTT
> Japón
> >>> incluso ha hecho presentaciones sobre esta cuestión en algunas
> >>> conferencias (si alguien las desea, puedo buscar las diapositivas
> >>> correspondientes).
> >>>
> >>>
> >>>
> >>>> Creo que tu aporte y tus conocimientos al respecto aportarán mucho
> en
> >>>> esta fase de las FAQ.
> >>>
> >>> En "alto nivel", la cuestion es que publicar registros AAAA apra
> nombres
> >>> de dominio que tambien son accesibles mediante IPv4 puede llevar a
> >>> grandes demoras en el establecimiento de conexion, que apra
> aplicaciones
> >>> interactivas resultaria directamente inaceptable.
> >>>
> >>> En lo que se refiere al workaround propuesto/descripto en RFC 5461,
> apra
> >>> que funcione se necesitan dos cosas:
> >>>
> >>> * Que las implementaciones de TCP funcionen como lo describe el
> >>> documento (Windows *no* lo ahce asi, por ejemplo... aunque LInux y
> e.g.
> >>> NetBSD *si* lo hacen)
> >>>
> >>> * Que en aquellos puntos de la red donde se limita la conectividad
> IPv6,
> >>> se generen errores ICMPv6 cuando se tenga queo que rutear algun
> paquete
> >>> IPv6, pero no se pueda hacerlo por falta de conectividad, etc.
> >>>
> >>>
> >>> En lo que hace a las "conexiones paralelas" descriptas en
> >>> http://tools.ietf.org/id/draft-gont-tcpm-connection-delays-00.txt,
> esto
> >>> deberia implementarse a nivel aplicacion, lo que agergaria
> complejidad a
> >>> las aplicaciones (y ajeno a eso, la mayoria de las aplicaciones NO
> hacen
> >>> esto).
> >>>
> >>> Cualquier cosa en la que pueda ayudar, estoy a tus ordenes.
> >>>
> >>> Un abrazo,
> >>> --
> >>> Fernando Gont
> >>> e-mail: fernando at gont.com.ar || fgont at acm.org
> >>> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> LACTF mailing list
> >>> LACTF at lacnic.net
> >>> https://mail.lacnic.net/mailman/listinfo/lactf
> >>>
> >>> --
> >>> This message has been scanned for viruses and
> >>> dangerous content by MailScanner, and is
> >>> believed to be clean.
> >>>
> >>
> >>
> >> --
> >> This message has been scanned for viruses and
> >> dangerous content by MailScanner, and is
> >> believed to be clean.
> >>
> >> _______________________________________________
> >> LACTF mailing list
> >> LACTF at lacnic.net
> >> https://mail.lacnic.net/mailman/listinfo/lactf
> >>
> > _______________________________________________
> > LACTF mailing list
> > LACTF at lacnic.net
> > https://mail.lacnic.net/mailman/listinfo/lactf
> >
> > --
> > This message has been scanned for viruses and
> > dangerous content by MailScanner, and is
> > believed to be clean.
> >
> 
> 
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
> 
> _______________________________________________
> LACTF mailing list
> LACTF at lacnic.net
> https://mail.lacnic.net/mailman/listinfo/lactf
> 
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 8.0.237 / Virus Database: 270.11.6/1980 - Release Date:
> 03/02/09 23:02:00



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