1. Introduction (Introduzione)

BGP Color-Aware Routing (BGP CAR) è una soluzione di routing basata su BGP per stabilire percorsi end-to-end consapevoli dell'intento attraverso una rete di trasporto multi-dominio del service provider. BGP CAR distribuisce route diverse verso un endpoint di rete di destinazione (ad esempio, un router Provider Edge (PE)) per intenti o colori diversi. Un colore è un valore intero a 32 bit non zero associato a un intento di rete (come basso costo, bassa latenza, evitare determinate risorse, slice di rete 5G, ecc.) come definito nella Sezione 2.1 di [RFC9256].

BGP CAR affronta la dichiarazione del problema e i requisiti di trasporto e VPN descritti in [INTENT-AWARE].

A tale scopo, questo documento specifica due nuovi SAFI BGP, chiamati BGP CAR SAFI (83) e VPN CAR SAFI (84), per trasportare route di infrastruttura per stabilire percorsi di trasporto. Sia CAR SAFI che VPN CAR SAFI sono applicabili agli AFI IPv4 Unicast e IPv6 Unicast (AFI 1 e AFI 2). L'uso di questi SAFI con altri AFI è al di fuori dello scopo di questo documento.

BGP CAR SAFI può essere abilitato sui dispositivi di trasporto in una rete provider (underlay) per stabilire percorsi di trasporto/infrastruttura consapevoli del colore tra le reti provider. Una rete di trasporto multi-dominio può comprendere più sistemi autonomi BGP (AS) nonché più domini IGP all'interno di un singolo AS BGP. BGP CAR SAFI può anche essere abilitato in VPN Routing and Forwarding (VRF) sui router PE verso router Customer Edge (CE) peering, nonché su dispositivi all'interno delle reti dei clienti. VPN CAR SAFI viene utilizzato per distribuire route consapevoli dell'intento ricevute da diversi clienti sui router PE, attraverso la rete provider, mantenendo la separazione degli spazi di indirizzamento dei clienti potenzialmente sovrapposti. Pertanto, la soluzione BGP CAR consente di stabilire percorsi di trasporto consapevoli dell'intento in una rete multi-dominio che si estende su domini di rete cliente e provider.

Questo documento definisce anche due tipi di route BGP CAR per questo scopo.

BGP CAR Type-1 NLRI (E, C) supporta l'origine e la distribuzione di più route consapevoli del colore verso lo stesso prefisso IP di destinazione per colori diversi. Ciò si verifica in scenari in cui un nodo di trasporto (come un PE) ha un indirizzo IP comune (come un indirizzo di loopback) per più annunci di intento. L'operatore intende utilizzare questo indirizzo IP comune sia come next hop BGP per le route di servizio che come endpoint di trasporto per i percorsi del piano dati. Sono necessarie più route verso questo stesso indirizzo o prefisso per stabilire percorsi univoci per ogni intento. Un esempio è stabilire più Label Switched Path (LSP) verso un PE di uscita per MPLS o Segment Routing over MPLS (SR-MPLS), uno per ogni intento.

BGP CAR Type-2 NLRI (prefisso IP o E) supporta la distribuzione di più route consapevoli del colore verso un nodo di trasporto in scenari in cui l'operatore designa blocchi di indirizzi IP di rete univoci per un dato intento e il nodo di trasporto assegna un prefisso IP o un indirizzo univoco per ogni intento. Un esempio di caso d'uso sono i locator per intento per Segment Routing over IPv6 (SRv6).

Questi percorsi BGP CAR consapevoli dell'intento vengono quindi utilizzati dai nodi di ingresso (come i PE) per indirizzare il traffico per le route di servizio che necessitano di un intento specifico. L'indirizzamento può riguardare tutto o parte del traffico verso una destinazione.

BGP CAR segue il modello di routing piatto utilizzato da BGP per il routing IP (BGP-IP) [RFC4271] o BGP Labeled Unicast (BGP-LU) (SAFI 4 in [RFC8277]) e lo estende per supportare la consapevolezza dell'intento, fornendo così un'esperienza operativa coerente con queste tecnologie di routing di trasporto ampiamente distribuite.

