[LACNIC/Politicas] Modificacion a la Politica de asignacion de Bloques IPv6
Gustavo Lozano
glozano at nic.mx
Tue Apr 22 17:46:23 BRT 2008
Nicolas,
Nadie mencionó que LACNIC no lo puede hacer
cumplir; lo que mencioné es que la política
necesita mayor detalle si quisiéramos que LACNIC
realice el “enforcement” del requerimiento expresado en la política actual.
No estoy de acuerdo con tu aseveración de que una
política de un RIR no puede especificar
agregación como condición. Las políticas le
dictan a un RIR las funciones que la comunidad
considera necesarias que realice. Si la comunidad
decide que la agregación es importante entonces
le puede dotar a LACNIC de los mecanismos para realizar el “enforcement”.
Si la comunidad llega a la conclusión de que el
exigir algún nivel de agregación de rutas es la
única forma de que el “sistema de rutas
inter-dominio” siga funcionando adecuadamente,
entonces los RIRs son los lugares idóneos para
exigir y monitorear este requerimiento porque los
consumidores de direccionamiento IP y los RIRs tienen una relación directa.
Mi propuesta es dejar la política tal como esta y
en un futuro si el problema de crecimiento de BGP
resulta ser un problema que pone en riesgo al
Internet dotar a LACNIC de los mecanismos para realizar el “enforcement”.
Gustavo.
At 11:55 a.m. 22/04/2008, you wrote:
>Jordi/Gustavo,
>
>Yo no se si he sido claro en lo expuesto en los
>correos anteriores, tal vez no se entienda
>mi punto de vista, lo repaso:
>
>No estoy a favor de la desagregación, ni estoy
>diciendo que se deba desagregar.
>Lo que estoy diciendo (en palabras mas burdas,
>para ver si queda mas claro el punto) es
>que eso no es incumbencia de una política de
>asignación de direcciones el imponer la
>sumarizacion como condición.
>
>Simplemente es eso... y además, si uds. mismos
>ven que LACNIC (en este caso) no lo puede
>hacer cumplir, no veo por que se defiende el dejar ese requerimiento.
>
>También quería mencionar que estoy totalmente de
>acuerdo con lo expuesto por Ricardo.
>
>Espero ser claro en lo expuesto.
>
>Saludos,
>Nicolas.
>
>
>
>
> > ----------------------------------------------------------------------
> >
> > Message: 1
> > Date: Mon, 21 Apr 2008 23:28:56 +0200
> > From: JORDI PALET MARTINEZ <jordi.palet at consulintel.es>
> > Subject: Re: [LACNIC/Politicas] Modificaci ? n a la Pol ? tica de
> > Publicaci ? n de Bloques IPv6
> > To: LACNIC Policy mailling list <politicas at lacnic.net>
> > Message-ID: <C432D3B8.1C1264%jordi.palet at consulintel.es>
> > Content-Type: text/plain; charset="ISO-8859-1"
> >
> > Coincido con Gustavo.
> >
> > No estoy de acuerdo con esta propuesta, y de
> hecho habra una presentacion en
> > el proximo LACNIC que explica las alternativas para hacer traffic
> > engineering sin desagregar.
> >
> > Creo que no hay motivacion para desagregar y que lo que hay que hacer es
> > negociar correctamente con los upstreams, que para eso se les paga. No
> > debemos repetir los errores de IPv4.
> >
> > De hecho, en otras regiones se esta produccione el fenomeno de que se
> > asignan prefijos /48 para PI y no estan siendo enrutados y no son visibles,
> > y que muchos upstreams se niegan a modificar sus filtros. Asi que considero
> > que cualquier cosa que implique que se enrute algo menor de /32 es negativo
> > para la region y no debe ser aceptado por la comunidad.
> >
> > Ademas, no creo que una propuesta de politica pueda decidir que se promueve
> > algo similar en otras regiones. No lo veo acorde con el PDP que solo afecta
> > a la propia region, como es logico.
> >
> > Saludos,
> > Jordi
> >
> >
> >
> >
> >> De: Gustavo Lozano <glozano at nic.mx>
> >> Responder a: LACNIC Policy mailling list <politicas at lacnic.net>
> >> Fecha: Thu, 17 Apr 2008 19:41:50 -0500
> >> Para: <nantoniello at antel.net.uy>, LACNIC Policy mailling list
> >> <politicas at lacnic.net>
> >> Asunto: Re: [LACNIC/Politicas] Modificaci?n
> a la Pol?tica de Publicaci?n de
> >> Bloques IPv6
> >>
> >> Nicol?s,
> >>
> >> Antes de discutir tu propuesta me gustar?a
> >> obtener respuesta a las siguientes preguntas:
> >> * ?Cu?l es el o los looking glass oficial(es)
> >> que utiliza LACNIC para validar este requerimiento?
> >> * ?Qu? sucede si en el o los looking glass
> >> oficial(es) que usa LACNIC existe un prefijo
> >> desagregado pero en otros looking glass no? Los
> >> looking glass muestran una vista de la ?tabla
> >> global de BGP? y la vista depende de los filtros implementados.
> >> * ?Cu?l es el ?castigo? por no cumplir con
> >> este texto de la pol?tica? En cuanto tiempo se
> >> realiza el ?castigo? o en otras palabras ?cuanto
> >> tiempo se le da al ISP para ser ?compliance? una
> >> vez detectado una violaci?n a este punto?
> >> * ?Alg?n ISP de la regi?n maneja un volumen
> >> de trafico suficiente para requerir hacer ?traffic engineering? en IPv6?
> >> Yo soy libre de filtrar lo que yo quiera en mis
> >> ruteadores. Si tienes la necesidad de desagregar
> >> tu asignaci?n de IPv6, entonces tu tienes que
> >> solicitarle a tus upstream que esos prefijos sean
> >> aceptados y ellos pueden decidir hacerlo o no sin
> >> importar lo que diga la pol?tica de LACNIC.
> >>
> >> El texto que propones ?Anunciar en el sistema de
> >> rutas inter-dominio de Internet el bloque
> >> asignado, con la m?nima desagregaci?n que le sea
> >> posible? es igual a quitar el texto original
> >> porque se convierte en una simple sugerencia.
> >>
> >> Estoy de acuerdo en quitar el requerimiento
> >> ?Anunciar en el sistema de rutas inter-dominio de
> >> Internet un ?nico bloque, que agregue toda la
> >> asignaci?n de direcciones IPv6 recibida? pero
> >> creo que no es el momento adecuado. Actualmente
> >> existe la percepci?n en gran parte de la
> >> comunidad de que existe un problema con el
> >> crecimiento de los prefijos anunciados en el
> >> ?sistema inter-dominio? o DFZ o como se le quiera
> >> llamar. Desde mi punto de vista no debemos
> >> modificar el texto hasta que la comunidad
> >> operativa se sienta satisfecha con una soluci?n o
> >> un an?lisis que indique que el problema no existe
> >> y simplemente se resuelve con el ciclo de renovaciones de hardware.
> >>
> >> Creo que tu propuesta deber?amos dejarla
> >> congelada siguiendo una l?gica parecida a la
> >> determinaci?n final del caso Bernstein vs USA.
> >> http://en.wikipedia.org/wiki/Bernstein_v._United_States
> >>
> >> Gustavo
> >>
> >> At 09:36 a.m. 16/04/2008, you wrote:
> >>> Estimados,
> >>>
> >>> De acuerdo a lo planteado en la reuni?n pasada
> >>> en Margarita, y acorde a la decisi?n votada
> >>> en la mencionada reuni?n de posponer para este
> >>> a?o la votaci?n de la propuesta, reenv?o a
> >>> la lista la propuesta, con algunas
> >>> modificaciones al texto del a?o pasado, con la
> >>> finalidad de escuchar su opini?n.
> >>>
> >>> Referencia:
> >>> LAC-2007-01. Modificaci?n a la Pol?tica de Publicaci?n de Bloques IPv6.
> >>> Nicol?s Antoniello.
> >>> http://mail.lacnic.net/pipermail/politicas/2007-March/006897.html
> >>>
> >>>
> >>> Propuesta:
> >>> Se propone modificar el punto 5.1.1.c de la Pol?tica de IPv6
> >>> 5.1 Adjudicaci?n inicial
> >>> 5.1.1 Criterio de adjudicaci?n inicial
> >>> c) Anunciar en el sistema de rutas inter-dominio
> >>> de Internet un ?nico bloque, que agregue
> >>> toda la asignaci?n de direcciones IPv6 recibida,
> >>> en un plazo no mayor de 12 meses.
> >>>
> >>> El texto propuesto ser?a:
> >>> c) Anunciar en el sistema de rutas inter-dominio
> >>> de Internet el bloque asignado, con la
> >>> m?nima desagregaci?n que le sea posible, en un plazo no mayor a 12 meses.
> >>>
> >>>
> >>> Y promover el cambio de los equivalentes a nivel de todo los RIR.
> >>>
> >>>
> >>> Motivaci?n:
> >>> El problema surge cuando un RIR asigna un
> >>> prefijo /28 (por ejemplo) a un ISP que tiene
> >>> enlaces a Internet con m?ltiples proveedores
> >>> (multi-homing) usando publicaciones BGP.
> >>> De acuerdo con la pol?tica de LACNIC (y de la de
> >>> otros RIRs), el ISP debe publicar el /28
> >>> a trav?s de los tres enlaces sin posibilidad de
> >>> desagregaci?n. El problema con esta
> >>> pol?tica es que al hacer esto el ISP pierde
> >>> control sobre tr?fico, limitando la capacidad
> >>> de distribuir el tr?fico sobre los tres
> >>> enlaces diferentes, a?n cuando utilice t?cnicas
> >>> de ingenier?a de tr?fico y/o manejo de comunidades BGP.
> >>> Es posible que un prefijo /28 tenga una gran
> >>> cantidad de tr?fico entrante asociado, de
> >>> modo que creo que la pol?tica deber?a permitir
> >>> la desagregaci?n (subnets) del prefijo.
> >>> En t?rminos generales, entiendo que una pol?tica
> >>> de asignaci?n de bloques de direcciones
> >>> IP puede, en todo caso, recomendar o exhortar a
> >>> quienes reciben dicha asignaci?n a
> >>> optimizar la forma en que el bloque es publicado
> >>> a fin de reducir al m?nimo posible el
> >>> impacto en las "tablas de rutas" globales, pero
> >>> en ning?n caso, deber?a imponer una forma
> >>> de publicaci?n como requisito para una asignaci?n.
> >>> _______________________________________________
> >>> 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
> >
> >
> >
> >
> > **********************************************
> > 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.
> >
> >
> >
> >
> >
> > ------------------------------
> >
> > Message: 2
> > Date: Mon, 21 Apr 2008 17:03:31 -0500
> > From: Gustavo Lozano <glozano at nic.mx>
> > Subject: [LACNIC/Politicas] Re: Modificaci ? n a la Pol ? t ica de
> > Publicaci ? n de Bloques IPv6
> > To: jordi.palet at consulintel.es, LACNIC Policy mailling list
> > <politicas at lacnic.net>, LACNIC Policy mailling list
> > <politicas at lacnic.net>
> > Message-ID: <20080421220327.0D6F5544C78 at mail.nic.mx>
> > Content-Type: text/plain; charset="iso-8859-1"; format=flowed
> >
> >
> > Sin necesidad de entrar a la discusi?n t?cnica
> > sobre la necesidad de desagregar o no, creo que
> > no es necesario modificar la pol?tica, porque
> > simplemente no representa un problema o riesgo
> > para quien decida desagregar su asignaci?n.
> >
> > Si la comunidad decidiera que LACNIC tiene que
> > realizar ?enforcement? del punto que estamos
> > discutiendo entonces tendr?an que definirse
> > conceptos (empezando por definir que abarca el
> > sistema de rutas inter-dominio de Internet),
> > adecuar pol?ticas, crear mecanismos para
> > monitorear y definir acciones en caso de no cumplir con el requerimiento.
> >
> > En pocas palabras, si necesitas desagregar tu
> > asignaci?n de IPv6 lo puedes hacer si tus
> > upstreams aceptan esos prefijos y seria dif?cil
> > decir que estas violando la pol?tica porque la
> > misma no tiene el detalle suficiente.
> >
> > Creo que es adecuado conservar por el momento el
> > texto actual porque captura el pensamiento de
> > hacer algo para evitar el ?problema? del crecimiento de prefijos en BGP.
> >
> > En un futuro que existan soluciones para el
> > ?problema? de crecimiento de prefijos,
> > multihoming e ingenier?a de tr?fico sin necesidad
> > de anunciar m?s espec?ficos podr?amos revisar la
> > conveniencia de quitar el texto de la pol?tica.
> >
> >
> > Gustavo
> >
> > At 04:28 p.m. 21/04/2008, JORDI PALET MARTINEZ wrote:
> >> Coincido con Gustavo.
> >>
> >> No estoy de acuerdo con esta propuesta, y de
> hecho habra una presentacion en
> >> el proximo LACNIC que explica las alternativas para hacer traffic
> >> engineering sin desagregar.
> >>
> >> Creo que no hay motivacion para desagregar y que lo que hay que hacer es
> >> negociar correctamente con los upstreams, que para eso se les paga. No
> >> debemos repetir los errores de IPv4.
> >>
> >> De hecho, en otras regiones se esta produccione el fenomeno de que se
> >> asignan prefijos /48 para PI y no estan
> siendo enrutados y no son visibles,
> >> y que muchos upstreams se niegan a modificar
> sus filtros. Asi que considero
> >> que cualquier cosa que implique que se
> enrute algo menor de /32 es negativo
> >> para la region y no debe ser aceptado por la comunidad.
> >>
> >> Ademas, no creo que una propuesta de
> politica pueda decidir que se promueve
> >> algo similar en otras regiones. No lo veo
> acorde con el PDP que solo afecta
> >> a la propia region, como es logico.
> >>
> >> Saludos,
> >> Jordi
> >>
> >>
> >>
> >>
> >>> De: Gustavo Lozano <glozano at nic.mx>
> >>> Responder a: LACNIC Policy mailling list <politicas at lacnic.net>
> >>> Fecha: Thu, 17 Apr 2008 19:41:50 -0500
> >>> Para: <nantoniello at antel.net.uy>, LACNIC Policy mailling list
> >>> <politicas at lacnic.net>
> >>> Asunto: Re: [LACNIC/Politicas] Modificaci?n a
> >> la Pol?tica de Publicaci?n de
> >>> Bloques IPv6
> >>>
> >>> Nicol?s,
> >>>
> >>> Antes de discutir tu propuesta me gustar?a
> >>> obtener respuesta a las siguientes preguntas:
> >>> * ?Cu?l es el o los looking glass oficial(es)
> >>> que utiliza LACNIC para validar este requerimiento?
> >>> * ?Qu? sucede si en el o los looking glass
> >>> oficial(es) que usa LACNIC existe un prefijo
> >>> desagregado pero en otros looking glass no? Los
> >>> looking glass muestran una vista de la ?tabla
> >>> global de BGP? y la vista depende de los filtros implementados.
> >>> * ?Cu?l es el ?castigo? por no cumplir con
> >>> este texto de la pol?tica? En cuanto tiempo se
> >>> realiza el ?castigo? o en otras palabras ?cuanto
> >>> tiempo se le da al ISP para ser ?compliance? una
> >>> vez detectado una violaci?n a este punto?
> >>> * ?Alg?n ISP de la regi?n maneja un volumen
> >>> de trafico suficiente para requerir hacer ?traffic engineering? en IPv6?
> >>> Yo soy libre de filtrar lo que yo quiera en mis
> >>> ruteadores. Si tienes la necesidad de desagregar
> >>> tu asignaci?n de IPv6, entonces tu tienes que
> >>> solicitarle a tus upstream que esos prefijos sean
> >>> aceptados y ellos pueden decidir hacerlo o no sin
> >>> importar lo que diga la pol?tica de LACNIC.
> >>>
> >>> El texto que propones ?Anunciar en el sistema de
> >>> rutas inter-dominio de Internet el bloque
> >>> asignado, con la m?nima desagregaci?n que le sea
> >>> posible? es igual a quitar el texto original
> >>> porque se convierte en una simple sugerencia.
> >>>
> >>> Estoy de acuerdo en quitar el requerimiento
> >>> ?Anunciar en el sistema de rutas inter-dominio de
> >>> Internet un ?nico bloque, que agregue toda la
> >>> asignaci?n de direcciones IPv6 recibida? pero
> >>> creo que no es el momento adecuado. Actualmente
> >>> existe la percepci?n en gran parte de la
> >>> comunidad de que existe un problema con el
> >>> crecimiento de los prefijos anunciados en el
> >>> ?sistema inter-dominio? o DFZ o como se le quiera
> >>> llamar. Desde mi punto de vista no debemos
> >>> modificar el texto hasta que la comunidad
> >>> operativa se sienta satisfecha con una soluci?n o
> >>> un an?lisis que indique que el problema no existe
> >>> y simplemente se resuelve con el ciclo de renovaciones de hardware.
> >>>
> >>> Creo que tu propuesta deber?amos dejarla
> >>> congelada siguiendo una l?gica parecida a la
> >>> determinaci?n final del caso Bernstein vs USA.
> >>> http://en.wikipedia.org/wiki/Bernstein_v._United_States
> >>>
> >>> Gustavo
> >>>
> >>> At 09:36 a.m. 16/04/2008, you wrote:
> >>>> Estimados,
> >>>>
> >>>> De acuerdo a lo planteado en la reuni?n pasada
> >>>> en Margarita, y acorde a la decisi?n votada
> >>>> en la mencionada reuni?n de posponer para este
> >>>> a?o la votaci?n de la propuesta, reenv?o a
> >>>> la lista la propuesta, con algunas
> >>>> modificaciones al texto del a?o pasado, con la
> >>>> finalidad de escuchar su opini?n.
> >>>>
> >>>> Referencia:
> >>>> LAC-2007-01. Modificaci?n a la Pol?tica de Publicaci?n de Bloques IPv6.
> >>>> Nicol?s Antoniello.
> >>>> http://mail.lacnic.net/pipermail/politicas/2007-March/006897.html
> >>>>
> >>>>
> >>>> Propuesta:
> >>>> Se propone modificar el punto 5.1.1.c de la Pol?tica de IPv6
> >>>> 5.1 Adjudicaci?n inicial
> >>>> 5.1.1 Criterio de adjudicaci?n inicial
> >>>> c) Anunciar en el sistema de rutas inter-dominio
> >>>> de Internet un ?nico bloque, que agregue
> >>>> toda la asignaci?n de direcciones IPv6 recibida,
> >>>> en un plazo no mayor de 12 meses.
> >>>>
> >>>> El texto propuesto ser?a:
> >>>> c) Anunciar en el sistema de rutas inter-dominio
> >>>> de Internet el bloque asignado, con la
> >>>> m?nima desagregaci?n que le sea posible,
> en un plazo no mayor a 12 meses.
> >>>>
> >>>>
> >>>> Y promover el cambio de los equivalentes a nivel de todo los RIR.
> >>>>
> >>>>
> >>>> Motivaci?n:
> >>>> El problema surge cuando un RIR asigna un
> >>>> prefijo /28 (por ejemplo) a un ISP que tiene
> >>>> enlaces a Internet con m?ltiples proveedores
> >>>> (multi-homing) usando publicaciones BGP.
> >>>> De acuerdo con la pol?tica de LACNIC (y de la de
> >>>> otros RIRs), el ISP debe publicar el /28
> >>>> a trav?s de los tres enlaces sin posibilidad de
> >>>> desagregaci?n. El problema con esta
> >>>> pol?tica es que al hacer esto el ISP pierde
> >>>> control sobre tr?fico, limitando la capacidad
> >>>> de distribuir el tr?fico sobre los tres
> >>>> enlaces diferentes, a?n cuando utilice t?cnicas
> >>>> de ingenier?a de tr?fico y/o manejo de comunidades BGP.
> >>>> Es posible que un prefijo /28 tenga una gran
> >>>> cantidad de tr?fico entrante asociado, de
> >>>> modo que creo que la pol?tica deber?a permitir
> >>>> la desagregaci?n (subnets) del prefijo.
> >>>> En t?rminos generales, entiendo que una pol?tica
> >>>> de asignaci?n de bloques de direcciones
> >>>> IP puede, en todo caso, recomendar o exhortar a
> >>>> quienes reciben dicha asignaci?n a
> >>>> optimizar la forma en que el bloque es publicado
> >>>> a fin de reducir al m?nimo posible el
> >>>> impacto en las "tablas de rutas" globales, pero
> >>>> en ning?n caso, deber?a imponer una forma
> >>>> de publicaci?n como requisito para una asignaci?n.
> >>>> _______________________________________________
> >>>> 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
> >>
> >>
> >>
> >> **********************************************
> >> 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.
> >>
> >>
> >>
> >> _______________________________________________
> >> 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
> >
> >
> > End of Politicas Digest, Vol 60, Issue 7
> > ****************************************
>_______________________________________________
>Politicas mailing list
>Politicas at lacnic.net
>https://mail.lacnic.net/mailman/listinfo/politicas
More information about the Politicas
mailing list