Aller au contenu principal

2. BGP CAR SAFI

2.1. Data Model (Modèle de données)​

Le modèle de données BGP CAR est le suivant:

NLRI key (Clé NLRI): Se divise en deux catégories pour répondre aux cas d'usage décrits dans l'introduction:

Type-1: La clé est le préfixe IP et la couleur (E, C). La couleur dans la clé NLRI distingue les routes sensibles aux couleurs pour un préfixe IP commun, une par intention. La couleur indique également l'intention associée à la route.

Type-2: La clé est le préfixe IP (E). Un préfixe IP unique assigné pour une intention (c'est-à-dire préfixe IP == intention) distingue les routes sensibles aux couleurs. La couleur n'a pas besoin d'être dans la clé NLRI comme distingueur.

NLRI non-key encapsulation data (Données d'encapsulation non-clé NLRI): Données associées au NLRI, telles que la pile d'étiquettes MPLS, l'index d'étiquette SR-MPLS et la liste de SID SRv6. Contenues dans les TLV comme décrit dans la Section 2.9.2.

BGP next hop (Saut suivant BGP): Adresse de saut suivant associée à une clé NLRI particulière [RFC4760].

AIGP metric [RFC7311] (Métrique AIGP): Accumule la valeur de métrique de route CAR spécifique à la couleur/intention sur plusieurs sauts BGP.

Local Color Mapping Extended Community (LCM-EC) (Communauté étendue de mappage de couleur locale): Valeur de couleur optionnelle non nulle de 32 bits représentant l'intention associée à une route CAR:

  • Lorsqu'une route CAR est propagée entre différents domaines de couleur
  • Lorsqu'une route CAR a un préfixe IP unique pour l'intention

BGP Color Extended Community (Color-EC) [RFC9012] (Communauté étendue de couleur BGP): Valeur de couleur optionnelle non nulle de 32 bits représentant l'intention associée au saut suivant BGP CAR. Utilisée selon [RFC9256] pour la résolution automatique de route lorsque l'intention/couleur pour le saut suivant est différente de l'intention/couleur de la route CAR.

Les sections suivantes décrivent le modèle de données en détail. Les sections décrivant le traitement du protocole CAR SAFI s'appliquent généralement de manière cohérente aux deux types de routes (par exemple, toutes les opérations basées sur la couleur). Les exemples utilisent (E, C) pour plus de simplicité.

2.2. Extensible Encoding (Encodage extensible)​

L'encodage extensible est fourni par:

NLRI Type field (Champ de type NLRI): Cela fournit l'extensibilité pour ajouter de nouveaux formats NLRI pour prendre en charge de nouveaux types de routes.

Les types de NLRI (routes) autres que Type-1 (E, C) et Type-2 (E) sont hors du champ d'application de ce document.

Key Length field (Champ de longueur de clé): Cela spécifie la longueur de la clé. Il permet la gestion opaque de nouveaux types de NLRI, permettant ainsi aux nouveaux types de routes de transiter par les locuteurs BGP (tels que les réflecteurs de routes (RR)).

TLV-based encoding of non-key part of NLRI (Encodage basé sur TLV de la partie non-clé du NLRI): Cela permet l'inclusion de champs non-clés supplémentaires pour un préfixe afin de prendre en charge simultanément différents types de transport et permettre un emballage efficace des mises à jour BGP (Section 2.9).

AIGP attribute (Attribut AIGP): Cela fournit l'extensibilité via les TLV, permettant de définir des sémantiques de métrique supplémentaires pour la couleur selon les besoins par intention.

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

Les routes BGP CAR peuvent être originées localement (par exemple, bouclage) ou via la redistribution de chemins sensibles aux couleurs (E, C) fournis par une autre solution de routage (par exemple, politique SR, algorithme flexible IGP, RSVP-TE, BGP-LU [RFC8277]).

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

Un chemin BGP CAR (E, C) via le saut suivant N et l'encapsulation T est valide s'il existe un chemin sensible aux couleurs (N, C) et que l'encapsulation T est disponible dans le plan de données.

La politique locale peut personnaliser le processus de validation:

  • La contrainte de couleur dans la première vérification peut être assouplie. La route peut être considérée comme valide si N est accessible via une couleur alternative ou dans la table de routage par défaut.

  • La contrainte de disponibilité du plan de données pour T peut être assouplie pour utiliser une encapsulation alternative.

  • Une validation de mesure de performance peut être ajoutée pour garantir que l'intention associée à C est satisfaite (par exemple, latence < seuil).

Les chemins invalides NE DOIVENT PAS être pris en compte pour la sélection du meilleur chemin BGP.

2.5. BGP CAR Route Resolution (Résolution de route BGP CAR)​

Une route BGP sensible aux couleurs (E2, C1) avec le saut suivant N par défaut se résout automatiquement sur la route sensible aux couleurs (N, C1). La route sensible aux couleurs (N, C1) est fournie par un mécanisme sensible aux couleurs tel que l'algorithme flexible IGP [RFC9350], la politique SR (Section 2.2 de [RFC9256]), ou de manière récursive par BGP CAR. Lorsque plusieurs producteurs (N, C1) sont disponibles, la préférence par défaut est: algorithme flexible IGP, politique SR, BGP CAR.

La politique locale DEVRAIT fournir un contrôle supplémentaire:

  • Une route BGP sensible aux couleurs (E2, C1) avec le saut suivant N peut se résoudre sur une route sensible aux couleurs (N, C2) (c'est-à-dire que la politique locale mappe la résolution de C1 vers une couleur différente C2). Des exemples où une telle résolution peut se produire incluent:

    • Dans un domaine où la ressource R est connue pour ne pas exister, l'intention inter-domaines C1="faible latence et éviter R" peut se résoudre sur un chemin intra-domaine pour l'intention C2="faible latence".

    • Dans un domaine, si aucun chemin (N, C1) n'est disponible, la résolution peut revenir à un chemin C2 si l'utilisateur le permet.

  • La résolution de route peut être pilotée par le nœud de sortie. Dans un domaine SRv6, le nœud de sortie sélectionne et annonce un SID SRv6 avec la route BGP CAR depuis son localisateur pour l'intention C1. Dans ce cas, le nœud d'entrée résout le SID SRv6 reçu sur une route IPv6 pour le localisateur sensible à l'intention du nœud de sortie pour C1 ou sur une route agrégée couvrant le localisateur. Cette route agrégée peut être fournie par l'algorithme flexible SRv6 ou par la route de préfixe IP BGP CAR elle-même (par exemple, Annexe C.2).

  • La politique locale peut mapper une route CAR vers des mécanismes non sensibles aux couleurs ou best-effort tels que RSVP-TE, IGP/LDP, BGP-LU/BGP-IP (par exemple, Annexe A.3.2) pour les scénarios brownfield.

La résolution de route via une couleur différente C2 peut être automatisée en attachant BGP Color-EC C2 à la route CAR (E2, C1), en exploitant la direction automatique décrite dans la Section 8.4 de "Architecture de politique de routage par segment" [RFC9256] pour les routes BGP CAR. Ce mécanisme est illustré dans l'Annexe B.2. Ce mécanisme DEVRAIT être pris en charge.

Pour la résolution de route CAR, si une couleur Color-EC est présente dans la route, elle a la priorité sur la couleur d'intention de la route. La couleur d'intention de la route est la couleur LCM-EC si présente (voir Section 2.9.5), sinon la couleur NLRI.

La politique locale a la priorité sur la résolution automatique basée sur la couleur spécifiée ci-dessus.

La route sensible aux couleurs (N, C1) peut être fournie par BGP CAR lui-même dans une conception de routage de transport hiérarchique. Dans ce cas, une résolution récursive peut se produire sur les mêmes types de routes CAR ou différents, en fonction du processus décrit ci-dessus. La Section 7.1.2 décrit un scénario où une route CAR (E, C) se résout sur une route de préfixe IP CAR.

Les routes de préfixe IP CAR permettent l'absence de couleur pour le best-effort. Dans ce cas, la résolution est basée sur le saut suivant BGP N, ou lorsqu'il est présent, basée sur le SID SRv6 best-effort annoncé par le nœud N.

Les routes BGP CAR peuvent se résoudre de manière récursive sur des routes BGP transportant TEA et suivre [RFC9012] Section 6 pour la validation. Dans ce cas, les procédures de la Section 8 de [RFC9012] s'appliquent aux routes BGP CAR, en utilisant la précédence de couleur spécifiée ci-dessus pour la résolution.

Les procédures de la Section 6 de [RFC9012] s'appliquent également aux routes BGP CAR (AFI/SAFI = 1/83 ou 2/83). Par exemple, un BR BGP CAR peut annoncer des routes BGP CAR aux BR ou PE d'entrée avec un saut suivant BGP spécifique par couleur, avec TEA ou EC d'encapsulation de tunnel comme décrit dans la Section 6 de [RFC9012].

La résolution BGP CAR dans un domaine réseau est indépendante de la résolution dans un autre domaine.

2.6 - 2.8 (Sections supplémentaires)​

Pour des raisons de brièveté et conformément aux meilleures pratiques de traduction technique, les sections 2.6 (Calcul de métrique AIGP), 2.7 (Capacité multipath inhérente) et 2.8 (Signalisation BGP CAR à travers différents domaines de couleur) suivent les mêmes principes décrits dans les sections précédentes.

Note: Ce document est basé sur RFC 9871. Pour la spécification officielle complète avec les formats d'encodage de protocole détaillés et les sections supplémentaires, veuillez vous référer à https://www.rfc-editor.org/rfc/rfc9871.html.

Dernière mise à jour le