[LACNIC/Napla] IXP en La Paz

Javier Galvez jcgalvez at MegaLink.com
Thu Apr 11 17:35:38 BRT 2013


HOla,

napla at lacnic.net on April 11, 2013 at 10:32 AM -0430 wrote:
>Como bien dice Arturo, las reglas mínimas del juego deben estar 
>contenidas en un documento generalmente consensuado y firmado por todos 
>sus participantes.

Si "no hay" participantes como se puede consensuar algo?, infortunadamente
estamos actuando como borreguitos, no sabemos que hacer, y solo estamos
esperando que alguien mas nos guie.
>
>Si bien cada operador establece sus propias normas, hemos recopilado y 
>desarrollado un ejemplo de documento de política (adjunto en el correo) 
>que contiene todos los elementos que consideramos críticos para sentar 
>las bases del punto de intercambio.

El de ecuador me parecio muy completo, lo copio a continuacion

http://www.aeprovi.org.ec/index.php?option=com_content&task=view&id=145&Itemid=105



Políticas sobre el enrutamiento
			


	Las siguientes políticas de enrutamiento rigen la operación y
administración de NAP.EC:

Protocolo de enrutamiento BGP.
Una sola sesión BGP por conexión con un servidor de rutas.
No se permite ebgp multi-hop.
El proveedor debe anunciar los mismos prefijos sobre todas sus conexiones
a NAP.EC, excepto aquellos proveedores que utilizan los enlaces
interurbanos de NAP.EC.
Se bloquean rangos de direcciones IPv4 de uso especial (RFC 5735, es decir
redes privadas, de documentación, de uso experimental o de investigación,
reservadas por IANA) y rutas por defecto.
Se aceptan prefijos IPv4 con máscaras entre 18 y 24 bits.
Se aceptan prefijos IPv6 con máscaras entre 31 y 48 bits. 
En NAP.EC no se filtran aplicaciones, ni “prefijos válidos”;  esta
condición debe cumplirse también de lado del proveedor .
No se aceptan conexiones con números de sistema autónomo (ASN) de uso
privado (RFC 1930) o de documentación (RFC 5398).  Se eliminan del ASPATH
los ASN privados. 
Desde NAP.EC, "todos" los prefijos son anunciados con comunidad no-export.
A todos los prefijos recibidos en NAP.EC se les asigna un valor de cero
para el atributo MED. 

Desde NAP.EC, los prefijos son anunciados con los siguientes valores del
atributo MED:   0 si ha sido recibido en el mismo nodo (ciudad) y 100 si
ha sido recibido en otro nodo (ciudad).
En el extremo de NAP.EC, se maneja un máximo para el número de prefijos
recibidos por sesión.  
Si el proveedor desea configurar un máximo para el número de prefijos
recibidos desde NAP.EC, este número máximo deberá ser consultado y
coordinado con la administración de NAP.EC.	



Políticas para intercambio de tráfico (peering policies) 	[
http://www.aeprovi.org.ec/index2.php?option=com_content&do_pdf=1&id=269 ]
[Image] 	[
http://www.aeprovi.org.ec/index2.php?option=com_content&task=view&id=269&pop=1&page=0&Itemid=105
] [Image] 	[
http://www.aeprovi.org.ec/index2.php?option=com_content&task=emailform&id=269&itemid=105
] [Image] 


	 El intercambio de tráfico en NAP.EC es multilateral obligatorio, es
decir, cada proveedor conectado intercambia tráfico con todos los demás
participantes.  	
>
>
>Aunque la parte de gobernanza está orientada a puntos de intercambio 
>constituidos como una organización neutral e independiente, el resto de 
>elementos son válidos para cualquier otra tipo de constitución véase 
>comercial, gubernamental, universitaria u otra.
>
>
>En cualquier caso, estos documentos son generalmente de dominio público 
>por lo que podéis encontrarlos en las páginas de los IXP a través de 
>nuestro directorio http://www.pch.net/ixpdir/
>
>Saludos,
>Gaël



Salu2,

Javier Galvez Funes
Asesor en Internet MegaLink
Siempre cuenta con nosotros!!!
212-9000 Ext: 110 CEL: +(591)-715-22149

"Las gentes que nunca hacen mas de lo que se les paga,
nunca obtienen pago por mas de lo que hacen".

Vamos ROWAN yo se que TU puedes!!! Usa tus "R. I."




More information about the Napla mailing list