<div dir="ltr"><div>Visto che ho favorito la creazione del thread a seguito di alcune 
specifiche domande di Giorgio, contribuisco sinteticamente  per quanto 
riguarda TOP-IX: una presentazione più accurata potrebbe essere fatta in
 occasione del prossimo ITNOG (speriamo che le condizioni ci permettano 
di farlo presto). <br></div><div>Entrambi i punti dell'oggetto sono già compresi nello Statuto del Consorzio (lo trovate al fondo della pagina <a href="https://www.top-ix.org/it/consorzio/" target="_blank">https://www.top-ix.org/it/consorzio/</a>)
 risalente al 2002 in cui, si stabilisce tra gli scopi sociali 
"......realizzare e gestire uno o più siti dove gli operatori Internet 
possano scambiare traffico "Internet Protocol (IP)....." e 
"......promuovere   accordi   con   altri   NAP   o   "exchange-point"  
 per   fornire ulteriori  servizi  di  "peering"  agli  aderenti  al 
 Consorzio.....".</div><div>La prima frase sottintende il fatto che da 
subito TOP-IX aveva infrastuttura distribuita con due locations in area 
metro a Torino, la seconda la possibilità di giungere ad accordi come 
quello fatto successivamente con VS-IX e altri.</div><div>Nel 2005 la 
copertura geografica ha raggiunto anche Milano grazie ad una 
infrastruttura DWDM co-gestita assieme a CSI Piemonte nell'ambito di un 
Programma Regionale (cioè supportato dalla Regione Piemonte) di sviluppo
 della connettività in Piemonte. La presenza milanese, inizialmente 
motivata dalla chiusura dell'anello DWDM, è stata poi utilizzata  per 
intercettare i fornitori di contenuti e servizi che ovviamente, quando 
arrivano in Italia, mettono piede a Milano come primo punto di presenza 
sul territorio. Rispetto alle condizioni iniziali alcune cose sono 
cambiate, compreso il fatto che una maggiore delocalizzazione rispetto 
al campus  di Via Caldera (a livello di area metro a Milano ma anche 
nazionale) può contribuire ad una maggiore efficienza e affidabilità di 
Internet in Italia.<br></div><div>Per quanto riguarda il remote peering 
TOP-IX ha agito prima con accordi di collaborazione con altri IXP 
(Lyonix, VS-IX e France-IX) che sono nati con motivazioni differenti. 
Successivamente è stato implementato il remote peering attraverso 
reseller partner. Anche su questo punto, rispetto alle condizioni 
iniziali, molte cose sono cambiate compreso il fatto che la latenza 
comincia ad avere sempre maggiore importanza e che molti ISP italiani 
hanno sviluppato la loro infrastruttura rendendo meno interessate il 
remote peering. Per la "long tail", ovvero i piccoli ISP, rimane 
comunque un elemento da prendere in considerazione.</div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>--</div><div>Luca<br></div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Il giorno dom 10 mag 2020 alle ore 19:12 Marco d'Itri <<a href="mailto:md@linux.it">md@linux.it</a>> ha scritto:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On May 08, Giorgio Bonfiglio via itnog <<a href="mailto:itnog@lists.itnog.it" target="_blank">itnog@lists.itnog.it</a>> wrote:<br>
<br>
> Un punto di vista utile che ci manca è quello di un IX che avesse deciso <br>
> di espandersi fuori dalla metro principale di presenza, e di come siano <br>
> state considerate le complessità che ne derivano (sviluppo di bacini <br>
> secondari, vicinanza con altri IX e simili).<br>
Visto che non arrivano commenti, fornisco il punto di vista di un IX <br>
(MINAP) che negli anni lo ha sempre evitato accuratamente, nonostante <br>
diverse offerte per farlo.<br>
<br>
Parto dal presupposto che non si possa violare la regole di un MAC <br>
address per porta, quindi deve esserci uno switch remoto gestito <br>
esattamente come quelli locali.<br>
<br>
Non mi sono mai piaciuti i possibili rischi del fare passare il traffico <br>
dell'IX su un trasporto L2 di terzi.<br>
Ricordo che più di una volta un importante IX nazionale, :-) prima che <br>
iniziasse a filtrare per davvero le porte dei clienti, ha avuto guasti <br>
causati dalla riflessione di frame da parte di circuiti di <br>
remotizzazione di clienti . Visto che non è pratico filtrare le porte di <br>
interconnessione interna, per quanto mi riguarda quindi questo design <br>
è irricevibile.<br>
<br>
Quali sono i benefici rispetto a una architettura di reseller con <br>
funzione di aggregatori? Risparmiare uno switch?<br>
<br>
Potrebbe cambiare qualcosa passando a una architettura basata su EVPN?<br>
<br>
Aggiungo anche che, secondo la mia esperienza, due circuiti di due <br>
carrier differenti su percorsi diversificati su una tratta tipo <br>
Milano-Roma si rompono contemporaneamente circa ogni due anni.<br>
<br>
-- <br>
ciao,<br>
Marco<br>
<br>
-- <br>
Mailing list info: <a href="http://lists.itnog.it/listinfo/itnog" rel="noreferrer" target="_blank">http://lists.itnog.it/listinfo/itnog</a><br>
</blockquote></div>