[LACNIC/Politicas] Nueva propuesta LAC-2019-11 / Nova proposta LAC-2019-11 / New proposal LAC-2019-11

Uesley Correa uesleycorrea at gmail.com
Tue Oct 29 18:54:07 -03 2019


Hola Nico,

Mil gracias por tus comentarios. Entiendo tu punto de vista, de verdad
mejor es que el usuário elija. El problema que enfrento (con alguna
frecuencia en mis clientes de consultoría / asesoría) es: Clientes que no
solicitaron ASN solamente por la cuestión de costos (de verdad no tienen
conocimiento de cuales benefícios tendían por ser un ASN) y ahora quieren
contratar otro tránsito IP y tienen dificultades (alguien les comenta que
ahora necesitan de ASN, y que tienen que tener un BGP, y ahora hacer toda
una nueva política de IRR, y otros temas de seguridad, etc). Y eso les
cuesta un trabajo inmensurable. Quizás una alternativa para "mantener las
posibilidades" sería hacer algo en carácter educativo, explicando al
solicitante de recursos de numeración que en un futuro él podrá necesitar
de un ASN y tener que rehacer todo un trabajo que de verdad podría hacer
una sola vez al início. Coincido con el punto que es mejor con que el
usuario decida, desde que el usuário mismo no lleve en cuenta solamente el
bolsillo en la decisión.

Saludos!

Uesley Corrêa - Analista de Telecomunicações
CEO Telecom Consultoria, Entrenamiento y Servicios
CEO Telecom Fiber Solutions


Em ter, 29 de out de 2019 às 18:45, Nicolas Antoniello <
nantoniello at gmail.com> escreveu:

