[ITNOG] IX "cross metro" e remote peering

Lun 11 Maggio 2020 09:36:31 CEST

Ciao a tutti,
per integrare il quadro.

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:
> quindi deve esserci uno switch remoto gestito 
> esattamente come quelli locali

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.
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, unico, abbia il totale controllo dell’infrastruttura di switching.
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.

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).
Ma l’infrastruttura è integralmente gestita da MIX.

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).

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.

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.

My 2 cents,
Buona settimana 
Valeria

> On 11 May 2020, at 00:11, Luca Cicchelli <luca.cicchelli@top-ix.org> wrote:
> 
> 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). 
> Entrambi i punti dell'oggetto sono già compresi nello Statuto del Consorzio (lo trovate al fondo della pagina https://www.top-ix.org/it/consorzio/ <https://www.top-ix.org/it/consorzio/>) risalente al 2002 in cui, si stabilisce tra gli scopi sociali "......realizzare e gestire uno o più 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.....".
> 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.
> 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.
> 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.
> --
> Luca
> 
> 
> Il giorno dom 10 mag 2020 alle ore 19:12 Marco d'Itri <md@linux.it <mailto:md@linux.it>> ha scritto:
> On May 08, Giorgio Bonfiglio via itnog <itnog@lists.itnog.it <mailto:itnog@lists.itnog.it>> wrote:
> 
> > Un punto di vista utile che ci manca è quello di un IX che avesse deciso 
> > di espandersi fuori dalla metro principale di presenza, e di come siano 
> > state considerate le complessità che ne derivano (sviluppo di bacini 
> > secondari, vicinanza con altri IX e simili).
> Visto che non arrivano commenti, fornisco il punto di vista di un IX 
> (MINAP) che negli anni lo ha sempre evitato accuratamente, nonostante 
> diverse offerte per farlo.
> 
> Parto dal presupposto che non si possa violare la regole di un MAC 
> address per porta, quindi deve esserci uno switch remoto gestito 
> esattamente come quelli locali.
> 
> Non mi sono mai piaciuti i possibili rischi del fare passare il traffico 
> dell'IX su un trasporto L2 di terzi.
> Ricordo che più di una volta un importante IX nazionale, :-) prima che 
> iniziasse a filtrare per davvero le porte dei clienti, ha avuto guasti 
> causati dalla riflessione di frame da parte di circuiti di 
> remotizzazione di clienti . Visto che non è pratico filtrare le porte di 
> interconnessione interna, per quanto mi riguarda quindi questo design 
> è irricevibile.
> 
> Quali sono i benefici rispetto a una architettura di reseller con 
> funzione di aggregatori? Risparmiare uno switch?
> 
> Potrebbe cambiare qualcosa passando a una architettura basata su EVPN?
> 
> Aggiungo anche che, secondo la mia esperienza, due circuiti di due 
> carrier differenti su percorsi diversificati su una tratta tipo 
> Milano-Roma si rompono contemporaneamente circa ogni due anni.
> 
> -- 
> ciao,
> Marco
> 
> -- 
> Mailing list info: http://lists.itnog.it/listinfo/itnog <http://lists.itnog.it/listinfo/itnog>
> 
> -- 
> Mailing list info: http://lists.itnog.it/listinfo/itnog

-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.itnog.it/pipermail/itnog/attachments/20200511/04c130b2/attachment.htm>