<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Ciao a tutti,<div class="">per integrare il quadro.</div><div class=""><br class=""></div><div class="">Credo che il punto centrale nell’implementazione di un IX (sempre) ed in particolare per un IX distribuito = IX remotizzato in uno o più punti (che lo sia a livello di campus che lo sia a livello geografico), sia quello evidenziato da Marco:</div><div class=""><blockquote type="cite" class=""><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;">quindi deve esserci uno switch remoto gestito <br class="">esattamente come quelli locali</blockquote></div></blockquote><div class=""><br class=""></div>La monogestione equivale alla possibilità di un totale controllo nei flussi, nella certezza della congruenza delle configurazioni e nella conseguente velocità e chiarezza nel gestire eventuali troubleshooting.</div><div class="">Se poi la distribuzione è realizzata tramite interconnessioni in fibra spenta (vedi MINAP, in un campus con “un tot “ di metri di fibra) o in DWDM (vedi Top-iX a livello geografico) è un don’t care matter: l’importante è che il gestore, <b class="">unico</b>, abbia il totale controllo dell’infrastruttura di switching.</div><div class="">Chiaro che interconnessioni in DWDM dipendono, sempre anche se non necessariamente, da terze parti, ma questo fa parte della catena operativa di ogni servizio di rete e, comunque, non influisce nelle logiche di gestione L2 delle piattaforme di switching, se appunto il disegno e l’implementazione sono coerenti.</div><div class=""><br class=""></div><div class="">MIX è da anni che da unico PoP è riuscito a distribuirsi (grazie finalmente alla nascita di siti carrier-independent una volta inesistenti) prima a livello metro, poi anche in Sicilia (OHM). Le interconnessioni a livello metro sono ad oggi integralmente gestite da MIX (fibra spenta e + c/d wdm), mentre ovviamente il PoP in OHM è interconnesso tramite “n” trasporti di terze parti (lambda).</div><div class="">Ma l’infrastruttura è integralmente gestita da MIX.</div><div class=""><br class=""></div><div class="">A questo si aggiunge il fatto che a MIX da praticamente sempre ad ogni porta equivale un MAC e filtri associati, e questo vale per tutti i Pop, anche per afferenti remotizzati su swicth di MIX, e anche per quelli che usufruiscono di servizi in partnership con altri operatori: reselling e pooling. Con questo approccio non rileviamo problemi nel mantenimento della piattaforma nel suo insieme e per altro ci consente di garantire che l’infrastruttura di interconnessione tra i PoP sia utilizzata a scopo di peering (eBGP in ogni sua forma :) ) e non, ad esempio, per essere utilizzata per altri scopi (iBGP o altro).</div><div class=""><br class=""></div><div class="">Eventuali utilizzi di altri protocolli (MPLS, eVPN ecc) sono, a mio parere, necessari prima di tutto in base al disegno topologico della piattaforma L2 di peering, e poi qualora sia renda necessario pararsi le spalle a causa di pericoli indotti da configurazioni che non hai sotto controllo e e che ti espongono a pericoli di funzionamento , cosa che nel caso di 2 IX interconnessi senza particolari accorgimenti potrebbe crearsi.</div><div class=""><br class=""></div><div class="">Infine, per quanto riguarda servizi di reselling, per MIX ma in generale per tutti gli IX sono servizi complementari: non è questione di risparmiare uno switch, ma di poter essere facilmente raggiungibile da qualsiasi punto uno si trovi a prescindere da dove sia il PoP di rete da collegarsi. Ma questi servizi nulla hanno a che vedere con piattaforme di peering distribuite, sono un’altra cosa sia concettualment che operativamente.</div><div class=""><br class=""></div><div class="">My 2 cents,</div><div class="">Buona settimana </div><div class="">Valeria</div><div class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 11 May 2020, at 00:11, Luca Cicchelli <<a href="mailto:luca.cicchelli@top-ix.org" class="">luca.cicchelli@top-ix.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="">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 class=""></div><div class="">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" class="">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 class="">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 class="">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 class=""></div><div class="">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 class=""><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr" class=""><div class="">--</div><div class="">Luca<br class=""></div></div></div></div><br class=""></div><br class=""><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" class="">md@linux.it</a>> ha scritto:<br class=""></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" class="">itnog@lists.itnog.it</a>> wrote:<br class="">
<br class="">
> Un punto di vista utile che ci manca è quello di un IX che avesse deciso <br class="">
> di espandersi fuori dalla metro principale di presenza, e di come siano <br class="">
> state considerate le complessità che ne derivano (sviluppo di bacini <br class="">
> secondari, vicinanza con altri IX e simili).<br class="">
Visto che non arrivano commenti, fornisco il punto di vista di un IX <br class="">
(MINAP) che negli anni lo ha sempre evitato accuratamente, nonostante <br class="">
diverse offerte per farlo.<br class="">
<br class="">
Parto dal presupposto che non si possa violare la regole di un MAC <br class="">
address per porta, quindi deve esserci uno switch remoto gestito <br class="">
esattamente come quelli locali.<br class="">
<br class="">
Non mi sono mai piaciuti i possibili rischi del fare passare il traffico <br class="">
dell'IX su un trasporto L2 di terzi.<br class="">
Ricordo che più di una volta un importante IX nazionale, :-) prima che <br class="">
iniziasse a filtrare per davvero le porte dei clienti, ha avuto guasti <br class="">
causati dalla riflessione di frame da parte di circuiti di <br class="">
remotizzazione di clienti . Visto che non è pratico filtrare le porte di <br class="">
interconnessione interna, per quanto mi riguarda quindi questo design <br class="">
è irricevibile.<br class="">
<br class="">
Quali sono i benefici rispetto a una architettura di reseller con <br class="">
funzione di aggregatori? Risparmiare uno switch?<br class="">
<br class="">
Potrebbe cambiare qualcosa passando a una architettura basata su EVPN?<br class="">
<br class="">
Aggiungo anche che, secondo la mia esperienza, due circuiti di due <br class="">
carrier differenti su percorsi diversificati su una tratta tipo <br class="">
Milano-Roma si rompono contemporaneamente circa ogni due anni.<br class="">
<br class="">
-- <br class="">
ciao,<br class="">
Marco<br class="">
<br class="">
-- <br class="">
Mailing list info: <a href="http://lists.itnog.it/listinfo/itnog" rel="noreferrer" target="_blank" class="">http://lists.itnog.it/listinfo/itnog</a><br class="">
</blockquote></div>
<br class="">-- <br class="">Mailing list info: <a href="http://lists.itnog.it/listinfo/itnog" class="">http://lists.itnog.it/listinfo/itnog</a><br class=""></div></blockquote></div><br class=""></div></body></html>