Segment Routing: Parte I - Teoria

Circa un anno fa ho avuto un breve colloquio con un giovane leone Cisco, molto bravo, che era di passaggio nella nostra sede per rinnovare la sua certificazione CCIE. Dopo l'esame ci siamo fatti una chiacchierata sul più e meno e lui con entusiasmo mi parlò del Segment Routing, che secondo lui sarebbe stata una rivoluzione al pari dell'introduzione dello Spanning Tree nelle reti Switched Ethernet. 

Ahi ahi ahi, gli dissi, qua partiamo male, molto male. Tutti voi ormai sapete cosa penso dello Spanning Tree e più in generale delle reti Switched Ethernet, per cui sentire paragonare il Segment Routing allo Spanning Tree in termini di impatto sulle reti, mi ha fatto drizzare i capelli. Devo dire che a quel tempo non avevo ancora approfondito l'argomento Segment Routing, per cui mi limitai solo a stroncare lo Spanning Tree. 

Nel frattempo ho "studiato" l'argomento ed è giunto il momento di condividere con gli affezionati lettori di questo umile blog, un po' di conoscenza che ho acquisito su questo nuovo paradigma. Concettualmente l'idea è semplice ma intelligente, è una riedizione in chiave moderna del vecchio e arci-noto Source Routing, descritto nella celebre RFC 791 scritta da Jon Postel. Sull'impatto che avrà sulle reti sono ancora un po' dubbioso, ma mi son detto che è giusto parlarne, anche perché, come avrò modo di dire, il Segment Routing ha bisogno di un qualche controllore centralizzato (leggi: controller SDN), per sfruttarne a pieno le sue potenzialità.

Il Segment Routing (SR) è anche noto con l'acronimo SPRING (Source Packet Routing In NetworkinG), ma per brevità lo indicherò da qui in poi con il semplice acronimo SR, che è anche l'acronimo che troverete in quasi tutti i documenti ufficiali IETF. Il suo processo di standardizzazione è ancora in corso e molti sono i draft IETF che ne definiscono i vari aspetti. Piuttosto che darvi l'elenco, vi rimando a questo link, dove potete trovare ulteriori link aggiornati verso tutti i documenti draft IETF sull'argomento.

SR si integra perfettamente con il protocollo PCEP trattato ampiamente in questo post. Può utilizzare sul piano dati sia MPLS che IPv6, anche se ho dei dubbi sulla utilità di utilizzare IPv6. Per cui in questo post mi limiterò a trattare, per il piano dati, il solo utilizzo di MPLS. E quindi prima di addentrarmi nella "teoria", voglio fare un breve richiamo concettuale sul ruolo di MPLS nelle grandi reti, solo alcune cose che tutti voi conoscete perfettamente, ma che voglio raccontarvi da una prospettiva diversa, così da rendere più semplice il passaggio a SR.

AMARCORD ... IL RUOLO DI MPLS NELLE RETI IP

Su MPLS si sa ormai tutto. E' sulla scena da quasi 20 anni e sono poche le reti IP che non lo utilizzano. Ma cosa ha decretato il successo di MPLS, che in fondo ha portato nelle reti IP l'idea arcinota della Commutazione di Etichetta, ampiamente nota ed adottata in altri standard come Frame Relay e ATM (e prima ancora nel preistorico X.25) ?

Non fatevi fuorviare da balle varie, il vero e solo motivo per cui oggi si utilizza MPLS è perché tramite di esso è possibile fornire nuovi servizi, tra cui il più celebre e gettonato è senza dubbio il servizio L3VPN (soprattutto unicast, ma anche multicast). Oltre al servizio L3VPN, vi ricordo i servizi L2VPN, nelle versioni punto-punto (VPWS, Virtual Private Wire Service) e multipunto-multipunto (VPLS,  Virtual Private LAN Service, e la sua evoluzione EVPN, Ethernet VPN), i servizi di trasporto IPv6 (6PE, 6VPE), il Traffic Engineering con i suoi servizi aggiuntivi di Fast ReRouting (Facility Backup e One-to-One Backup).

