[LACNIC/Politicas] propuesta de politica LAC-2016-5 - dudas para nueva version
Ricardo Patara
patara at registro.br
Tue Aug 30 11:34:01 BRT 2016
Hola
On 30/08/2016 11:28, JORDI PALET MARTINEZ wrote:
> Entiendo que si una universidad como la mencionada con Nico tiene varios
> proveedores (por ejemplo la conexión a la red Nacional y/o a CLARA, y uno o
> varios carriers), necesita direccionamiento propio y obviamente NO es un
> usuario final.
>
> Si es cierto que en este caso la política se lo permite y asi se ha hecho
> muchas veces. El caso al que yo me refiero es mas si fuera la red nacional.
>
> Imaginemos que la red nacional es el proveedor principal para todas las
> universidades de un país.
>
> Cada universidad quiere su propio /32, porque a su vez tienen varios
> campuses, etc. Si aplican a la política de usuario final, podrían obtener,
> cada una de ellas su propio /32.
>
> Pero como proveedor nacional para que pueda asignar un /32 a cada
> universidad, necesitaría pedir (un ejemplo, suponiendo un numero grande de
> universidades, centros independientes de I+D, etc = 40), un /26.
que sea así, y no hay impedimentos para que los solicite.
si presenta un plan claro y bien elaborado, lo justificaría.
saludos
> Esto es el mismo ejemplo que explique aplicado a un gobierno de un país, pero
> aplicado a la red e universidades. Se trata de evitar que se haga un pedido
> artificial de 40 veces /32 como usuarios finales, si la entidad “central”
> puede pedir como LIR (no-ISP tradicional) ese /26, que es lo mismo, pero un
> solo pedido para LACNIC, y que permite que las universidades, si es el caso,
> al menos como backup, puedan tener multihoming y anunciar el /32 de cada una
> a sus propios ISPs, o quizás a los IX regionales, etc.
>
> Saludos, Jordi
>
>
>
> -----Mensaje original-----
> De: Politicas <politicas-bounces at lacnic.net> en nombre de Ricardo Patara <patara at registro.br>
> Responder a: Lista para discusion de politicas de la comunidad de LACNIC <politicas at lacnic.net>
> Fecha: martes, 30 de agosto de 2016, 15:23
> Para: <politicas at lacnic.net>
> Asunto: Re: [LACNIC/Politicas] propuesta de politica LAC-2016-5 - dudas para nueva version
>
> Hola Nico,
>
> > Ciertamente lo que comenta Jordi sobre entidades gubernamentales o
> > similares que delegan internamente a otras (separdas desde el punto de
> > vista administrativo) es una realidad.
> > En Uruguay por ejmplo, el servicio de Inforática de la Universidad Estatal
> > asigna subredes a las diferentes Universidades Estatales quienes a su vez
> > tienen cada una su propio grupo de TI que luego administra esas
> > direcciones. No son LIR en lo formal que respecta a Lacnic pero si lo son a
> > la interna. Y el modelo, por diversas razones, no admite que cada
> > Universidad pida las direcciones directo a Lacnic... Entre otros porque la
> > "conectividad" con Internet la brinda el Servicio Central, no hablan
> > necesariamente eBGP, no pueden hablar iBGP porque son dominios
> > administrativos diferentres, bla bla bla... Podemos buscar soluciones
> > alternativas para rodear el hecho, pero hoy es una realidad.
>
> comprendo, pero no me queda claro cual es el problema aquí?
>
> si las universidades estatales utilizan a el servicio de Informática como su
> "proveedor" de acesso hacia la internet, nada más logico que cuente con bloques
> su asignados por dicha organización.
>
> la política actual se les permitiría eso.
>
> saludos
>
> > Tal vez debemos tener en cuenta esta situación y analizar el nivel
> > porcentual de exigencia de argumentación de uso de las direcciones
> > adaptándonos a estos casos que antes no habíamos considerado.
> > Sobre todo teniendo en cuenta que muy seguramente las re-asignaciones de
> > redes IPv6 por parte de los RIR a los miembros no sean ni cerca lo
> > frecuentes que son para los recursos IPv4 (lo cual reduce notablemete la
> > carga administrativa dinámica del RIR en este sentido, por decirlo de
> > alguna manera, pero no afecta el nivel de membresía de quienes tienen
> > delegadas las redes).
> >
> > Saludos,
> > Nico
> >
> >
> >
> > El Monday, August 29, 2016, JORDI PALET MARTINEZ <jordi.palet at consulintel.es>
> > escribió:
> >
> >> Hola Ricardo,
> >>
> >> Contesto debajo entre líneas.
> >>
> >> Saludos,
> >> Jordi
> >>
> >>
> >>
> >> -----Mensaje original-----
> >> De: Politicas <politicas-bounces at lacnic.net <javascript:;>> en nombre de
> >> Ricardo Patara <patara at registro.br <javascript:;>>
> >> Responder a: Lista para discusion de politicas de la comunidad de LACNIC <
> >> politicas at lacnic.net <javascript:;>>
> >> Fecha: jueves, 18 de agosto de 2016, 17:23
> >> Para: <politicas at lacnic.net <javascript:;>>
> >> Asunto: Re: [LACNIC/Politicas] propuesta de politica LAC-2016-5 - dudas
> >> para nueva version
> >>
> >> Hola Jordi, te contesto a continuación.
> >>
> >> >> Como recordatorio, el enlace de la misma es:
> >> >> https://politicas.lacnic.net/politicas/detail/id/LAC-2016-5
> >> >
> >> >> 1) Hay organizaciones que son LIRs, pero no son ISPs (en el contexto
> >> >> tradicional que todo entendemos). Por ejemplo un gobierno, o entidad
> >> >> internacional. Tampoco son usuarios finales porque entregan
> >> recursos IPv4
> >> >> y/o IPv6 a otras entidades.
> >> >
> >> > En el texto de políticas de LACNIC hay ya una defincion de LIR que
> >> creo
> >> > atender ese caso que comentas:
> >> >
> >> > "Registro de Internet Local (LIR) es un IR que a su vez asigna
> >> recursos de
> >> > Internet a usuarios de los servicios de red que éste provee. Los
> >> LIRs son
> >> > generalmente ISPs, cuyos clientes son principalmente usuarios
> >> finales y
> >> > posiblemente otros ISPs."
> >> >
> >> > Quizás seria necesario entonces ajustar solamente el titulo del
> >> punto 2.3.3.1
> >> > para :
> >> >
> >> > "2.3.3.1. Distribución inicial a ISPs o LIRs"
> >>
> >>
> >> | Entiendo lo que dices, pero el caso que intento describir, tiene un
> >> contexto
> >> | mas amplio, porque no solo es el titulo sino los requisitos para
> >> asignar
> >> | recursos, por eso no basta con cambiar el titulo.
> >>
> >> comprendo.
> >> mi intención era decir que si no hay necesidades "distintas" entre
> >> ISPs y LIRs,
> >> los cambios serian solamente ajustar el titulo del 2.3.3.1
> >>
> >> Yo creo que si que hay necesidades distintas. Ya he comentado otras veces
> >> que el caso se ha dado en Europa. Alli se opto por una política con
> >> requisitos mucho mas “abiertos”, lo que, bajo mi punto de vista, se presta
> >> a que un ISP se pueda aprovechar de ello y por eso creo que es mas fácil de
> >> tener una política con dos categorías y requisitos ligeramente diferentes.
> >>
> >> En los casos Europeos ello ha demorado la asignación durante varios años,
> >> a gobiernos. Creo que hemos de ser inteligentes, aprender no solo de
> >> nuestros errores, sino también de los de los demás, y anticiparnos a que
> >> eso ocurra en la región.
> >>
> >> >> Por ejemplo. No es lo mismo el Ministerio de Telecomunicaciones del
> >> pais
> >> >> “x”, si recibe los recursos SOLO para su propio uso (caso a), que el
> >> >> Ministerio de Administración Pública del mismo pais, si recibe los
> >> recursos
> >> >> porque gestiona una red que conecta todos los Ministerio y otros
> >> organismos
> >> >> públicos del país, y les entrega a cada uno de ellos recursos (caso
> >> b).
> >> >>
> >> >> En el caso a, esta claro que dicha entidad califica bajo la
> >> politica de
> >> >> usuario final.
> >> >>
> >> >> En el caso b, esta entidad seria un LIR, pero no es un ISP en el
> >> sentido
> >> >> estricto de la palabra, pues no ofrece servicios a cualquier otra
> >> entidad
> >> >> fisica o jurídica, sino a entidades dentro de “un club” especial,
> >> en el
> >> >> caso del ejemplo, organismos publicos.
> >> >
> >> > el texto de la politica no hace esa distincion del tipo de "cliente"
> >> del
> >> > LIR/ISP.
> >> >
> >> > considera "clientes conectados a su red" y en ese caso especifico un
> >> > ministerio, por ej, seria un cliente de la red del gobierno.
> >>
> >> | Totalmente de acuerdo, pero el punto aquí es que si ponemos
> >> requisitos
> >> | diferentes para un ISP que para otro tipo de LIR, y dejamos un único
> >> “tipo”,
> >> | el texto de los requisitos se vuelve altamente complicado, además
> >> (sigo con
> >> | el costo …)
> >>
> >> okay, pero sigo con el punto de que no son diferentes los requisitos
> >> ni las
> >> necesidades.
> >>
> >> Aquí esta la diferencia:
> >>
> >> Caso del ISP:
> >> El plan de direccionamiento no debe superar los cuatro años. Y debe
> >> considerar el espacio necesario para atender a los clientes y a los
> >> servicios actuales considerando el prefijo mínimo para asignaciones
> >> recomendadas en la política vigente.
> >> Debido a la existencia de múltiples puntos de acceso (POP), el plan de
> >> direccionamiento puede indicar prefijos mínimos para cada POP. Los prefijos
> >> mínimos para cada POP deben estar dentro de las "fronteras" binarias de la
> >> dirección IPv6 (/X, donde X es múltiplo de 4). Sin embargo, el bloque
> >> previsto para cada POP debe satisfacer por lo menos un 30% de la necesidad
> >> actual del mismo.
> >>
> >> Caso del LIR no-ISP:
> >> El plan de direccionamiento ha de tener en cuenta la longevidad prevista
> >> de la organización.
> >> Debe considerar el espacio necesario para atender a los "clientes", número
> >> de usuarios, extensión de la infraestructura de la organización, estructura
> >> jerárquica y/o geográfica de la organización, segmentación de la
> >> infraestructura por razones de seguridad y a los servicios actuales
> >> considerando el prefijo mínimo para asignaciones recomendadas en la
> >> política vigente.
> >>
> >> Para ponerlo mas claro:
> >> - En un ISP el plan de direccionamiento no debe superar los cuatro años.
> >> Un gobierno planifica a mas tiempo.
> >> - Un ISP no considera la “jerarquía” de la organización para establecer el
> >> plan de direccionamiento. En un gobierno si que ha de ser considerado.
> >> Igualmente los otros puntos.
> >>
> >> Insisto, me baso en CASOS reales ocurridos en Europa. No en algo
> >> imaginario.
> >>
> >> >> Mi propuesta pretende aclarar esta situacion, con una categoria
> >> nueva
> >> >> diferente de ISP, aunque es muy similar a un ISP. Sin embargo opino
> >> que
> >> >> una nueva categoria permite que la membresia establezca, si es
> >> necesario,
> >> >> una diferenciacion en el coste de los recursos, y que se
> >> establezcan otras
> >> >> diferencias como pueden ser el criterio de adjudicación de dichos
> >> >> recursos.
> >> >
> >> > hay que tener un cuidado aqui pues las políticas no establecen
> >> costos de
> >> > asignación o categorias. eso cabe al directorio y asemblea de
> >> miembros
> >> >
> >>
> >> | Efectivamente, lo tengo perfectamente claro, pero si hay dos tipos
> >> de LIR
> >> | (ISP y no-ISP), eso obliga a que tengan el mismo “costo”, porque no
> >> hay forma
> >> | de diferenciarlos. Y yo creo que el costo no debe ser el mismo, me
> >> explico.
> >>
> >> | a) Un usuario final tiene un costo menor, asumo porque NO hace
> >> “lucro”
> >> | directo con los recursos asignados. Aún asi, el costo actual parece
> >> | excesivamente bajo, pero eso es otro tema para debatir precisamente
> >> en el
> >> | directorio y asamblea, simplemente lo comento. b) Un ISP,
> >> obviamente, su
> >> | negocio es “dar servicios” con esos recursos, y es lógico que tenga
> >> un costo
> >> | mucho mas alto. c) Un LIR que NO sea ISP, al igual que un usuario
> >> final NO
> >> | hace “lucro” directo con los recursos asignados. Creo que debería
> >> tener un
> >> | costo inferior al de un ISP y para ello, creo que el directorio y la
> >> asamblea
> >> | “necesitan” una categoría diferente de LIR, distinta de ISP, para
> >> poder
> >> | hacerlo. Sino, es incluso administrativamente difícil tener dos
> >> precios según
> >> | seas LIR o ISP.
> >>
> >> comprendo.
> >> pero como dije, el tema de costos, tarifas, etc no cabe en el foro.
> >>
> >> agrego que lacnic tiene tarifas especiales para organizaciones sin
> >> fines de
> >> lucro que sean usuarios finales.
> >> quizas el directorio podria estudiar algo similar para LIRs. Pero eso
> >> no nos
> >> cabe discutir aqui.
> >>
> >> Se que SI se establecen tarifas diferentes, eso lo tiene que hacer el
> >> directorio, pero si hay una categoría diferente, seria una labor mucho mas
> >> sencilla. Yo no estoy indicando que tenga que ser como parte de la
> >> política, simplemente, la política también facilita esa opción si se desea
> >> que asi sea. Ademas la tarifa actual del 50% solo aplica a usuarios finales
> >> y además NO-gubernamentales, y precisamente lo que estamos viendo es casos
> >> que NO son usuarios finales, y que por lo que consta, hasta ahora,
> >> erróneamente, han sido asi clasificados, pues no se ha entendido bien que
> >> un usuario final NO puede entregar recursos a otras organizaciones.
> >>
> >> >> 2) Este tipo de organizaciones (caso b), tiene unos requisitos que
> >> no son
> >> >> los mismos que los de un ISP. Por ejemplo, la consideración de
> >> “clientes”
> >> >> no es tal, y la extension de la infraestructura, su estructura
> >> jerárquica,
> >> >> la necesidad de entregar bloques mas pequeños a cada
> >> “sub-organización”
> >> >> (cad ministerio, cada entidad del gobierno, etc.).
> >> >
> >> > no queda claro que requisitos son distintos para los clientes del LIR
> >> > comparados con clientes de un ISP.
> >> >
> >> > clientes del NIR son clientes de una red que esperase sea
> >> jerárquica. y por
> >> > las politicas vigentes, el LIR podría entregar bloques a dichos
> >> clientes
> >> > (sean bloques pequenos o grandes) de acuerdo a la necesidad de cada
> >> cliente.
> >> >
> >>
> >> | Si comparas el texto de la política actual con el que propongo para
> >> la nueva
> >> | sección, veras esas diferencias. Para no complicarlo en este email
> >> creo que
> >> | lo podemos debatir aparte, una vez tengamos claro si hace falta una
> >> nueva
> >> | categoría o no para que el directorio pueda establecer otro “rango”
> >> de
> >> | precios.
> >>
> >> ok
> >>
> >> >> El gobierno de nuestro ejemplo, podria optar por hacer multiples
> >> peticiones
> >> >> a LACNIC para cada una de las entidades, y luego anunciarlas de
> >> forma
> >> >> agregada, etc., pero es un trámite administrativo y tecnico
> >> innecesario y
> >> >> no siempre posible, porque puede que haya ministerios sin personal
> >> >> especifico para eso, o muchas otras razones que lo hacen poco
> >> practico, o
> >> >> incluso que los prefijos asignados por LACNIC no fueran contiguos,
> >> etc.
> >> >> Todo ello sin contar la carga de trabajo de realizar “n” peticiones
> >> y
> >> >> justificaciones a LACNIC en lugar de una sola.
> >> >>
> >> >> Se trataria de una peticion de “n” recursos, sumamente “artificial”
> >> si lo
> >> >> quereis entender de este modo.
> >> >
> >> > a ver si comprendi ese punto lo que propones es seria una politica
> >> que le
> >> > permita asignar un rango de prefijo X para un gobierno (LIR), para
> >> que en
> >> > seguida sea divido en rangos menores de prefijos X+Y a entidades del
> >> goberno
> >> > que por su vez van a anunciar dichos prefijos X+Y a sus provedores de
> >> > transito particulares.
> >>
> >> | NO, al contrario. Quiero evitar eso. Ahora mismo un gobierno podría
> >> pedir (un
> >> | ejemplo) un /32 para cada ministerio. Y obtendría n x /32, que si te
> >> fijas
> >> | serian a un costo ridículo comparado con si pide lo mismo, pero
> >> agregado,
> >> | como LIR (con el texto actual). Por eso creo que hay que 1) evitar
> >> esta
> >> | petición “artificial”, 2) Permitiendo asi que tenga una
> >> clasificación de
> >> | costes que pudiera ser diferente a la de ISP y diferente a la de
> >> usuario
> >> | final (quizás algo intermedio).
> >>
> >> ok
> >> entonces es parecido con el esceneario de un ISP.
> >>
> >> Ese recibe un /28 por ejemplo y internamente lo divide en prefijos más
> >> largos
> >> (bloques menores) para sus clientes.
> >> Pero en anuncio a la DFZ es un /32 agregado.
> >>
> >> Si, aquí no hay diferencia. Obviamente el objetivo es que se anuncie
> >> agregado siempre que sea posible.
> >>
> >> > o sea, el gobierno no actuaria como provedor de conectividad en su
> >> ejemplo?
> >> >
> >>
> >> | Precisamente, el gobierno en estos casos que propongo, ES el
> >> proveedor de
> >> | conectividad (típicamente con multihoming, etc.).
> >>
> >> ok
> >>
> >> > eso implicaria en asignar un prefijo que se verá desagregado al
> >> final en la
> >> > tabla. Es eso mismo?
> >>
> >> | Intento evitar esa desagregación. Creo que lo has “leído” justamente
> >> al
> >> | revés. Intento evitar también que se pidan “n” /32 y luego se
> >> anuncien
> >> | agregados (si son contiguos). No hay necesidad que obligar al
> >> gobierno a
> >> | hacer “cosas raras”.
> >>
> >> ok, comprendido.
> >>
> >> >> Mi propuesta pretende, partiendo de los requisitos de la politica
> >> para
> >> >> ISP, establecer otros mas apropiados para este caso, que ademas se
> >> basan
> >> >> en modificaciones recientes a los requisitos habilitados para
> >> gobiernos
> >> >> Europeos en RIPE NCC, atendiendo precisamente a casos concretos y
> >> que ya
> >> >> hemos visto en la region y sin embargo se han asignado recursos como
> >> >> usuarios finales EN CONTRA de la politica actual, porque no son
> >> usuarios
> >> >> finales sino que entregan recursos a otras organizaciones.
> >> >
> >> > para que la discusion sea más productiva, podrias indicar estos casos
> >> > concretos en nuestra región que mencionas que se asigno en contra la
> >> > política?
> >>
> >> | En el ultimo LACNIC, precisamente en el foro de políticas e incluso
> >> en una
> >> | presentación previa, se hablo de un par de casos de gobiernos, no
> >> recuerdo
> >> | todos ahora mismo, pero uno de ellos era Panama. Les pregunte en el
> >> foro
> >> | publico un par de veces para asegurarme y confirmaron que habían
> >> recibido un
> >> | prefijo /32 como usuario final, pero que ellos entregaban “trozos”
> >> de ese
> >> | prefijo a las diversas entidades, y les proporcionaban conectividad.
> >> Eso
> >> | claramente va en contra de la política de usuario final, porque NO
> >> se permite
> >> | entregar a OTRAS entidades, y confirmaron que LEGALMENTE cada
> >> entidad a la
> >> | que asignan direcciones son entidades DIFERENTES. Queda claro que mi
> >> | intención es que se corrija la situación, de hecho, quizás, con la
> >> política
> >> | actual, en este caso concreto, se debería recalificar ese /32 como
> >> ISP y que
> >> | abonen la diferencia de precio.
> >>
> >> okay.
> >> en ese caso hay que ver con lacnic qué fue solicitado y que
> >> justificativa
> >> presentaron.
> >> puede haber pasado que ellos mismos lo solicitaron como END USER.
> >>
> >> lo que solicitaba era un ejemplo de govierno que haya solicitado como
> >> ISP y se
> >> les recuso.
> >>
> >> te comento, que en brasil tenemos una empresa del govierno que actua
> >> como
> >> provedor de servicios y conectividad para organos del govierno y que
> >> ha recibido
> >> un bloque grande como uns ISP governamental.
> >>
> >> o sea, la política se le permite
> >>
> >> Es posible que en este caso, si el bloque que ha solicitado era un /32, o
> >> hasta /28, y el plan de direccionamiento fuera para 4 años, la política
> >> “funcionase” (desconozco los detalles y no se si se quieren hacer
> >> públicos), pero los casos en los que pienso son mucho mas grandes, mas
> >> completos, tienen planes de direccionamiento para muchos mas años, etc.
> >>
> >> no veo que puntos en el texto le impediria un govierno (atraves de su
> >> empresa/organo/departamento tecnico) solicitar a lacnic un bloque como
> >> ISP se le
> >> fuera denegado.
> >>
> >> | Estoy casi seguro que en otros países se ha dado el mismo caso, pero
> >> no
> >> | quiero hablar de esos casos sin tener una constancia tan explicita
> >> como en
> >> | este caso.
> >>
> >> como te comente arriba, hay casos concretos donde se paso el contrario.
> >>
> >> Estoy seguro que si revisamos esas asignaciones, descubriríamos que,
> >> erróneamente, se han podido entregar recursos como usuario final y que sin
> >> embargo están siengo asignados a otras organizaciones del propio gobierno.
> >> Insisto, son organizaciones diferentes administrativamente hablando.
> >>
> >> | Yo creo que o bien porque el precio es mucho menor, o bien porque no
> >> se
> >> | conocen bien las políticas, los que piden recursos pueden a veces
> >> | aprovecharse de la diferencia de precio o bien como digo sin
> >> conocimiento,
> >> | para no explicar que “se van a entregar recursos a otras entidades”
> >> o bien
> >> | que no se dan cuenta que “otras” entidades del gobierno, son
> >> PRECISAMENTE
> >> | otras entidades. No se si me explico …
> >>
> >> ok
> >> pero en ambos los casos la solucion puede ser otra que no la de crear
> >> nuevo
> >> texto (y desde mi humilde opinion, complicar el manual de políticas)
> >>
> >> si el problema es el costo, los miembros deben solicitar al directorio
> >> una
> >> revisión de las tarifas.
> >>
> >> si el problema es comprender las políticas, se pueden hacer tutoriales,
> >> workshops, conferencias o incluso incluir estos temas en las reuniones
> >> que
> >> lacnic ya hace con gobiernos.
> >>
> >> Yo creo que no complicamos el manual, al revés, lo simplificamos, evitamos
> >> la confusión, creamos una categoría diferente para estos casos, se evita
> >> que surja la duda de si son usuarios finales, y se les permite planes de
> >> direccionamiento mas coherentes con el tipo de entidad y no limitados a una
> >> expansión comercial que lógicamente no les aplica porque no son entidades
> >> comerciales.
> >>
> >> un abrazo
> >> Ricardo Patara
> >> _______________________________________________
> >> Politicas mailing list
> >> Politicas at lacnic.net <javascript:;>
> >> https://mail.lacnic.net/mailman/listinfo/politicas
> >>
> >>
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> Politicas mailing list
> >> Politicas at lacnic.net <javascript:;>
> >> 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