Mappatura da etichetta a percorso, scalabilità di generazione di etichette

Nei router abilitati MPLS, viene generata un'etichetta univoca per prefisso di destinazione nella tabella di routing o per l'hop successivo nella tabella di routing se non entrambi, come è il mapping tra etichette univoche e voce della tabella di routing? Inoltre, se è per prefisso di destinazione, quanto è scaricabile? Secondo la mia comprensione, il valore massimo dell'etichetta è 2 ^ 20 = 1048576. Cosa succede se il numero di voci della tabella di routing è maggiore di 1048576?

— Hemanth
fonte

Stai seriamente suggerendo di guardare uno scenario in cui qualcuno si sta avvicinando a 1 milione di voci LFIB o è una domanda teorica?

— Mike Pennington,

Attualmente lavoro con L3, ho visto scenari di clienti avvicinarsi a 1 milione di rotte (rotte Internet complete) nei router Edge. Non ha attraversato quel numero. Ma ho visto il numero totale di voci vicino a mezzo milione.

— Hemanth,

quante rotte IGP + etichette RSVP-TE? È un cattivo design associare un'etichetta a ogni percorso Internet. Dovresti associare le etichette a tutti i salti successivi BGP nella tabella IGP.

— Mike Pennington,

Legare un'etichetta per Nexthop BGP ha senso. Ma la MPLS non ha linee guida comuni per la generazione di etichette? Non esiste una regola comune secondo la quale dovrebbe essere generata un'etichetta univoca per prefisso di destinazione o per nexthop? o è solo implementazione specifica?

— Hemanth,

Qualche risposta ti è stata d'aiuto? in tal caso, dovresti accettare la risposta in modo che la domanda non continui a comparire per sempre, cercando una risposta. In alternativa, potresti fornire e accettare la tua risposta.

— Ron Maupin

Risposte:

è un'etichetta univoca generata per prefisso di destinazione nella tabella di routing o per hop successivo nella tabella di routing? ... ho visto scenari di clienti avvicinarsi a 1 milione di percorsi ... Ma MPLS non ha linee guida comuni per la generazione di etichette? Non esiste una regola comune secondo la quale dovrebbe essere generata un'etichetta univoca per prefisso di destinazione o per nexthop? o è solo implementazione specifica?

Sembra esserci un po 'di confusione. È piuttosto improbabile che qualcuno voglia mai allocare un'etichetta univoca per ciascuna rotta Internet. Una rete MPLS ben progettata dovrebbe allocare etichette basate sui prefissi IGP che sono vincolati al tuo prossimo hop di BGP (rif RFC 3031, Sezione 4.6 ).

Pertanto, non sono sicuro che 1 milione di etichette nella LFIB rappresentino oggi un serio vincolo di progettazione MPLS.

— Mike Pennington
fonte

Come da rfc3031 sezione 4.6, tutti i router core assegneranno lables per i prefissi igp. Ma BGP assegnerà un'etichetta univoca per ogni rotta (route BGp) che invia al peer BGP. Ma anche qui BGP può pubblicizzare migliaia di rotte, giusto? Cosa succederà se il numero di percorsi BGP supera 2 ^ 20?

— Hemanth,

@Saran hai ragione, è concepibile esaurire le etichette in tale scenario (come RFC4364, opzione b). Ciò che accadrebbe è che non è possibile pubblicizzare alcun NLRI che richiede una nuova etichetta. Penso che sia piuttosto improbabile e tecnicamente fintanto che il PE remoto ha lo stesso hop successivo, per il prefisso, potresti condividere l'etichetta. Poiché opt-B deve comprimere tutta l'IGP, l'etichetta VPN in un'etichetta singola, è un po 'più facile immaginare uno scenario in cui ciò potrebbe accadere, ma non mi sembra molto probabile.

— ytti,

@Saran, nello scenario che hai menzionato, ovvero la VPN MPLS inter-AS . Il routing BGP semplice che sembra porre nella domanda originale non alloca le etichette per le rotte BGP per impostazione predefinita. Qualunque scenario MPLS VPN potrebbe presumibilmente esaurire le etichette distribuite da VPNv4; a quel punto è necessario segmentare la base clienti su router separati se non si esegue AS.

— Mike Pennington,

L'opzione C si ridimensiona come il normale MPLS, in quanto è normale stack [IGP, VPN]. Tuttavia, l'opzione B è solo [etichetta], che alla fine deve mappare in ASBR a [IGP, VPN]. Quindi, mentre in OptionC la parte VPN non deve essere unica per due PE, in OptionB ogni combinazione di [IGP, VPN] deve essere unica sul collegamento ASBR <-> ASBR.

— ytti,

@ytti - "Penso che sia piuttosto improbabile e tecnicamente fintanto che il PE remoto ha lo stesso hop successivo, per il prefisso, potresti condividere l'etichetta." Non esiste una regola rigida per cui un'etichetta debba essere generata per ogni PRefix (prefisso BGp)? Capisco perfettamente che è meglio condividere un'etichetta per più prefissi, se seguono lo stesso percorso per il passaggio. Ma la domanda è: come si decide? In che modo il router downstream saprà o deciderà quali percorsi condividere un'etichetta. È solo il Nexthop? se più percorsi condividono lo stesso nexthop, verrà assegnata una sola etichetta?

— Hemanth,

L'esatto scenario pratico in cui le etichette potrebbero esaurirsi è discutibile. Ci sono anche alcuni problemi di pulizia domestica che non sono direttamente correlati all'esaurimento delle etichette, ma contribuiscono a tale effetto.

I gestori di etichette oggi nei principali fornitori (almeno CSCO, JNPR) sono programmati in modo da richiedere un blocco continuo per ogni applicazione di etichetta. Naturalmente questo potrebbe essere risolto, con qualche costo in termini di prestazioni e complessità, ma è sicuramente un altro problema da considerare.

Alcuni servizi MPLS sono piuttosto affamati di spazio etichetta nel core, il limite è per lo più irrilevante in quanto possiamo mascherarli sotto la nostra "etichetta IGP".
Dobbiamo ricordare che MPLS non riguarda solo l'IP, si tratta di FEC, se dobbiamo fornire un servizio di trattamento / percorso diverso nel core, abbiamo bisogno di un nuovo FEC.

Ci sono alcune discussioni sul supporto di mega etichette e grandi etichette , i loro casi d'uso , sebbene una più probabile implementazione avverrà tramite etichette per scopi speciali . Personalmente spero / mi aspetto che il formato del filo MPLS venga modificato prima che 2 ^ 20 diventi un problema. Poiché MPLS viene utilizzato principalmente all'interno di una sola rete di operatori, cambiare il formato del filo è semplicissimo rispetto alla migrazione IPv4-> IPV6, quindi qualsiasi problema incontreremo, risolverli sarà abbastanza semplice. Alcuni problemi che vorrei risolvere:

Capacità di conservare la cronologia delle etichette in transito
Overhead a basso byte (TTL, TC sono ridondanti in etichette sovrapposte)
Elimina la necessità di un payload MPLS P 'ducking-typing' di transito (interrompe ECMP oggi)
Estendibile in base alla progettazione (le etichette per scopi speciali introducono un enorme costo in byte)
Maggiore spazio per le etichette
Coesistenza con MPLSv1

— ytti
fonte