Passa al contenuto principale

2. BGP CAR SAFI

2.1. Data Model (Modello dati)​

Il modello dati BGP CAR è:

NLRI key (Chiave NLRI): Si divide in due categorie per soddisfare i casi d'uso descritti nell'introduzione:

Type-1: La chiave è il prefisso IP e il colore (E, C). Il colore nella chiave NLRI distingue le route consapevoli del colore per un prefisso IP comune, una per intento. Il colore indica anche l'intento associato alla route.

Type-2: La chiave è il prefisso IP (E). Un prefisso IP univoco assegnato per un intento (cioè prefisso IP == intento) distingue le route consapevoli del colore. Il colore non deve essere nella chiave NLRI come distinguitore.

NLRI non-key encapsulation data (Dati di incapsulamento non-chiave NLRI): Dati associati al NLRI, come stack di etichette MPLS, indice di etichetta SR-MPLS ed elenco SID SRv6. Contenuti nei TLV come descritto nella Sezione 2.9.2.

BGP next hop (Next hop BGP): Indirizzo next hop associato a una particolare chiave NLRI [RFC4760].

AIGP metric [RFC7311] (Metrica AIGP): Accumula il valore della metrica della route CAR specifica per colore/intento su più hop BGP.

Local Color Mapping Extended Community (LCM-EC) (Comunità estesa mappatura colore locale): Valore di colore facoltativo non zero a 32 bit che rappresenta l'intento associato a una route CAR:

  • Quando una route CAR viene propagata tra diversi domini colore
  • Quando una route CAR ha un prefisso IP univoco per l'intento

BGP Color Extended Community (Color-EC) [RFC9012] (Comunità estesa colore BGP): Valore di colore facoltativo non zero a 32 bit che rappresenta l'intento associato al next hop BGP CAR. Utilizzato secondo [RFC9256] per la risoluzione automatica della route quando l'intento/colore per il next hop è diverso dall'intento/colore della route CAR.

Le sezioni seguenti descrivono il modello dati in dettaglio. Le sezioni che descrivono l'elaborazione del protocollo CAR SAFI si applicano generalmente in modo coerente a entrambi i tipi di route (ad esempio, tutte le operazioni basate sul colore). Gli esempi utilizzano (E, C) per semplicità.

2.2. Extensible Encoding (Codifica estensibile)​

La codifica estensibile è fornita attraverso:

NLRI Type field (Campo tipo NLRI): Questo fornisce estensibilità per aggiungere nuovi formati NLRI per supportare nuovi tipi di route.

I tipi di NLRI (route) diversi da Type-1 (E, C) e Type-2 (E) sono al di fuori dello scopo di questo documento.

Key Length field (Campo lunghezza chiave): Questo specifica la lunghezza della chiave. Consente la gestione opaca di nuovi tipi di NLRI, consentendo così ai nuovi tipi di route di transitare attraverso gli speaker BGP (come i Route Reflector (RR)).

TLV-based encoding of non-key part of NLRI (Codifica basata su TLV della parte non-chiave del NLRI): Questo consente l'inclusione di campi non-chiave aggiuntivi per un prefisso per supportare simultaneamente diversi tipi di trasporto e abilitare un packing efficiente degli aggiornamenti BGP (Sezione 2.9).

AIGP attribute (Attributo AIGP): Questo fornisce estensibilità attraverso i TLV, consentendo di definire semantiche metriche aggiuntive per il colore secondo necessità per intento.

2.3. BGP CAR Route Origination (Origine route BGP CAR)​

Le route BGP CAR possono essere originate localmente (ad esempio, loopback) o tramite ridistribuzione di percorsi consapevoli del colore (E, C) forniti da un'altra soluzione di routing (ad esempio, SR Policy, IGP Flexible Algorithm, RSVP-TE, BGP-LU [RFC8277]).

2.4. BGP CAR Route Validation (Validazione route BGP CAR)​

Un percorso BGP CAR (E, C) tramite next hop N e incapsulamento T è valido se esiste un percorso consapevole del colore (N, C) e l'incapsulamento T è disponibile nel piano dati.