> Hola Uesley,
>
> El tema del “costo” por la delegación de un ASN entiendo que responde más o
> menos a la misma razón que el pago por la membresía acorde al rango de
> número de direcciones IP que tenga delegadas... son recursos y como todo
> recurso hay costos de gestión por parte de los RIR que son la forma que
> tienen los RIR de financiar su funcionamiento.
>
> Cuál es finalmente ese costo?, eso ya es otro tema y efectivamente lo
> definen los Miembros en la Asamblea de Miembros, acorde a los estatutos de
> Lacnic.
>
> Yo creo que de todas formas, como tu dices cuando “te mudaste a PY”, no
> esta mal que un usuario final pueda elegir si quiere o no gestionar un ASN,
> independientemente de que tan simple o no es la operación. Y también creo
> que es más saludable poder solicitar bloques IP a Lacnic sin necesidad de,
> en el mismo momento, disponer de un ASN. En cambio, con esta propuesta
> entiendo que luego, cuando lo necesite realmente, lo solicito y listo.
>
> Saludos,
> Nico
>
>
>
>
> El El mar, 29 de oct. de 2019 a la(s) 18:29, Uesley Correa <
> uesleycorrea at gmail.com> escribió:
>
> > Hol@,
> >
> > Yo conozco los dos lados y tengo puntos en conforme con los dos lados. De
> > verdad cuando me mudé de Brasil hacia Paraguay y me enteré más del
> > escenario Latinoamericano me parecía demasiado raro entender "qué hace un
> > ISP o usuario final con una asignación sin un ASN". Después "entendí" el
> > punto en cuestión del ASN y de los aparentes costos involucrados en
> > gestionar un router BGP.
> >
> > Lo que añado es: hoy, hasta un OpenWRT / Mikrotik muy barato consigue
> > gestionar BGP, lo que pone en tierra el argumento de la necesidad de un
> > router "más grande". Coincido con Jordi, solamente una ruta por defecto o
> > default static alcanzaría en un escenario single homed y el usuario final
> > tendría a la mano la flexibilidad de cambiar de Proveedor al momento que
> > desee sin muchos problemas. Un otro punto que creo ser más comercial,
> pero
> > es importante acordarse de que llegaremos muy pronto en un escenario en
> que
> > cualquier PYME tenga su propio ASN y rangos (aunque no sea IPV4). Y el
> > usuario final (PYME) debe tener la flexibilidad de cambiar cuando quiera
> > (de verdad teniendo alguna clase de soporte por parte de quien vende el
> > servicio y haciendo un cobro adicional por el mantenimiento del BGP).
> > Entonces, razones hay para que un usuario final tenga su ASN. Lo que de
> > verdad no comprendo es por qué motivo maneja LACNIC un cobro por el ASN
> > (sea en ISP o en end user). Eso dificulta mucho en actualizaciones
> futuras
> > (tengo muchos clientes ISP que no cambian de operadora por qué se
> > consideran atados a la misma por tener sus rangos anunciados por ASN
> > "ajeno").
> >
> > Saludos,
> >
> > Uesley Corrêa - Analista de Telecomunicações
> > CEO Telecom Consultoria, Entrenamiento y Servicios
> > CEO Telecom Fiber Solutions
> >
> >
> > Em ter, 29 de out de 2019 às 17:53, Arturo Servin <
> arturo.servin at gmail.com
> > >
> > escreveu:
> >
> > > De acuerdo con la politica.
> > >
> > > Hay casos de uso validos donde se necesita espacio unico global y no es
> > > necesario un ASN o anunciarlo globalmente.
> > >
> > > Saludos,
> > > as
> > >
> > >
> > > On Tue, Oct 29, 2019 at 9:32 PM Nicolas Antoniello <
> > nantoniello at gmail.com>
> > > wrote:
> > >
> > > > Estimados todos,
> > > >
> > > > Me gustaría conocer la opinión del resto de los integrantes de esta
> > lista
> > > > sobre esta política !
> > > > Que opinan quienes operan como usuarios finales y no utilizan BGP?
> Como
> > > > manejan esto?
> > > >
> > > > Abrazo,
> > > > Nicolas
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > El mar., 29 de oct. de 2019 a la(s) 15:58, Nicolas Antoniello (
> > > > nantoniello at gmail.com) escribió:
> > > >
> > > > > Fernando,
> > > > >
> > > > > Supongo que NIC.br así lo hace pues por las políticas actuales hay
> > que
> > > > > tener ASN para solicitar recursos IP.
> > > > > Lo que me parece es que no tiene mucho sentido que sea obligatorio
> > > tener
> > > > > ASN si no se va a utilizar... ni tampoco que no se pueda disponer
> de
> > > > > recursos IP si se solicitan y que los mismos sean publicados por el
> > ISP
> > > > que
> > > > > brinda la conectividad.
> > > > > Si en un futuro interconectan con más de un ISP, solicitan el ASN y
> > > > listo,
> > > > > sin necesidad de renumerar.
> > > > >
> > > > > No me queda claro cuál sería tu argumento para "obligar" a tener
> ASN
> > > si o
> > > > > si?
> > > > >
> > > > > Sobre lo de la publicación, creo que la propuesta de Edmundo de
> > sacarlo
> > > > es
> > > > > porque está referido al deber de publicar con su propio ASN que es
> > > > > justamente lo que se quiere modificar. La necesidad de justificar
> lo
> > > > > solicitado, etc entiendo que está cubierta por el resto del manual,
> > > como
> > > > > para cualquier solicitud (esta parte entiendo que es solo para lo
> del
> > > > > tamaño mínimo de asignación, que ya tenia lo del ASN).
> > > > >
> > > > > Abrazo,
> > > > > Nico
> > > > >
> > > > >
> > > > >
> > > > > El mar., 29 de oct. de 2019 a la(s) 15:05, Fernando Frediani (
> > > > > fhfrediani at gmail.com) escribió:
> > > > >
> > > > >> Hola Nico
> > > > >>
> > > > >> Este es mi punto: tiene más sentido no cobrar un valor separado
> para
> > > ASN
> > > > >> y que el valor sea único para ASN+IPv4+IPv6 como lo es con NIC.br.
> > Si
> > > > >> los ASN fueran solo de 16 bits, estaría bien, pero con los ASN de
> 32
> > > > >> bits no es un problema recibir uno y no usarlo de inmediato.
> > > > >>
> > > > >> Aunque existe un consenso de que no hay necesidad de una ASN
> > > > >> inicialmente, creo que la parte del texto que se propone eliminar
> > "El
> > > > >> solicitante debe justificar que anunciará el espacio asignado"
> > > > >> necesitaría ser revisado ya que es una base fundamental para
> > solicitar
> > > > >> cualquier recurso de numeración.
> > > > >>
> > > > >> Saludos
> > > > >> Fernando
> > > > >>
> > > > >> On 29/10/2019 13:56, Nicolas Antoniello wrote:
> > > > >> > Hola Fernando y todos,
> > > > >> >
> > > > >> > Hay varios RIR que no tienen esa exigencia que tenemos en LACNIC
> > de
> > > > >> tener
> > > > >> > que solicitar ASN para solicitar bloques.
> > > > >> > Creo que puede ser una solución para quienes tienen un único
> > > proveedor
> > > > >> y no
> > > > >> > requieren ASN ni quieren administrar un AS, routers de borde con
> > > BGP,
> > > > >> etc.
> > > > >> > De esa forma no sería necesario pagar por la delegación de ASN y
> > > solo
> > > > >> por
> > > > >> > los bloques IP.
> > > > >> > También creo que hay varios “end-user” que utilizan esa
> modalidad
> > > por
> > > > lo
> > > > >> > que el ASN no lo utilizarían.
> > > > >> >
> > > > >> > Más aún, es mejor lo que se propone que la situación actual para
> > > ellos
> > > > >> pues
> > > > >> > lo que actualmente muchos hacen (para no tener que pagar por un
> > ASN
> > > > que
> > > > >> no
> > > > >> > utilizarán) es solicitar bloques a su proveedor; con la contra
> de
> > > que
> > > > >> si en
> > > > >> > algún momento quieren hacer multihoming multiproveedor y
> solicitan
> > > > ASN y
> > > > >> > bloques tienen que renumerar. Ya sabemos el dolor de cabeza que
> es
> > > > >> > renumerar.
> > > > >> >
> > > > >> > En principio estoy a favor de esta propuesta.
> > > > >> >
> > > > >> > Abrazo,
> > > > >> > Nico
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> > El El mar, 29 de oct. de 2019 a la(s) 12:12, Fernando Frediani <
> > > > >> > fhfrediani at gmail.com> escribió:
> > > > >> >
> > > > >> >> Hola.
> > > > >> >> Esta propuesta me parece un poco extraña porque creo que el uso
> > de
> > > > ASN
> > > > >> >> es necesario para la gran mayoría de los casos y también algo
> que
> > > > >> >> debería fomentarse, aunque entiendo que en algunos pocos casos
> > > puede
> > > > no
> > > > >> >> ser necesario. Si hoy no es una necesidad en algunos pocos
> casos,
> > > es
> > > > >> muy
> > > > >> >> probable que lo sea en el futuro cercano.
> > > > >> >>
> > > > >> >> Creo que quizás esta propuesta tenga que ver con el hecho de
> que
> > > > LACNIC
> > > > >> >> cobra un monto separado por asignar un ASN. En mi opinión, esto
> > no
> > > > >> >> debería existir y el ASN se asignará automáticamente a
> cualquier
> > > > >> >> solicitante (si no lo tiene en otro RIR, por ejemplo) y no se
> le
> > > > >> cobrará
> > > > >> >> de más, es decir, el mismo valor para ASN + IPv4 + IPv6. NIC.br
> > lo
> > > > hace
> > > > >> >> así y no creo que traiga cualquier pérdidas financieras si el
> > monto
> > > > >> >> cobrado es único, ni habrá problemas de escasez con los ASN de
> 32
> > > > bits.
> > > > >> >> En los casos en que el Usuario final elige no recibir ASN por
> un
> > > > costo
> > > > >> >> más bajo, termina causando una cierta dependencia del ISP que
> > debe
> > > > >> >> eliminarse una vez que la UF decida tener sus propios recursos
> y
> > > esto
> > > > >> >> también debe incluir ASN..
> > > > >> >>
> > > > >> >> Otro punto muy importante en el que no puedo estar de acuerdo
> es
> > > > >> >> eliminar la parte del texto que dice "El solicitante debe
> > > justificar
> > > > >> que
> > > > >> >> anunciará el espacio asignado".
> > > > >> >>
> > > > >> >> Saludos Cordiales
> > > > >> >> Fernando Frediani
> > > > >> >>
> > > > >> >> On 29/10/2019 10:18, info-politicas at lacnic.net wrote:
> > > > >> >>> [Português abaixo]
> > > > >> >>> [English below]
> > > > >> >>>
> > > > >> >>> Estimados suscriptores de la Lista de Políticas de LACNIC,
> > > > >> >>>
> > > > >> >>> Se recibió una nueva propuesta de Política, se le asignó el id
> > > > >> >> LAC-2019-11.
> > > > >> >>> Título: Eliminación del requerimiento de ASN para Usuarios
> > > Finales.
> > > > >> >>>
> > > > >> >>> Resumen: Esta propuesta busca eliminar la obligatoriedad para
> > los
> > > UF
> > > > >> de
> > > > >> >> contar con un AS para hacer uso de las direcciones que les sean
> > > > >> asignadas.
> > > > >> >>> Para ver el detalle ingrese en:
> > > > >> >>> https://politicas.lacnic.net/politicas/detail/id/LAC-2019-11
> > > > >> >>>
> > > > >> >>> Los comentarios y los puntos de vista aportados por la
> comunidad
> > > son
> > > > >> >> vitales para el correcto desarrollo del proceso de la
> propuestas
> > > > >> >>> - ¿Apoya usted o se opone a esta propuesta?
> > > > >> >>> - ¿Esta propuesta resolvería un problema que usted está
> > > > >> experimentando?-
> > > > >> >> ¿Ve alguna desventaja en esta propuesta?
> > > > >> >>> - ¿Qué cambios podrían hacerse a esta propuesta para que sea
> más
> > > > >> eficaz?
> > > > >> >>>
> > > > >> >>> Por más información contacte a info-politicas at lacnic.net
> > > > >> >>> Saludos cordiales,
> > > > >> >>>
> > > > >> >>>
> > > > >> >>
> > > > >>
> > > >
> > >
> >
> ______________________________________________________________________________________________________
> > > > >> >>> Prezados assinantes da lista de políticas de LACNIC,
> > > > >> >>>
> > > > >> >>> Foi recebida uma nova proposta de Política, foi atribuído o id
> > > > >> >> LAC-2019-11.
> > > > >> >>> Título: Eliminación del requerimiento de ASN para Usuarios
> > > Finales.
> > > > >> >>>
> > > > >> >>> Resumo: Esta propuesta busca eliminar la obligatoriedad para
> los
> > > UF
> > > > de
> > > > >> >> contar con un AS para hacer uso de las direcciones que les sean
> > > > >> asignadas.
> > > > >> >>> Para ver o detalhe acesse:
> > > > >> >>> https://politicas.lacnic.net/politicas/detail/id/LAC-2019-11
> > > > >> >>>
> > > > >> >>>    Os comentários e os pontos de vista aportados pela
> comunidade
> > > são
> > > > >> >> vitais para o bom desenvolvimento do processo das propostas
> > > > >> >>> - ¿Você é a favor ou contra desta proposta?
> > > > >> >>> - ¿Esta proposta iria resolver um problema que você está
> > > > >> >> experimentando?- ¿Vê alguma alguma desvantagem nesta proposta?
> > > > >> >>> - ¿Que mudanças poderiam ser feitas à proposta para que seja
> > mais
> > > > >> eficaz?
> > > > >> >>>
> > > > >> >>>    Por mais informações entre em contato conosco através do
> > > seguinte
> > > > >> >> e-mail: info-politicas at lacnic.net
> > > > >> >>> Atenciosamente,
> > > > >> >>>
> > > > >> >>
> > > > >>
> > > >
> > >
> >
> ______________________________________________________________________________________________________
> > > > >> >>> Dear LACNIC Policy List subscribers,
> > > > >> >>>
> > > > >> >>> A new Policy Proposal has been received and assigned the
> > following
> > > > ID:
> > > > >> >> LAC-2019-11.
> > > > >> >>> Title: Eliminación del requerimiento de ASN para Usuarios
> > Finales.
> > > > >> >>>
> > > > >> >>> Summary: Esta propuesta busca eliminar la obligatoriedad para
> > los
> > > UF
> > > > >> de
> > > > >> >> contar con un AS para hacer uso de las direcciones que les sean
> > > > >> asignadas.
> > > > >> >>> To read the proposal, please go to
> > > > >> >>> https://politicas.lacnic.net/politicas/detail/id/LAC-2019-11
> > > > >> >>>
> > > > >> >>> The community's comments and opinions are essential to the
> > proper
> > > > >> >> functioning of the policy development process.
> > > > >> >>> - Do you support this policy or are you against it?
> > > > >> >>> - Would this proposal solve a problem you are experiencing?-
> Do
> > > you
> > > > >> >> think this proposal has any drawbacks?
> > > > >> >>> - What changes could be made to this proposal to make it more
> > > > >> effective?
> > > > >> >>>
> > > > >> >>> For further information, please contact
> > info-politicas at lacnic.net
> > > > >> >>> Kind regards,
> > > > >> >>>
> > > > >> >>> 
> > > > >> >>> --
> > > > >> >>> LACNIC - Registro de Direcciones de Internet para América
> > Latina y
> > > > >> Caribe
> > > > >> >>> Rambla Rep. de México 6125, CP 11400
> > > > >> >>> Montevideo-Uruguay
> > > > >> >>> Teléfono: +598 2604 22 22
> > > > >> >>> www.lacnic.net
> > > > >> >>> _______________________________________________
> > > > >> >>> 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
> > > > >> _______________________________________________
> > > > >> 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
> > >
> > _______________________________________________
> > 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
>


More information about the Politicas mailing list