[LACNIC/Politicas] Sumary Week 30th May - 7th June - Resumen Semana del 30 de Mayo al 7 de Junio- Sumário Semana 23 de maio ao 7 de junho.

[Roque Gagliano]

Summary of Public Policy List discussions from 31 May to 7 June, 2009.

[LACNIC-2007-01] Modification of the IPv6 Block Announcement Policy

[Nicolás Antoniello - 1st June 2009] - The ARIN community has  
presented a similar proposal: to remove references to routing  
techniques or practices from the policies.

..."Removing the requirement for a single aggregate announcement  
benefits the NRPM itself, as it has been decided by the community that  
it should not contain routing advice."...

[Jordi Palet - 1 June 2009] - ARIN and other RIRs would be seen as bad  
network neighbors if this type of requirements were to be removed. If,  
as mentioned during the meeting, there are other technical solutions  
available instead of disaggregating, these solutions should be  
preferred even if they cost more, as this cost will be limited to  
those who need to deal with such a situation and not to others who  
have routers on the Internet.

We must not repeat the errors we made with IPv4, especially  
considering the fact that the number of prefixes we can generate if we  
allow disaggregation may be in the order of millions. Smaller ISPs or  
companies will be affected the most.

[Jordi Palet - 1st June 2009] - If we allow disaggregation we will ALL  
pay a high cost. If aggregation is not allowed, that cost will be paid  
only by the provider that needs to use alternative techniques; as  
expensive as these may seem the cost will always be lower.

In addition, when it becomes truly necessary to disaggregate, as it  
was also mentioned during the meeting, we will have LISP  
implementations in all routers and, therefore, we will have another  
solution that will not imply costs for anyone.

[Nicolas Antoniello - 2 June 2009] - We are focusing the discussion in  
favor or against this policy modification based on technical  
arguments. If we begin discussing technical solutions or needs, there  
will always be disagreements and endless arguments both for and  
against. The fact that similar proposals have emerged at other RIRs is  
more a consequence of the maturing of the idea of separating policies  
from implementations than a result of technical needs.

I believe that policies are there to be complied with: they are not  
recommendations but regulations that must be followed. Thus, a policy  
that cannot be applied may weaken the policy itself. I understand that  
we must modify the policy in order to eliminate all references to  
routing mechanism requirements.

[Luis Carlos Solano - 2 June 2009] - They should be completely  
eliminated because, as mentioned earlier, the manner in which an ISP  
balances its load and announces its prefixes (today in v4, later in  
v6) is subject to factors such as the number of links and their speed,  
types of services and clients. Consequently, a policy must in no way  
try to impose a technical requirement that in the long run i) will  
interfere with the provision of services to the clients, and ii)  
cannot be controlled.

I don't know if it is correct to think of LACNIC as the organization  
in charge of monitoring BGP tables to see who is complying with a  
certain routing policy and who is not.

Evidently, I am - and we all should be - against fragmentation, which  
is the particular issue under discussion, but this and all other  
routing issues must be left to best practices. The day that an ISP (as  
is the case today with v4) injects large numbers of small prefixes  
(later on we'll discuss what “small” means and how large “a large  
number” is) into the routing tables, then the community can filter it.

-------------------------------

Sumario de las discusiones en la Lista Pública de Políticas desde el  
31 de Mayo 2009 hasta el 7 de Junio.

[LACNIC-2007-01] Modificación a la política de publicación de bloques  
IPv6

[Nicolás Antoniello - 1 junio 2009] - Hay una propuesta de la  
comunidad de ARIN en el mismo sentido: quitar de las políticas las
referencias a técnicas o prácticas de Routing.

..."Removing the requirement for a single aggregate announcement
benefits the NRPM itself, as it has been decided by the community that
it should not contain routing advice."...

[Jordi Palet - 1 junio 2009] - Vería a ARIN y otros RIRs como malos  
vecinos de red si este tipo de reglas son relajadas. Si hay otras  
soluciones técnicas en lugar de desagregar, tal como se mencionó en el  
encuentro, deben ser preferidas aun cuando cuesten más, ya que ese  
costo está acotado a quien necesite manejar tal situación y no al  
resto de las personas que tienen routers en Internet.

No debemos repetir los errores que tuvimos con IPv4, especialmente  
considerando que el número de prefijos que podemos generar si  
permitimos desagregar puede estar en el orden de millones. Los ISPs o  
empresas más chicas serán los más afectados.

[Jordi Palet - 1 junio 2009] - Si permitimos la desagregación TODOS  
pagaremos un alto coste. Si no se  permite la agregación, ese coste lo  
paga sólo el proveedor que tiene que usar tecnicas alternativas, por  
muy costosas que éstas puedan parecer, será siempre un coste menor.

Además, cuando realmente haga falta desagregar, como también se  
comentó en la reunion, dispondremos de implementaciones de LISP en  
todos los routers y por tanto, tendremos otra solución que no  
conllevará costes para nadie.

[Nicolas Antoniello - 2 junio 2009] - Estamos centrando la discusión a  
favor o en contra de esta modificación a la política en argumentos de  
corte técnico. Si nos ponemos a discutir soluciones o necesidades  
técnicas siempre habrá discrepancia e infinidad de argumentos en uno u  
otro sentido. El surgimiento de propuestas similares en otros RIR,  
responde más que a una necesidad técnica, a una maduración de la idea  
de separar las políticas de las implementaciones.