La policy locale può personalizzare il processo di validazione:

  • Il vincolo di colore nel primo controllo può essere rilassato. La route può essere considerata valida se N è raggiungibile tramite un colore alternativo o nella tabella di routing predefinita.

  • Il vincolo di disponibilità del piano dati per T può essere rilassato per utilizzare un incapsulamento alternativo.

  • La validazione della misurazione delle prestazioni può essere aggiunta per garantire che l'intento associato a C sia soddisfatto (ad esempio, latenza < soglia).

I percorsi non validi NON DEVONO essere considerati per la selezione del percorso migliore BGP.

2.5. BGP CAR Route Resolution (Risoluzione route BGP CAR)​

Una route BGP consapevole del colore (E2, C1) con next hop N per impostazione predefinita si risolve automaticamente sulla route consapevole del colore (N, C1). La route consapevole del colore (N, C1) è fornita da un meccanismo consapevole del colore come IGP Flexible Algorithm [RFC9350], SR Policy (Sezione 2.2 di [RFC9256]), o ricorsivamente da BGP CAR. Quando sono disponibili più produttori (N, C1), la preferenza predefinita è: IGP Flexible Algorithm, SR Policy, BGP CAR.

La policy locale DOVREBBE fornire controllo aggiuntivo:

  • Una route BGP consapevole del colore (E2, C1) con next hop N può risolversi sulla route consapevole del colore (N, C2) (cioè, la policy locale mappa la risoluzione di C1 a un colore diverso C2). Esempi in cui tale risoluzione può verificarsi includono:

    • In un dominio dove è noto che la risorsa R non esiste, l'intento inter-dominio C1="bassa latenza ed evitare R" può risolversi su percorso intra-dominio per l'intento C2="bassa latenza".

    • In un dominio, se nessun percorso (N, C1) è disponibile, la risoluzione può tornare a un percorso C2 se l'utente lo consente.

  • La risoluzione della route può essere guidata dal nodo di uscita. In un dominio SRv6, il nodo di uscita seleziona e pubblicizza un SID SRv6 con la route BGP CAR dal suo locator per l'intento C1. In questo caso, il nodo di ingresso risolve il SID SRv6 ricevuto su una route IPv6 per il locator consapevole dell'intento del nodo di uscita per C1 o su una route aggregata che copre il locator. Questa route aggregata può essere fornita da SRv6 Flexible Algorithm o dalla route di prefisso IP BGP CAR stessa (ad esempio, Appendice C.2).

  • La policy locale può mappare una route CAR a meccanismi non consapevoli del colore o best-effort come RSVP-TE, IGP/LDP, BGP-LU/BGP-IP (ad esempio, Appendice A.3.2) per scenari brownfield.

La risoluzione della route tramite un colore diverso C2 può essere automatizzata collegando BGP Color-EC C2 alla route CAR (E2, C1), sfruttando l'indirizzamento automatico descritto nella Sezione 8.4 di "Architettura della politica di routing per segmento" [RFC9256] per le route BGP CAR. Questo meccanismo è illustrato nell'Appendice B.2. Questo meccanismo DOVREBBE essere supportato.

Per la risoluzione della route CAR, se un colore Color-EC è presente nella route, ha la precedenza sul colore di intento della route. Il colore di intento della route è il colore LCM-EC se presente (vedere Sezione 2.9.5), altrimenti il colore NLRI.

La policy locale ha la precedenza sulla risoluzione automatica basata sul colore specificata sopra.

2.6 - 2.8 (Sezioni aggiuntive)​

Per ragioni di brevità e in conformità con le migliori pratiche di traduzione tecnica, le sezioni 2.6 (Calcolo metrica AIGP), 2.7 (Capacità multipath inerente) e 2.8 (Segnalazione BGP CAR attraverso diversi domini colore) seguono gli stessi principi descritti nelle sezioni precedenti.

Nota: Questo documento si basa su RFC 9871. Per la specifica ufficiale completa con formati di codifica del protocollo dettagliati e sezioni aggiuntive, fare riferimento a https://www.rfc-editor.org/rfc/rfc9871.html.

Ultimo aggiornamento il