<div><br></div><div>Creo que lo mejor será premiar a los que comiencen a "aggregar" (cómo sería en español???)</div><div>Una beca al lacnog o al próximo lacnic puede ser suficiente incentivo. </div><div><br></div>
<div>Otro premio debe ir para los que empiecen a "ofrecer" comunidades para que sus clientes y peerings puedan hacer traffic engineering.</div><div><br></div><div>Tal vez podemos proponer un standard regional para valores de comunidad recomendados...</div>
<div><br></div><div>Christian</div><br>On Friday, December 16, 2011, Arturo Servin  wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">
<div><br></div><div><span style="white-space:pre-wrap"> </span>De hecho es bastante penoso que seamos la región con el índice más alto de desagregación:</div><div><br></div><div>LACNIC Deaggregation factor:                                   4.64</div>
<div><br></div><div><span style="white-space:pre-wrap"> </span>Muy, pero muy alto del promedio:</div><div><br></div><div> Deaggregation factor:                                          2.29</div><div><br></div><div><span style="white-space:pre-wrap">    </span></div>
<span style="white-space:pre-wrap">     </span><br><div><div>On 16 Dec 2011, at 11:38, Carlos M. Martinez wrote:</div><br><blockquote type="cite">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000">
    Gracias Christian!<br>
    <br>
    Personalmente yo también soy de la idea de que tendríamos que
    trabajar en bajar nuestros niveles de desagregación, ya que en
    definitiva nos estamos dañando entre nosotros. <br>
    <br>
    Y de paso podríamos dejar de tener como región una presencia
    importante aquí:<br>
    <br>
    >> <a href="http://www.cidr-report.org/as2.0/#Gains" target="_blank">http://www.cidr-report.org/as2.0/#Gains</a> <br>
    <br>
    :-)<br>
    <br>
    ¿Que podemos hacer para ayudar a la comunidad?<br></div></blockquote><div><br></div><div><br></div><div><span style="white-space:pre-wrap">     </span>Quizá un wall of shame en cada LACNOG?</div><div><br></div><div>=)</div>
<div><br></div><div><br></div><div><br></div><blockquote type="cite"><div bgcolor="#FFFFFF" text="#000000">
    <br>
    Carlos<br>
    <br>
    On 12/16/11 11:22 AM, Christian O'Flaherty wrote:
    <blockquote type="cite">Hola Carlos,
      <div><br>
      </div>
      <div>Van mis respuestas como ex-operador...<br>
        <div> </div>
        <blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
          <br>
          Hemos notado algunas cosas que nos llevan a hacer la siguiente<br>
          consulta: ¿Es común que quienes se conectan a puntos de
          intercambio de<br>
          tráfico desagreguen sus anuncios?<br>
        </blockquote>
        <div><br>
        </div>
        <div>Definitivamente. Desagregar suele ser una solución rápida y
          simple (aunque no sea prolijo) cuando los proveedores
          superiores no dan herramientas para modificar el localpref
          usando comunidades.</div>
        <div> </div>
        <blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Estamos
          viendo una cantidad importante de bloques /25 de IPv4<br>
          anunciados en nuestra región que no parecen ser detectados
          fuera de la<br>
          misma, por eso sospechamos de que se utilicen en contextos
          locales<br>
          (IXPs u otras formas de peering local).<br>
        </blockquote>
        <div><br>
        </div>
        <div>Algunos proveedores en la región dejan pasar cualquier
          tamaño de anuncio. Cuando eso pasa a los "grandes" se filtra
          por ser un bloque menor a /24. No ocurrirá solamente en los
          IXPs o peerings, tambien puede haber /25 en interconexiones de
          transit que el cliente desagrega porque tiene mas de un
          proveedor y no le dan comunidades para poder balancear
          correctamente.</div>
        <div> </div>
        <blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Es
          interesante notar que que muchos de esos /25s al dia de hoy
          serian<br>
          marcados como INVALID por routers que hicieran validación de
          origen,<br>
          ya que muchos de ellos estan cubiertos por ROAs que tienen
          maxLen de<br>
          /24 o incluso menores.<br>
        </blockquote>
        <div><br>
        </div>
        <div>Creo que es una buena razón para comenzar con una campaña a
          favor del uso de comunidades en los proveedores regionales. </div>
        <div> </div>
        <blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
          La pregunta mas de fondo que nos hacemos es si hay practicas<br>
          operativas de BGP en uso común al día de hoy que requieran<br>
          consideraciones especiales en el contexto de RPKI.<br>
        </blockquote>
        <div><br>
        </div>
        <div>Prefiero que dejemos de desagregar en la región en lugar de
          modificar el proceso en RPKI incluyendo excepciones. </div>
        <div> </div>
        <blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
          Un ejemplo de esto podria ser: "necesito generar algunos /25s
          que solo<br>
          sean validos para mis peers del IXP tal o cual, pero que para
          el resto<br>
          del mundo no lo sean"<br>
        </blockquote>
        <div><br>
        </div>
        <div>Hay algún caso donde sea necesario desagregar y no se pueda
          resolver de otra forma?</div>
        <div><br>
        </div>
        <div>Christian</div>
        <div> </div>
        <blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
          <br>
          --<br>
          --<br>
          =========================<br>
          Carlos M. Martinez-Cagnazzo<br>
          <a href="http://cagnazzo.name/" target="_blank">http://cagnazzo.name</a><br>
          =========================<br>
          _______________________________________________<br>
          LACNOG mailing list<br>
          <a>LACNOG@lacnic.net</a><br>
          <a href="https://mail.lacnic.net/mailman/listinfo/lacnog" target="_blank">https://mail.lacnic.net/mailman/listinfo/lacnog</a><br>
        </blockquote>
      </div>
      <br>
      <fieldset></fieldset>
      <br>
      <pre>_______________________________________________
LACNOG mailing list
<a>LACNOG@lacnic.net</a>
<a href="https://mail.lacnic.net/mailman/listinfo/lacnog" target="_blank">https://mail.lacnic.net/mailman/listinfo/lacnog</a>
</pre>
    </blockquote>
    <br>
    <br>
    <pre cols="72">-- 

--
Carlos M. Martinez
LACNIC R+D
<a href="http://www.labs.lacnic.net/" target="_blank">http://www.labs.lacnic.net</a></pre>
  </div>

_______________________________________________<br>LACNOG mailing list<br><a></a></blockquote></div><br></div></blockquote>