[LACNIC/Politicas] Politica de asignación de bloques IPv6 (sobre LACNIC-2007-01)
JORDI PALET MARTINEZ
jordi.palet at consulintel.es
Mon Jun 1 17:51:44 BRT 2009
Hi Scott,
Yes, I knew about this around the same time I sent my email.
I see it in the other way around. I will see ARIN or other RIRs participants
as bad net citizens if this type of rules are relaxed. As indicated in the
meeting, while there are other technical solutions instead of
deaaggregation, they must be preferred even if they cost MORE, because that
cost is bound to the one that need to handle that situation, NOT to the rest
of the people having routers in Internet.
We should NOT repeat the mistakes done with IPv4, specially considering that
the number of prefixes that we can generate if we allow deagregating, can be
in the order of millions. The smaller ISPs or enterprises will be more
affected. Definitively not reasonable.
Regards,
Jordi
> From: Scott Leibrand <scottleibrand at gmail.com>
> Reply-To: <scottleibrand at gmail.com>
> Date: Fri, 29 May 2009 11:49:18 -0500
> To: Jordi Palet Martínez <jordi.palet at consulintel.es>, <politicas at lacnic.net>
> Subject: Re: [LACNIC/Politicas] Politica de asignación de bloques IPv6 (sobre
> LACNIC-2007-01)
>
> Jordi,
>
> FYI, a new proposal (Open Access To IPv6) was just posted to the public
> policy mailing list (PPML) in ARIN that would (among other things)
> remove "by advertising that connectivity through its single aggregated
> address allocation" from article 3 of section 6.5.1.1.
>
> In my personal opinion, LACNIC would not be considered a "bad neighbor"
> if you do the same.
>
> -Scott
>
> JORDI PALET MARTINEZ wrote:
>> Hola Luis Carlos,
>>
>> Pero bajo mi punto de vista, si tienes un cliente lo suficientemente grande
>> para que necesite anunciar su /48, lo mas logico, es que ese cliente reciba
>> de LACNIC directamente (como IPv6 PI) ese /48 (o el tamaño de prefijo que
>> corresponda), porque lo mas probable es que ese cliente tenga varios caminos
>> hacia Internet (con uno o varios proveedores). Asi que no haria falta
>> desagregar ese prefijo del tuyo, sino que seria otro diferente.
>>
>> Si eliminamos esa restriccion de la politica, mientras eso no ocurra en
>> otras regiones, podria darse el caso de que "todos" los operadores de la
>> region de LACNIC, puedan ser considerados "malos vecinos".
>>
>> Saludos,
>> Jordi
>>
>>
>>
>>
>>
>>> From: Luis Carlos Solano <lsolano at racsa.co.cr>
>>> Reply-To: "Lista para discusió n de politicas de la comunidad de
>>> LACNIC"
>>> <politicas at lacnic.net>
>>> Date: Fri, 29 May 2009 08:46:18 -0600
>>> To: <politicas at lacnic.net>
>>> Subject: Re: [LACNIC/Politicas] Politica de asignación de bloques IPv6
>>> (sobre
>>> LACNIC-2007-01)
>>>
>>> JORDI PALET MARTINEZ wrote:
>>>
>>>> Creo que la desagregacion es mala, y habiendo soluciones tecnicas, es
>>>> preferible adoptarlas antes que llegar a una situacion en el futuro en que
>>>> el numero de rutas sea inaceptable para muchos ISPs, sobre todo los
>>>> pequeños
>>>> y medianos, que tendrian que hacer inversiones astronomicas en utilizar
>>>> routers que hoy por hoy, ni siquiera existen.
>>>>
>>> La desagregación es pésima, cierto, pero pienso que en IPv6, por ser un
>>> /48 tan grande, se presta para la desagregación, a niveles comerciales.
>>>
>>> Al menos en RACSA, hoy, trabajamos con enlaces STM-4s. Hemos buscado con
>>> el tiempo que los proveedores fijen una única sesión BGP para varios
>>> enlaces, con el fin de agregar al máximo.
>>>
>>> No obstante, podría darse en el futuro que un cliente /grande/ y/o
>>> servicio particular necesite sólo para él, un enlace STM-4. En vista
>>> que un /48 puede ser suficiente para un ese cliente, parecería que por
>>> razones comerciales (servicio diferenciado) ese /48 debería enrutarse
>>> por un enlace en particular.
>>>
>>> Evidentemente, un ISP que anuncie un /48 sería un enemigo de la
>>> comunidad (y es un ejemplo extremo), pero al ser la unidad mínima tan
>>> grande, podría cada una de estas unidades mínimas generar suficiente
>>> tráfico para llenar una sesión BGP de un ISP.
>>>
>>> Mi humuilde opinión es entonces que todo lo relacionado con el
>>> enrutamiento debe eliminarse cualquier política. Las mejores prácticas
>>> dictarán el tamaño de los filtros en los enrutadores de modo que los
>>> /malos vecinos/ se expongan a ser filtrados.
>>>
>>> Saludos,
>>>
>>> --
>>> Luis Carlos.
>>>
>>> _______________________________________________
>>> 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
>>
**********************************************
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.
More information about the Politicas
mailing list