Creo que las políticas están para cumplirse, no son recomendaciones,  
son reglamentos a seguir. Entonces, una política que no se puede  
aplicar podría quitarle fuerza a la misma política. Entiendo que  
debemos modificar la política a fin de eliminar toda referencia a  
imposiciones de mecanismos de routing.

[Luis Carlos Solano - 2 junio 2009] - Deberían eliminarse por completo  
pues como comentaba antes, la forma que un ISP balancea la carga y  
anuncia sus prefijos (hoy en v4 y así será en v6) está sujeto a  
factores como el número y velocidad de los enlaces, los tipos de  
servicios y clientes. Así que una política no debe de ninguna manera,  
tratar de imponer algo técnico que a la postre i) Interfiera en la  
prestación de servicios a los clientes y ii) no se pueda controlar.

No sé si sea correcto en pensar en LACNIC como el encargado de estar  
monitoreando las tablas de BGP para ver quién cumple o no con alguna  
política de enrutamiento.

Sobra decir -creo- que estoy y todos deberíamos estar en contra de la  
fragmentación, que es el caso particular en discusión, pero este y  
todos los demás temas de enrutamiento, deben quedar en la mejor  
práctica. El día que un ISP por incapacidad (como sucede hoy en v4)  
inyecte a la tabla de rutas prefijos pequeños y en alta cantidad  
(luego hablamos de qué es pequeño y cuánto es mucho) pues entonces,  
que la comunidad lo filtre.


----------------------------

Sumário das discussões na Lista Pública de Políticas de 31 de maio  
2009 até 7 de junho.

[LACNIC-2007-01] Modificação à política de publicação de blocos IPv6

[Nicolás Antoniello - 1 junho 2009] – Existe uma proposta da  
comunidade do ARIN no mesmo sentido: tirar das políticas as  
referências às técnicas ou práticas de roteamento.

..."Removing the requirement for a single aggregate announcement  
benefits the NRPM itself, as it has been decided by the community that  
it should not contain routing advice."... (Eliminar o requisito de um  
único anúncio agregado beneficia o Manual de Políticas sobre Recursos  
de Numeração já que foi decidido pela comunidade que este não deveria  
conter recomendações sobre roteamento).

[Jordi Palet - 1 junho 2009] – Eu consideraria o ARIN e outros RIRs  
como maus vizinhos de rede se esse tipo de regras fossem relaxadas. Se  
houver outras soluções técnicas em lugar de desagregar, como foi  
mencionado no encontro, deveriam preferir-se mesmo quando fossem mais  
caras já que esse custo estaria limitado para quem necessite manejar a  
situação e não para o resto das pessoas que têm routers na Internet.

Não devemos repetir os erros que tivemos com o IPv4, principalmente  
levando em conta que o número de prefixos que podemos gerar, caso  
permitamos desagregar, pode ser de milhões. Os ISPs ou empresas  
menores vão ser os mais afetados.


[Jordi Palet - 1 junho 2009] – Se permitirmos a desagregação TODOS  
vamos pagar um alto custo. Se a desagregação não for permitida, esse  
custo vai ser pago somente pelo provedor que tiver que usar técnicas  
alternativas, e, a pesar de que estas puderem parecer muito caras,  o  
custo vai ser sempre menor.

Além disso, quando realmente fizer falta desagregar, como também foi  
falado na reunião, vamos dispor de implementações de LISP em todos os  
routers e, portanto, teremos outra solução que não vai acarretar  
custos para ninguém.


[Nicolas Antoniello - 2 junho 2009] – Estamos centralizando a  
discussão a favor ou em contra dessa modificação à política com  
argumentos de cunho técnico. Sempre que discutamos soluções ou  
necessidades técnicas haverá discrepância e infinidade de argumentos  
em um sentido ou outro. O surgimento de propostas similares em outros  
RIRs corresponde mais do que a uma necessidade técnica a um  
amadurecimento da idéia de separar as políticas das implementações.

Acredito que as políticas estão para serem cumpridas, não são  
recomendações, são regulamentos a seguir. Então, uma política que não  
pode ser aplicada poderia tirar as forças da própria política. Entendo  
que devemos modificar a política para poder eliminar toda referência a  
imposições de mecanismos de roteamento.


[Luis Carlos Solano - 2 junho 2009] – Deveriam eliminar-se  
completamente já que, como disse antes, a forma que um ISP balança a  
carga e anuncia seus prefixos (hoje em v4 e depois em v6) depende de  
fatores como o número e velocidade dos enlaces, os tipos de serviços e  
clientes. Assim que uma política não deve de jeito nenhum tentar impor  
algo técnico que no final i) interfira na prestação de serviços aos  
clientes e ii) não possa ser controlado.


Não sei se está correto pensar no LACNIC como o encarregado de  
monitorar as tabelas de BGP para ver quem cumpre o não com alguma  
política de roteamento.

Demais está dizer – acredito- que eu estou e todos deveríamos estar  
contra da fragmentação que é o assunto particular em discussão, mas  
esse e todos os outros assuntos de roteamento devem ficar na melhor  
prática. O dia em que um ISP por incapacidade (como acontece hoje em  
v4) introduza na tabela de rotas prefixos pequenos e em grande  
quantidade (depois falamos de que é pequeno e quanto é muito) então, a  
comunidade vai tê-los que filtrar.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part
URL: <https://mail.lacnic.net/pipermail/politicas/attachments/20090611/0d5dcff5/attachment.sig>