6. Manageability Considerations (Considerazioni sulla gestibilità)
6. Manageability Considerations (Considerazioni sulla gestibilità)
Questa sezione è strutturata come raccomandato in [RFC5706].
Si applicano le procedure operative BGP esistenti. Non sono definite nuove procedure operative in questo documento. Si nota che le informazioni NLRI presenti in questo documento trasportano dati puri a livello applicativo che non hanno un impatto corrispondente immediato sullo stato di forwarding. Pertanto, qualsiasi cambiamento nelle informazioni di raggiungibilità ha un impatto diverso rispetto agli aggiornamenti BGP regolari che devono modificare lo stato di forwarding per un intero router. Inoltre, si prevede che la distribuzione di questo NLRI sia gestita da Route Reflector dedicati che forniscono un livello di isolamento e contenimento degli errori tra diversi tipi di NLRI.
I parametri di configurazione definiti nella Sezione 6.2.3 DOVREBBERO essere inizializzati ai seguenti valori predefiniti:
-
La capacità Link-State NLRI è disabilitata per tutti i vicini.
-
La velocità massima con cui i Link-State NLRI vengono annunciati/ritirati dai vicini è impostata a 200 aggiornamenti al secondo.
L'estensione proposta viene attivata solo tra peer BGP dopo la negoziazione della capacità. Inoltre, le estensioni possono essere attivate/disattivate su base per-peer (vedi Sezione 6.2.3), in modo che l'estensione possa essere introdotta gradualmente nella rete.
L'estensione del protocollo definita in questo documento non pone nuovi requisiti su altri protocolli o componenti funzionali.
La frequenza degli aggiornamenti del Link-State NLRI potrebbe influire sulla distribuzione regolare dei prefissi BGP. Un operatore di rete PUÒ utilizzare un'infrastruttura dedicata di Route Reflector per distribuire i Link-State NLRI.
La distribuzione dei Link-State NLRI DOVREBBE essere limitata a un singolo dominio amministrativo che può consistere in più aree all'interno di un AS o più AS.
Si applicano le procedure BGP esistenti. Inoltre, un'implementazione DOVREBBE consentire a un operatore di:
- Elencare i vicini con cui lo speaker scambia Link-State NLRI.
Il gruppo di lavoro IDR ha documentato e continua a documentare parti della Management Information Base e modelli YANG per la gestione e il monitoraggio degli speaker BGP e delle sessioni tra di essi. Si presume attualmente che la sessione BGP che esegue BGP-LS non differisca materialmente da qualsiasi altra sessione BGP e possa essere gestita con gli stessi modelli di dati.
Se un'implementazione di BGP-LS rileva un attributo malformato, allora DEVE utilizzare l'azione 'Attribute Discard' secondo [RFC7606], Sezione 2.
Un'implementazione di BGP-LS DEVE eseguire i seguenti controlli sintattici per determinare se un messaggio è malformato.
-
La somma di tutti i TLV trovati nell'attributo BGP-LS corrisponde alla lunghezza dell'attributo di percorso BGP-LS?
-
La somma di tutti i TLV trovati nell'attributo BGP MP_REACH_NLRI corrisponde alla lunghezza BGP MP_REACH_NLRI?
-
La somma di tutti i TLV trovati nell'attributo BGP MP_UNREACH_NLRI corrisponde alla lunghezza BGP MP_UNREACH_NLRI?
-
La somma di tutti i TLV trovati in un attributo NLRI Node-, Link- o Prefix-Descriptor corrisponde al campo Total NLRI Length dei Node-, Link- o Prefix-Descriptor?
-
Un TLV di lunghezza fissa corrisponde al campo TLV Length in questo documento?
Un'implementazione DOVREBBE consentire all'operatore di specificare i vicini a cui vengono annunciati i Link-State NLRI e da cui i Link-State NLRI vengono accettati.
Un'implementazione DOVREBBE consentire all'operatore di specificare la velocità massima con cui i Link-State NLRI vengono annunciati/ritirati dai vicini.
Un'implementazione DOVREBBE consentire all'operatore di specificare il numero massimo di Link-State NLRI memorizzati nella Routing Information Base (RIB) di un router.
Un'implementazione DOVREBBE consentire all'operatore di creare topologie astratte da annunciare ai vicini e di creare diverse astrazioni per vicini diversi.
Un'implementazione DOVREBBE consentire all'operatore di configurare un Instance-ID a 64 bit.
Un'implementazione DOVREBBE consentire all'operatore di configurare una coppia di ASN e identificatore BGP-LS (Sezione 3.2.1.4) per insieme di flooding a cui partecipa il nodo.
Non applicabile.
Un'implementazione DOVREBBE fornire le seguenti statistiche:
-
Numero totale di aggiornamenti Link-State NLRI inviati/ricevuti
-
Numero di aggiornamenti Link-State NLRI inviati/ricevuti per vicino
-
Numero di aggiornamenti Link-State NLRI malformati ricevuti per vicino
-
Numero totale di Link-State NLRI originati localmente
Queste statistiche dovrebbero essere registrate come conteggi assoluti dall'avvio del sistema o della sessione. Un'implementazione PUÒ anche aumentare queste informazioni registrando valori di picco al secondo in ciascun caso.
Un operatore DOVREBBE definire una politica di importazione per limitare gli aggiornamenti in arrivo come segue:
- Scartare tutti gli aggiornamenti dai peer consumatori.
Un'implementazione DEVE avere la capacità di limitare gli aggiornamenti in arrivo.