Tutti questi servizi hanno un denominatore comune, utilizzano sul piano dati più etichette MPLS. Queste etichette MPLS sono di due tipi:

• Una o più Transport Label, che sono etichette il cui compito è "guidare" il pacchetto da un router di ingresso verso un router di uscita. Queste etichette possono essere viste come delle "istruzioni" per i router di transito, per portare correttamente il pacchetto verso il router di uscita corretto. Nelle applicazioni classiche la Transport Label è una sola, o più di una in casi particolari. In SPRING invece, come vedremo, sono in generale più di una.
• Una Service Label, che è una etichetta a cui corrisponde un servizio. Questa etichetta può essere vista come una "istruzione" per il router di uscita della rete IP/MPLS, per eseguire una determinata operazione (esempio: fai un lookup sulla VRF X, manda il payload verso l'interfaccia Y, ecc.). 

Tutto è riassunto nella figura seguente. Si noti che il payload può essere qualsiasi cosa, di norma un pacchetto L3 (es. IPv4, IPv6), o L2 (es. celle ATM, trame Ethernet, ecc.). E questo è un altro dei punti di forza di MPLS: l'essere agnostico sul tipo di payload trasportato !

Le Transport e Service Label sono annunciate da protocolli diversi. Nelle applicazioni classiche le Transport Label sono annunciate da LDP, RSVP-TE o BGP-LU (BGP - Labelled Unicast, specificato nella RFC 3107). Le Service Label nella stragrande maggioranza dei casi vengono annunciate da estensioni multiprotocollo del BGP, solo in un caso (il servizio VPWS), vengono annunciate via sessioni LDP multi-hop.

Quanto fin qui detto non è assolutamente una novità per chi ha un minimo di dimestichezza con MPLS. Ma come ho detto sopra, lo scopo di questa sezione era quello di raccontarvi il ruolo di MPLS con un linguaggio che ritroveremo a breve, illustrando il funzionamento del SR.

SR: PRINCIPI FONDAMENTALI

SR è una modalità di routing, che quando utilizzata congiuntamente a un piano dati MPLS, può essere vista come un'alternativa sia a LDP che a RSVP-TE. Infatti, benché il piano dati utilizzi MPLS, nessuno dei due classici protocolli per la distribuzione delle etichette, LDP e RSVP-TE, è necessario per il suo funzionamento. Resta il fatto comunque, che SR può essere integrato sia con LDP che con RSVP-TE, ma il suo funzionamento intrinseco non ha bisogno di nessuno dei due protocolli.

Ma andiamo al dunque. L'idea base è semplice: aggiungere ai pacchetti che entrano in un dominio MPLS una Service Label e quindi una pila di Transport Label che consenta di instradare i pacchetti secondo certi desiderata.

E fin qui sembrerebbe tutto identico a quanto detto nella sezione precedente. Dove è la differenza quindi ? Bene, l'idea è che ogni Transport Label identifica un segmento della rete. Quindi il percorso end-to-end è costituito da una sequenza di segmenti "incollati" tra loro. Questi segmenti possono essere di vario tipo:

• Un semplice nodo della rete.
• Un link (o meglio, adiacenza del protocollo IGP, che deve essere necessariamente o IS-IS o OSPF).
• Un LSP costruito via LDP o RSVP-TE.
• Un link verso un altro AS.

Un segmento può essere pensato come una "istruzione", dove l'istruzione è rappresentata da una etichetta MPLS. A differenza però dal paradigma classico di MPLS, che prevede che le etichette siano locali al router (ossia, è solo il router che le genera che sa come utilizzarle), qui le etichette, o nel linguaggio SR i segmenti, possono essere sia locali che globali:

• Segmenti locali: il router che genera e annuncia un segmento locale è l'unico che installa la relativa etichetta nella LFIB (e questo coincide esattamente con il paradigma classico di MPLS).
• Segmenti globali: ogni router del dominio MPLS assegna una etichetta (locale) a un segmento (globale) e tutti gli altri router installano l'etichetta nella propria LFIB.

Dite la verità, sembra un po' oscuro, no ? E' ora quindi di fare qualche esempio, necessario per capire "come funziona la baracca". Supponiamo, con la rete della figura seguente, di voler costruire un percorso, che a partire da PE1, passi per P3, utilizzi il link P3-P4, e quindi termini su PE2. Per chi di voi fosse familiare con il protocollo RSVP-TE (o anche con il classico source routing IP !), i nodi P3 e PE2 sono di tipo loose, mentre il nodo P4 è un nodo strict.

Il percorso è quindi costituito da tre segmenti, a ciascuno dei quali corrisponde una etichetta MPLS (riportata tra parentesi):

• Il nodo P3 (L = 103).
• Il link P3-P4 (L = 234).
• Il nodo PE2 (L = 302).

Da dove vengono fuori queste etichette lo vedremo nella prossima sezione. Ora, supponiamo che al router PE1 arrivi un pacchetto da inoltrare su questo percorso. PE1 aggiunge al pacchetto tre etichette MPLS, rispettivamente 103 (etichetta esterna), 234 e 302. Poi PE1, se necessario, potrebbe aggiungere una ulteriore Service Label, che nella figura seguente è indicata genericamente con SL. La pila (ordinata) di etichette complessiva che ne risulta è quindi la seguente (dalla più esterna alla più interna): [103, 234, 302, SL]. La sequenza delle operazioni che conduce questo pacchetto a destinazione è la seguente:

1. Il pacchetto viene instradato da PE1 a P3. L' "istruzione" per questa operazione PE1 la deduce dalla prima etichetta (= 103), che identifica il nodo P3. Poiché PE1 ha più percorsi per raggiungere P3, il pacchetto segue il percorso ottimo IGP. Qualora esistessero più percorsi ECMP (Equal Cost MultiPath), il traffico verrebbe bilanciato sui percorsi ECMP disponibili. Supponiamo che il percorso IGP sia PE1-P1-P2-P3.
2. Il pacchetto viene inviato a P1 (= IGP Next-Hop verso P3) con la stessa identica pila di etichette. Il pacchetto viene quindi instradato da P1 a P2 (= IGP Next-Hop verso P3). L' "istruzione" per questa operazione P1 la deduce sempre dalla prima etichetta (= 103), che identifica il nodo P3 e che rimane invariata (questa operazione viene denominata CONTINUE, nel draft IETF draft-ietf-spring-segment-routing).
3. P2, che è il penultimo nodo del percorso prima di P3, esegue il classico Penultimate Hop popping (in seguito vedremo il trucco utilizzato), e quindi pacchetto arriva a P3 con tre etichette: [234, 302, SL] (questa operazione viene denominata NEXT, nel draft IETF citato nel punto precedente draft-ietf-spring-segment-routing).
4. P3 inoltra quindi il pacchetto sul link P3-P4. L' "istruzione" per questa operazione P3 la deduce dalla prima etichetta (= 234), che identifica il link P3-P4. Prima di inoltrare il pacchetto sul link, P3 esegue una operazione di label pop e quindi inoltra il pacchetto verso il nodo P4. Il pacchetto quindi arriva a P4 con due etichette: [302, SL].
5. Il pacchetto viene infine instradato da P4 al nodo finale PE2. L' "istruzione" per questa operazione P4 la deduce dalla prima etichetta (= 302), che identifica il nodo PE2. Poiché P4 ha più percorsi per raggiungere PE2, il pacchetto segue il percorso ottimo IGP (eventualmente bilanciando il traffico, nel caso di più percorsi ECMP disponibili).
6. Il penultimo nodo del percorso prima di PE2, esegue il classico Penultimate Hop Popping (PHP), e quindi pacchetto arriva a PE2 con la sola Service Label SL.

Il tutto è riassunto nella figura seguente.

L'esempio appena descritto mette bene in evidenza la differenza tra segmenti globali e segmenti locali. 

Illustrerò dapprima il caso di segmenti globali. Se ci fate caso , i nodi P3 e PE2 sono identificati "globalmente" rispettivamente dalle etichette 103 e 302. In realtà quello che accade quando si abilita il SR, è che ciascun nodo associa localmente a se stesso una etichetta MPLS, che comunica in qualche modo a tutti gli altri nodi. Questa è etichetta è quindi globale per tutto il dominio MPLS. Nell'esempio della figura, i nodi P3 e PE2 allocano localmente a loro stessi rispettivamente le etichette 103 e 302 e le comunicano agli altri nodi (in quale modo, sarà oggetto della sezione "Distribuzione delle Etichette"). Queste etichette saranno utilizzate per veicolare traffico verso il nodo.

Un aspetto particolare di SR, diverso dal paradigma classico del forwarding MPLS, è che per inviare traffico verso un particolare nodo si utilizza sempre la stessa etichetta globale annunciata al dominio MPLS da quel nodo. Anche qui, un esempio aiuta a chiarire questo aspetto. Si consideri la figura seguente, dove è evidenziato il solo percorso ottimo IGP tra due nodi PE1 e PE2. Nella figura sono evidenziate le etichette "globali" scelte localmente dai vari router (NOTA: non vi fate confondere da questa commistione di termini "locale" e "globale" per le stesse etichette. Ogni etichetta è generata localmente da ciascun router, ma è gestita globalmente !). 

Ora, supponiamo che da PE1 si voglia inviare un determinato payload a PE2. Poiché PE2 ha allocato localmente per l'utilizzo globale l'etichetta 102, la pila di etichette sarà sempre costituita, con l'eccezione dell'ultimo tratto (link P3-PE2), dalla coppia [102, SL]. Solo sull'ultimo tratto, a causa del PHP, il pacchetto viaggia con la sola service label SL. E questo significa utilizzare globalmente l'etichetta 102.

Allo steso modo, se il pacchetto avesse avuto come destinazione il router P3, avrebbe viaggiato, a parte l'ultimo link, sempre con la pila di etichette [133, SL]. E così via. 

Il lettore attento avrà certamente notato che questo modo di procedere genera però un problema non secondario, e cioè che ciascun router deve generare etichette diverse. Non è possibile (ovviamente !) che due router allochino per loro stessi la stessa etichetta globale ! Vedremo in una delle prossime sezioni come risolvere questo problema.

Veniamo ora ai segmenti locali. Nel primo esempio sopra, il secondo segmento (link P3-P4) ha associata l'etichetta MPLS 234. Questa etichetta viene allocata localmente da P3, associata al link P3-P4, e annunciata agli altri nodi. La differenza tra questa etichetta e quelle globali appena viste è che l'utilizzo di questa etichetta è solo locale, ossia solo il router che la annuncia avrà nella sua LFIB una riga relativa e questa etichetta. Gli altri router ne conosceranno il valore ma non la installeranno nella propria LFIB. Quindi solo il nodo P3 potrà ricevere pacchetti con quella determinata etichetta. Al pari del paradigma classico di MPLS, essendo l'uso dell'etichetta solo locale, è consentito l'utilizzo locale della stessa etichetta da parte degli altri nodi.  

Anche qui, un esempio aiuta a chiarire ogni dubbio. Si consideri di nuovo l'esempio precedente, dove è evidenziato il solo percorso ottimo IGP tra due nodi PE1 e PE2. Supponiamo che ciascun router allochi localmente una etichetta MPLS al link adiacente nella direzione da sinistra a destra. Le etichette siano le seguenti: 511 (link PE1-P1), 501 (link P1-P2), 501 (link P2-P3), 503 (link P3-PE2). Il payload entrante in PE1 e diretto a PE2 avrà in ingresso la pila di etichette [511, 501, 501, 503, SL]. Ogni volta che il pacchetto con pila di etichette arriva a un nodo, questo esegue una operazione di label pop e instrada il pacchetto sull'interfaccia uscente corrispondente all'etichetta entrante. Il tutto è riassunto nella figura seguente.

Riassumendo ...

• SR vede un percorso come un insieme di segmenti, locali o globali. Un percorso end-to-end è costituito da una sequenza di segmenti.
• A ciascun segmento è associata una etichetta MPLS (NOTA: ricordo che in questo post considero solo un piano dati basato su MPLS. E' possibile, in alternativa, un piano dati basato su IPv6). 
• A ciascun pacchetto che entra nel dominio SR, viene aggiunta una pila di etichette, che determina il percorso che il pacchetto seguirà fino alla destinazione, ossia fino al nodo di uscita del dominio SR. La determinazione del percorso e quindi la pila di etichette da aggiungere sul nodo di ingresso, è al di fuori degli scopi di SR.

L'ultimo punto è l'aspetto che assomiglia al classico source routing IP. Si noti che per seguire un determinato percorso non è necessario alcun tipo di segnalazione, come ad esempio avviene con i percorsi (LSP) MPLS realizzati via RSVP-TE. E inoltre non è necessario il mantenimento di alcuno stato nei nodi intermedi: SR è completamente stateless (lo stato è nei pacchetti, non nei router !).

ALLOCAZIONE E DISTRIBUZIONE DELLE ETICHETTE
Un aspetto chiave di MPLS "classico" è l'allocazione e la distribuzione delle etichette associate alle varie FEC (Forwarding Equivalence Class). Per l'allocazione, lo standard lascia una certa libertà, avendo le etichette significato locale. Per la distribuzione invece, come noto, MPLS utilizza due protocolli, LDP e RSVP-TE, in funzione del tipo di LSP: LDP per LSP Hop-by-Hop e RSVP-TE per LSP Explicitly Routed. 

Il paradigma SR utilizza invece strategie diverse. Innanzitutto, l'allocazione delle etichette associate ai segmenti globali è vincolata all'univocità su tutto il dominio SR, ossia, due qualsiasi segmenti globali devono necessariamente avere etichette diverse. Per i segmenti locali invece la strategia è simile a MPLS classico.

Per semplicità in questo post considererò solo due tipi di segmenti, che poi sono quelli più interessanti nelle applicazioni pratiche e che ho utilizzato negli esempi sopra:

• IGP-node: sono segmenti globali che identificano un nodo della rete. Sono un caso particolare di segmenti più generali (IGP-prefix), associati a un particolare prefisso, tipicamente una interfaccia di Loopback del nodo. 
• IGP-adjacency: sono segmenti locali che identificano un'adiacenza IGP unidirezionale, o anche un insieme di adiacenze.

Per rispettare il vincolo di univocità delle etichette associate ai segmenti globali di tipo IGP-node, SR utilizza l'artificio dei "blocchi di etichette globali" (SRGB, Segment Routing Global Block). Ogni nodo alloca localmente un blocco di etichette per l'utilizzo globale. Sarebbe "cosa buona e giusta" che tutti i nodi utilizzassero lo stesso identico blocco, le procedure di configurazione e troubleshooting ne trarrebbero notevole vantaggio. Così, ipotizzerò da qui in avanti che tutti i nodi utilizzino lo stesso identico SRGB (NOTA: nel caso di nodi di vendor diversi probabilmente non è così, anche se pare si vada convergendo verso la scelta di un SRGB condiviso. Comunque vi sono comandi di configurazione che consentono di scegliere il SGRB, e questo è molto importante nel caso di interlavoro tra router di vendor diversi). Nel prossimo post illustrerò un test di laboratorio, per verificare cosa accade nel caso di interlavoro Cisco-Juniper.

Un SRGB è identificato da due parametri: base e ampiezza. La base rappresenta la prima etichetta, l'ampiezza il numero di etichette allocabili. Ad esempio, se base = 16.000 e ampiezza = 8.000, le etichette allocabili globalmente sono tutte quelle appartenenti all'intervallo [16.000, 23.999]. L'artificio utilizzato per garantire l'univocità è il seguente: per ciascun nodo si definisce via configurazione, un valore denominato Node-SID (SR ID del nodo), e quindi l'etichetta associata al nodo viene automaticamente presa pari a "base + Node-SID". Ad esempio, supponendo che la base del SRGB sia 16.000 e che a un nodo venga assegnato Node-SID = 20, l'etichetta MPLS globale assegnata al nodo è 16.000 + 20 = 16.020. Va da se che i Node-SID assegnati devono essere diversi da nodo a nodo. Per evitare errori di configurazione, sono allo studio metodi automatici di assegnazione, vedi ad esempio questo draft IETF.  

Per i segmenti locali, come ad esempio quelli del tipo IGP-adjacency, non serve alcun accorgimento particolare, se non quello di non "invadere il campo" delle etichette globali. In altre parole, le etichette associate ai segmenti del tipo IGP-adjacency, devono essere allocate in un intervallo a intersezione nulla con quello del SRGB.

Per chiudere il cerchio manca solo illustrare come avviene la distribuzione delle etichette. E qui il paradigma SR introduce una importante novità: la distribuzione delle etichette avviene attraverso una estensione dei protocolli IS-IS e OSPF. Quindi, niente più LDP, né RSVP-TE, quindi un protocollo in meno nella rete (o due). Resta il fatto comunque che i protocolli possono coesistere, se ritenuto opportuno. 

Non è scopo di questo post dare i dettagli di come sono strutturate queste estensioni. mi limiterò solo a illustrare qualche idea. Prendiamo il caso dell'annuncio dei segmenti di tipo IGP-node, che è il più interessante. In realtà ciò che viene annunciata non è l'etichetta in valore assoluto (anche se questa possibilità è prevista), ma i due parametri del SRGB (base e ampiezza) e il Node-SID. Nel caso di IS-IS queste informazioni sono codificate in nuovi moduli TLV, mentre nel caso di OSPF sono codificate in nuovi LSA opachi. Insieme ai parametri che consentono di determinare le etichette associate ai nodi, vengono inviate anche alcune flag, tra cui due sono particolarmente interessanti:

• flag P (no-PHP flag): se P = 0 il penultimo nodo del percorso esegue l'operazione di PHP, altrimenti no. E' possibile anche far eseguire l'operazione di Explicit-null label, ponendo a 1 sia la flag P che una seconda flag (flag E).
• flag N (Node-SID flag): se N = 1 il segmento coincide con un nodo.

A questo punto abbiamo (quasi) tutto, o almeno quello che è sufficiente per i nostri scopi. Altri dettagli nel prossimo post, dove illustrerò il tutto tramite un test di laboratorio.

LDP, RSVP-TE, SPRING : CONFRONTO
E così, dopo anni e anni che si parla di routing, di MPLS, ecc. , dopo anni di esperienza guadagnata sul campo in reti di qualsiasi dimensione, qualcuno ha sentito il bisogno di introdurre un nuovo paradigma. SR, come ampiamente visto in questo post, altro non è che un nuovo modo di realizzare LSP MPLS (per ora P2P e MP2P). 

E siamo a tre: LDP, RSVP-TE e SR. E quindi mi sembra logico chiudere questo post con una tabella di confronto tra questi tre metodi. Il confronto è riportato nelle tabella seguente.

Gli ultimi due aspetti sono molto interessanti. L'utilizzo di etichette deterministiche, ossia assegnate (semi-)manualmente offre maggiore stabilità del piano di forwarding e troubleshooting più semplice. 

La possibilità di integrazione con SDN, già ampiamente vista nel post precedente, insieme alla sua semplicità, ne fanno un candidato naturale come sostituto di RSVP-TE nelle grandi reti. Anche se a dire il vero RSVP-TE offre una gamma più vasta di specifica dei vincoli, che SR non ha (es. definizione di priorità, prenotazione di banda, classi amministrative, ecc.). Ma l'integrazione con un controller centralizzato SDN, consente di ovviare a questi inconvenienti. 

SR poi, in confronto a RSVP-TE è molto più scalabile e richiede il mantenimento nella LFIB di un numero minore di etichette. Ad esempio, nel caso di una maglia completa di LSP MPLS, su un router P il numero etichette (e più in generale stati) cresce in ragione quadratica con il numero di nodi (per l'esattezza, se N è il numero di nodi, il numero di etichette da mantenere è N*(N-1)). Nel caso di SR, il numero di etichette da mantenere cresce invece linearmente (per l'esattezza, se N è il numero di nodi e A il numero delle adiacenze del nodo, il numero di etichette da mantenere è N+A).

Infine non va trascurato il vantaggio dell'eliminazione di un protocollo. SR infatti non richiede per il suo funzionamento né LDP né RSVP-TE. Un protocollo in meno significa meno probabilità di incappare in bug software, maggiore semplicità di configurazione e soprattutto, maggiore facilità di troubleshooting (a dire il vero su questo punto mi sono sempre chiesto perché invece di LDP, non utilizzare MPLS-over-IP o MPLS-over-GRE ? Tutto standardizzato nella RFC 4023 - Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE), Marzo 2005. Misteri del Networking, o UCCS (Ufficio Complicazioni Cose Semplici) al lavoro ?).

CONCLUSIONI
Con questo post ho iniziato un lungo cammino su un argomento, il Segment Routing, la cui effettiva utilità è per me ancora un po' dubbia, ma di cui in seguito sentirete certamente parlare, anche se certamente non raggiungerà la "fama" di altri termini di moda come cloud, SDN, NFV, OpenFlow, ecc. . 

L'idea mi piace molto, il Segment Routing ha i suoi indubbi vantaggi sia in termini di semplicità che di scalabilità, e si integra perfettamente con il nuovo verbo del Software Defined Networking (SDN). Per questo continuerò a svilupparla con post futuri. Nel prossimo ad esempio, illustrerò dei test di laboratorio. Poi, è una tecnologia che seppur non ancora consolidata in una RFC ufficiale, è già supportata da tutti i principali vendor (Cisco, Juniper, ALU-Nokia, Huawei).

Ma sarà questo sufficiente per far si che gli ISP lo utilizzino nella loro rete in luogo di LDP e/o RSVP-TE ? Ho fatto una piccola indagine su tre grandi ISP Italiani e il Dipartimento di Ingegneria di una grande rete Enterprise: risultato, di eventuali piani di implementazione a breve non se ne parla, forse chissà, magari a medio-lungo termine se ne potrà discutere. Se qualche lettore avesse informazioni diverse in merito, mi farebbe piacere se mi contattasse (tiziano.tofoni@ssgrr.com). 

Se volete saperne di più su MPLS, da zero all'infinito, oppure avete bisogno di ulteriori approfondimenti, seguite i nostri molti corsi sull'argomento, tra cui vi segnalo: 

• IPN272: MPLS: dalla teoria alla Pratica
• IPN273: MPLS: aspetti avanzati
• IPN276: MPLS nell’IOS XR Cisco
• IPN258: MPLS nel JunOS Juniper

E se volete un qualcosa di molto più completo, seguite l'intero percorso per la certificazione Cisco CCNP - SP (CCNP - Service Provider).