1.1. Terminology (Terminologia)

Intent (in routing) (Intento (nel routing)):
Qualsiasi comportamento che influenza il routing o la selezione del percorso, inclusa qualsiasi combinazione dei seguenti comportamenti:

a. Selezione del percorso topologico (ad esempio, minimizzazione di una metrica o evitamento di risorse)
b. Inserimento di servizio Network Function Virtualization (NFV) (ad esempio, indirizzamento della catena di servizi)
c. Comportamento per hop (ad esempio, slicing 5G)

Questo è un concetto più specifico del best-effort in termini di routing, rispetto all'intento come astrazione dichiarativa in [RFC9315].

Color (Colore):
Un valore intero a 32 bit non zero associato a un intento (ad esempio, basso costo, bassa latenza o evitamento di determinate risorse), come definito nella Sezione 2.1 di [RFC9256]. L'assegnazione dei colori è gestita dall'operatore.

Colored service route (Route di servizio colorata):
Un PE di uscita (ad esempio, E2) colora la sua route di servizio BGP (ad esempio, VPN) (ad esempio, V/v) per indicare l'intento che richiede per il traffico associato a V/v. Il colore è codificato come BGP Color Extended Community [RFC9012], utilizzato secondo [RFC9256], o rappresentato dalla parte locator di un SID di servizio SRv6 [RFC9252].

Color-aware path to (E2, C) (Percorso consapevole del colore verso (E2, C)):
Un percorso per inoltrare pacchetti verso E2 che soddisfa l'intento associato al colore C. Più tecnologie possono fornire un percorso consapevole del colore verso (E2, C), come SR Policy [RFC9256], IGP Flexible Algorithm [RFC9350] e BGP CAR (come specificato in questo documento).

Color-aware route (E2, C) (Route consapevole del colore (E2, C)):
Una route distribuita o segnalata per costruire un percorso consapevole del colore verso E2 per il colore C.

Service route automated steering on color-aware path (Indirizzamento automatico della route di servizio su percorso consapevole del colore):
Un PE di ingresso (o ASBR) E1 indirizza automaticamente il traffico per una route di servizio V/v colorata con C da E2 su un percorso consapevole del colore (E2, C). Se esistono più di questi percorsi, viene utilizzato uno schema di preferenza per selezionare il percorso migliore (ad esempio, IGP Flexible Algorithm preferito rispetto a SR Policy, SR Policy preferito rispetto a BGP CAR).

