Appendix F. Implementation Recommendations (Raccomandazioni di implementazione)

Questa sezione presenta alcune raccomandazioni di implementazione.

Appendix F.1. Multiple Networks Per Message (Reti multiple per messaggio)

Il protocollo BGP consente di specificare più prefissi di indirizzo con gli stessi attributi di percorso in un unico messaggio. L'uso di questa capacità è altamente raccomandato. Con un prefisso di indirizzo per messaggio c'è un aumento sostanziale dell'overhead nel ricevitore. Non solo l'overhead di sistema aumenta a causa della ricezione di più messaggi, ma anche l'overhead della scansione della tabella di routing per gli aggiornamenti ai peer BGP e ad altri protocolli di routing (e l'invio dei messaggi associati) viene sostenuto più volte.

Un metodo per costruire messaggi che contengono molti prefissi di indirizzo per set di attributi di percorso da una tabella di routing che non è organizzata su base per set di attributi di percorso è costruire molti messaggi mentre la tabella di routing viene scansionata. Quando ogni prefisso di indirizzo viene elaborato, viene allocato un messaggio per il set di attributi di percorso associato, se non esiste, e il nuovo prefisso di indirizzo viene aggiunto ad esso. Se tale messaggio esiste, il nuovo prefisso di indirizzo viene aggiunto. Se il messaggio manca dello spazio per contenere il nuovo prefisso di indirizzo, viene trasmesso, viene allocato un nuovo messaggio e il nuovo prefisso di indirizzo viene inserito nel nuovo messaggio. Quando l'intera tabella di routing è stata scansionata, tutti i messaggi allocati vengono inviati e le loro risorse vengono rilasciate. La massima compressione si ottiene quando tutte le destinazioni coperte dai prefissi di indirizzo condividono un set comune di attributi di percorso, rendendo possibile l'invio di molti prefissi di indirizzo in un unico messaggio di 4096 byte.

Quando si effettua il peering con un'implementazione BGP che non comprime più prefissi di indirizzo in un unico messaggio, potrebbe essere necessario adottare misure per ridurre l'overhead dal flusso di dati ricevuti quando viene acquisito un peer o quando si verifica un cambiamento significativo della topologia di rete. Un metodo per farlo è limitare il tasso di aggiornamenti. Questo eliminerà la scansione ridondante della tabella di routing per fornire aggiornamenti flash ai peer BGP e ad altri protocolli di routing. Uno svantaggio di questo approccio è che aumenta la latenza di propagazione delle informazioni di routing. Scegliendo un intervallo minimo di aggiornamento flash che non è molto maggiore del tempo necessario per elaborare i più messaggi, questa latenza dovrebbe essere minimizzata. Un metodo migliore sarebbe leggere tutti i messaggi ricevuti prima di inviare aggiornamenti.

Appendix F.2. Reducing Route Flapping (Riduzione del flapping delle route)

Per evitare un eccessivo flapping delle route, un BGP speaker che deve ritirare una destinazione e inviare un aggiornamento su una route più specifica o meno specifica dovrebbe (SHOULD) combinarli nello stesso messaggio UPDATE.

Appendix F.3. Path Attribute Ordering (Ordinamento degli attributi di percorso)

Le implementazioni che combinano messaggi di aggiornamento (come descritto sopra nella Sezione 6.1) potrebbero preferire vedere tutti gli attributi di percorso presentati in un ordine noto. Questo permette loro di identificare rapidamente set di attributi da diversi messaggi di aggiornamento che sono semanticamente identici. Per facilitare ciò, è un'ottimizzazione utile ordinare gli attributi di percorso secondo il codice di tipo. Questa ottimizzazione è interamente opzionale.

Appendix F.4. AS_SET Sorting (Ordinamento AS_SET)

Un'altra ottimizzazione utile che può essere eseguita per semplificare questa situazione è ordinare i numeri AS trovati in un AS_SET. Questa ottimizzazione è interamente opzionale.

Appendix F.5. Control Over Version Negotiation (Controllo sulla negoziazione della versione)

Poiché BGP-4 è in grado di trasportare route aggregate che non possono essere rappresentate correttamente in BGP-3, un'implementazione che supporta BGP-4 e un'altra versione BGP dovrebbe (SHOULD) fornire la capacità di parlare solo BGP-4 su base per peer.

Appendix F.6. Complex AS_PATH Aggregation (Aggregazione complessa AS_PATH)

Un'implementazione che sceglie di fornire un algoritmo di aggregazione di percorso che mantiene quantità significative di informazioni sul percorso potrebbe voler utilizzare la seguente procedura:

Allo scopo di aggregare gli attributi AS_PATH di due route, modelliamo ogni AS come una tupla <type, value>, dove "type" identifica un tipo del segmento di percorso a cui appartiene l'AS (ad esempio, AS_SEQUENCE, AS_SET), e "value" è il numero AS. Due AS sono detti essere uguali se le loro tuple <type, value> corrispondenti sono uguali.

L'algoritmo per aggregare due attributi AS_PATH funziona come segue:

a) Identificare gli stessi AS (come definito sopra) all'interno di ciascun attributo AS_PATH che sono nello stesso ordine relativo in entrambi gli attributi AS_PATH. Due AS, X e Y, sono detti essere nello stesso ordine se:

X precede Y in entrambi gli attributi AS_PATH, o
Y precede X in entrambi gli attributi AS_PATH.

b) L'attributo AS_PATH aggregato consiste di AS identificati in (a), esattamente nello stesso ordine in cui appaiono negli attributi AS_PATH da aggregare. Se due AS consecutivi identificati in (a) non si seguono immediatamente in entrambi gli attributi AS_PATH da aggregare, allora gli AS intermedi (AS che sono tra i due AS consecutivi che sono uguali) in entrambi gli attributi vengono combinati in un segmento di percorso AS_SET che consiste degli AS intermedi di entrambi gli attributi AS_PATH. Questo segmento viene quindi posizionato tra i due AS consecutivi identificati in (a) dell'attributo aggregato. Se due AS consecutivi identificati in (a) si seguono immediatamente in un attributo, ma non si seguono in un altro, allora gli AS intermedi di quest'ultimo vengono combinati in un segmento di percorso AS_SET. Questo segmento viene quindi posizionato tra i due AS consecutivi identificati in (a) dell'attributo aggregato.

c) Per ogni coppia di tuple adiacenti nell'AS_PATH aggregato, se entrambe le tuple hanno lo stesso tipo, unirle insieme se ciò non causerà la generazione di un segmento di lunghezza superiore a 255.

Se, come risultato della procedura sopra, un dato numero AS appare più di una volta all'interno dell'attributo AS_PATH aggregato, tutte le istanze tranne l'ultima (occorrenza più a destra) di quel numero AS dovrebbero (SHOULD) essere rimosse dall'attributo AS_PATH aggregato.