Aller au contenu principal

6. Manageability Considerations (Considérations de gérabilité)

6. Manageability Considerations (Considérations de gérabilité)​

Cette section est structurée comme recommandé dans [RFC5706].

Les procédures opérationnelles BGP existantes s'appliquent. Aucune nouvelle procédure opérationnelle n'est définie dans ce document. Il est noté que les informations NLRI présentes dans ce document transportent des données purement au niveau de l'application qui n'ont pas d'impact immédiat correspondant sur l'état de transfert. En tant que tel, tout changement dans les informations de joignabilité a un impact différent des mises à jour BGP régulières, qui doivent changer l'état de transfert pour un routeur entier. De plus, il est anticipé que la distribution de ce NLRI sera gérée par des route reflectors dédiés fournissant un niveau d'isolation et de confinement des pannes entre différents types de NLRI.

Les paramètres de configuration définis dans la Section 6.2.3 DEVRAIENT être initialisés aux valeurs par défaut suivantes:

  • La capacité Link-State NLRI est désactivée pour tous les voisins.

  • Le taux maximum auquel les Link-State NLRIs seront annoncés/retirés des voisins est défini à 200 mises à jour par seconde.

L'extension proposée n'est activée entre pairs BGP qu'après négociation de capacité. De plus, les extensions peuvent être activées/désactivées sur une base de pair individuel (voir Section 6.2.3), de sorte que l'extension peut être déployée progressivement dans le réseau.

L'extension de protocole définie dans ce document ne pose pas de nouvelles exigences sur d'autres protocoles ou composants fonctionnels.

La fréquence des mises à jour Link-State NLRI pourrait interférer avec la distribution régulière de préfixes BGP. Un opérateur réseau PEUT utiliser une infrastructure Route-Reflector dédiée pour distribuer les Link-State NLRIs.

La distribution de Link-State NLRIs DEVRAIT être limitée à un seul domaine administratif, qui peut consister en plusieurs aires au sein d'un AS ou plusieurs AS.

Les procédures BGP existantes s'appliquent. De plus, une implémentation DEVRAIT permettre à un opérateur de:

  • Lister les voisins avec lesquels le locuteur échange des Link-State NLRIs.

Le groupe de travail IDR a documenté et continue de documenter des parties de la base d'informations de gestion et des modèles YANG pour gérer et surveiller les locuteurs BGP et les sessions entre eux. Il est actuellement estimé que la session BGP exécutant BGP-LS n'est pas substantiellement différente de toute autre session BGP et peut être gérée en utilisant les mêmes modèles de données.

Si une implémentation de BGP-LS détecte un attribut malformé, alors elle DOIT utiliser l'action 'Attribute Discard' conformément à [RFC7606], Section 2.

Une implémentation de BGP-LS DOIT effectuer les vérifications syntaxiques suivantes pour déterminer si un message est malformé.

  • La somme de tous les TLVs trouvés dans l'attribut BGP-LS correspond-elle à la longueur d'attribut de chemin BGP-LS?

  • La somme de tous les TLVs trouvés dans l'attribut BGP MP_REACH_NLRI correspond-elle à la longueur BGP MP_REACH_NLRI?

  • La somme de tous les TLVs trouvés dans l'attribut BGP MP_UNREACH_NLRI correspond-elle à la longueur BGP MP_UNREACH_NLRI?

  • La somme de tous les TLVs trouvés dans un attribut NLRI Node, Link ou Prefix Descriptor correspond-elle au champ Total NLRI Length des Node, Link ou Prefix Descriptors?

  • Un TLV de longueur fixe correspond-il au champ TLV Length dans ce document?

Une implémentation DEVRAIT permettre à l'opérateur de spécifier les voisins auxquels les Link-State NLRIs seront annoncés et desquels les Link-State NLRIs seront acceptés.

Une implémentation DEVRAIT permettre à l'opérateur de spécifier le taux maximum auquel les Link-State NLRIs seront annoncés/retirés des voisins.

Une implémentation DEVRAIT permettre à l'opérateur de spécifier le nombre maximum de Link-State NLRIs stockés dans la base d'informations de routage (RIB) d'un routeur.

Une implémentation DEVRAIT permettre à l'opérateur de créer des topologies abstraites qui sont annoncées aux voisins et créer différentes abstractions pour différents voisins.

Une implémentation DEVRAIT permettre à l'opérateur de configurer un Instance-ID 64 bits.

Une implémentation DEVRAIT permettre à l'opérateur de configurer une paire d'ASN et d'identifiants BGP-LS (Section 3.2.1.4) par ensemble d'inondation dans lequel le noeud participe.

Non applicable.

Une implémentation DEVRAIT fournir les statistiques suivantes:

  • Nombre total de mises à jour Link-State NLRI envoyées/reçues

  • Nombre de mises à jour Link-State NLRI envoyées/reçues, par voisin

  • Nombre de mises à jour Link-State NLRI reçues erronées, par voisin

  • Nombre total de Link-State NLRIs originés localement

Ces statistiques devraient être enregistrées comme des comptes absolus depuis le démarrage du système ou de la session. Une implémentation PEUT également améliorer ces informations en enregistrant des comptes de pic par seconde dans chaque cas.

Un opérateur DEVRAIT définir une politique d'importation pour limiter les mises à jour entrantes comme suit:

  • Rejeter toutes les mises à jour des pairs consommateurs.

Une implémentation DOIT avoir les moyens de limiter les mises à jour entrantes.

Dernière mise à jour le