Color domain (Dominio colore):
Un insieme di nodi che condividono lo stesso mapping colore-intento, tipicamente sotto un'unica amministrazione. L'insieme può essere organizzato in uno o più domini di rete (aree/istanze IGP all'interno di un singolo AS BGP o più AS BGP). Il mapping colore-intento sui nodi è impostato tramite configurazione. Il rimapping e il filtraggio dei colori possono verificarsi ai confini del dominio colore. Vedere [INTENT-AWARE].

Resolution of a BGP CAR route (E, C) (Risoluzione di una route BGP CAR (E, C)):
Una route BGP CAR inter-dominio (E, C) tramite N viene risolta su un percorso consapevole del colore intra-dominio (N, C), dove N è il next hop della route BGP CAR.

Resolution versus steering (Risoluzione versus indirizzamento):
Coerentemente con la terminologia utilizzata nei documenti SR Policy ([RFC9256] Sezione 8), in questo documento, l'indirizzamento (di route di servizio) viene utilizzato per descrivere il mapping del traffico per una route di servizio su un percorso BGP CAR. Al contrario, il termine risoluzione è riservato al mapping di una route BGP CAR inter-dominio su un percorso consapevole del colore intra-dominio.

Service steering (Indirizzamento di servizio):
La route di servizio mappa il traffico su un percorso BGP CAR (o altro percorso consapevole del colore, ad esempio SR Policy). Se un percorso consapevole del colore non è disponibile, la policy locale può mappare su una route/percorso TE non consapevole del colore (ad esempio, BGP-LU, RSVP-TE, IGP/LDP). Il concetto di indirizzamento di servizio è indipendente dalla tecnologia di trasporto utilizzata. La Sezione 3 descrive meccanismi specifici di indirizzamento di servizio per MPLS, SR-MPLS e SRv6.

Intra-domain resolution (Risoluzione intra-dominio):
La route BGP CAR mappa su un percorso consapevole del colore intra-dominio (ad esempio, SR Policy, IGP Flexible Algorithm, BGP CAR) o route/percorso TE non consapevole del colore (ad esempio, RSVP-TE, IGP/LDP, BGP-LU).

Transport network (Rete di trasporto):
Una rete comprendente più domini collaborativi gestiti da uno o più operatori, utilizzando tecnologie di routing (come IP, MPLS e SR) per inoltrare pacchetti per fornire connettività e altri servizi. Nelle distribuzioni SR, la rete di trasporto si trova all'interno del dominio affidabile come definito in [RFC8402].

Transport layer (Strato di trasporto):
Si riferisce allo strato di rete underlay (ad esempio, LSP MPLS tra PE) utilizzato da uno strato overlay o di servizio (ad esempio, MPLS VPN).

Transport RR (RR di trasporto):
Un BGP Route Reflector (RR) utilizzato per distribuire route di trasporto/underlay intra-dominio o inter-dominio.

Service RR (RR di servizio):
Un BGP Route Reflector (RR) utilizzato per distribuire route di servizio/overlay intra-dominio o inter-dominio.

Abbreviations (Abbreviazioni):

• ABR: Area Border Router (Router di confine di area)
• AFI: Address Family Identifier (Identificatore famiglia di indirizzi)
• AIGP: Accumulated IGP Metric Attribute [RFC7311] (Attributo metrica IGP accumulata)
• ASBR: Autonomous System Border Router (Router di confine del sistema autonomo)
• BGP-LU: BGP Labeled Unicast SAFI (valore SAFI 4 secondo [RFC8277])
• BGP-IP: BGP IPv4/IPv6 Unicast SAFI (valore SAFI 1 secondo [RFC4760] e [RFC4271])
• BR: Border Router (Router di confine, per area IGP (ABR) o sistema autonomo BGP (ASBR))
• Color-EC: BGP Color Extended Community [RFC9012] (Comunità estesa colore BGP)
• E: Rappresentazione generica di un endpoint di trasporto, ad esempio PE, ABR o ASBR
• LCM-EC: BGP Local Color Mapping Extended Community (Comunità estesa mappatura colore locale BGP)
• NLRI: Network Layer Reachability Information [RFC4271] (Informazioni di raggiungibilità dello strato di rete)
• P node: Router di trasporto intra-dominio
• RD: Route Distinguisher (Distinguitore di route)
• RR: Route Reflector (Riflettore di route)
• T-RR: Transport Route Reflector (Riflettore di route di trasporto)
• S-RR: Service Route Reflector (Riflettore di route di servizio)
• SAFI: Subsequent Address Family Identifier (Identificatore sottofamiglia di indirizzi)
• TEA: Tunnel Encapsulation Attribute [RFC9012] (Attributo incapsulamento tunnel)
• V/v, W/w: Rappresentazione generica delle route di servizio (indicante lunghezza prefisso/maschera), indipendentemente da AFI/SAFI o codifica NLRI effettiva

1.2. Illustration (Illustrazione)

Quella che segue è una breve illustrazione delle caratteristiche notevoli della soluzione BGP CAR.

+-------------+      +-------------+      +-------------+
|             |      |             |      |             | V/v with C1
|----+        |------|             |------|        +----|/
| E1 |        |      |             |      |        | E2 |\
|----+        |      |             |      |        +----| W/w with C2
|             |------|             |------|             |
|  Domain 1   |      |   Domain 2  |      |   Domain 3  |
+-------------+      +-------------+      +-------------+

Figura 1: Illustrazione della soluzione BGP CAR

Tutti i nodi fanno parte di una rete inter-dominio sotto un'unica autorità con mapping colore-intento coerente:

• C1 mappa su "bassa latenza"

  • Flex-Algo 1 mappa su "bassa latenza", quindi su C1

• C2 mappa su "bassa latenza ed evitamento della risorsa R"

  • Flex-Algo 2 mappa su "bassa latenza ed evitamento della risorsa R", quindi su C2

E1 riceve due route di servizio da E2:

• V/v con BGP Color-EC C1
• W/w con BGP Color-EC C2

E1 dispone dei seguenti percorsi consapevoli del colore:

• (E2, C1) fornito da BGP CAR con supporto per dominio come segue:

  • Dominio 1: tramite IGP FA1
  • Dominio 2: tramite SR Policy associata al colore C1
  • Dominio 3: tramite IGP FA1

• (E2, C2) fornito da SR Policy

E1 indirizza automaticamente il traffico per le route di servizio ricevute come segue:

• V/v tramite (E2, C1) fornito da BGP CAR
• W/w tramite (E2, C2) fornito da SR Policy

Proprietà dell'esempio:

• Sfruttamento di BGP Color-EC

  • Le route di servizio sono colorate utilizzando la BGP Color Extended Community ampiamente utilizzata [RFC9012] per richiedere l'intento

• Indirizzamento automatico (E, C)

  • V/v e W/w sono automaticamente indirizzati verso percorsi consapevoli del colore appropriati

• Coesistenza senza soluzione di continuità di BGP CAR e SR Policy

  • V/v indirizzato verso percorso consapevole del colore fornito da BGP CAR
  • W/w indirizzato verso percorso consapevole del colore fornito da SR Policy

• Interoperabilità senza soluzione di continuità di BGP CAR e SR Policy

  • V/v indirizzato verso percorso BGP CAR, che a sua volta si risolve all'interno del Dominio 2 in una SR Policy associata al colore di V/v

Proprietà aggiuntive:

• Piano dati MPLS: Per 300k PE e 5 colori, la soluzione BGP CAR garantisce che nessun singolo nodo debba supportare una scala del piano dati dell'ordine di PE remoti * C (Sezione 5). Ciò altrimenti supererebbe le capacità del piano dati MPLS.

• Piano di controllo: Se un nodo non partecipa a quel percorso consapevole del colore, NON DOVREBBE installare il percorso (E, C).

• Mapping colore-intento incoerente: La soluzione supporta la segnalazione di route BGP CAR attraverso diversi domini colore (Sezione 2.8).

I principali vantaggi di questo modello sono:

• Sfruttamento di BGP Color-EC [RFC9012] per la colorazione delle route di servizio
• Definizione dell'indirizzamento automatico di servizio: la route di servizio V/v colorata con C da E2 indirizza verso percorso consapevole del colore (E2, C)
• Definizione del modello dati del percorso BGP CAR: (E, C)
  • Estensione naturale del modello dati BGP-IP/BGP-LU (E)
  • Coerente con il modello dati SR Policy
• Definizione della risoluzione ricorsiva per le route BGP CAR: la route BGP CAR (E2, C) tramite N si risolve su percorso consapevole del colore (N, C), che a sua volta può essere fornito da BGP CAR o tramite un'altra soluzione di routing consapevole del colore (ad esempio, SR Policy, IGP Flexible Algorithm)
• Definizione esplicita di più incapsulamenti di trasporto (ad esempio, MPLS, SR, SRv6, IP)

1.3. Requirements Language (Linguaggio dei requisiti)

Le parole chiave "MUST (DEVE)", "MUST NOT (NON DEVE)", "REQUIRED (RICHIESTO)", "SHALL (DEVE)", "SHALL NOT (NON DEVE)", "SHOULD (DOVREBBE)", "SHOULD NOT (NON DOVREBBE)", "RECOMMENDED (RACCOMANDATO)", "NOT RECOMMENDED (NON RACCOMANDATO)", "MAY (PUÒ)" e "OPTIONAL (OPZIONALE)" in questo documento devono essere interpretate come descritto in BCP 14 [RFC2119] [RFC8174] quando, e solo quando, appaiono in maiuscolo, come mostrato qui.

---