5. Fonctionnement

L'identifiant de chemin spécifié dans la Section 3 peut être utilisé pour annoncer plusieurs chemins pour le même préfixe d'adresse sans que les annonces subséquentes ne remplacent les précédentes. Hormis le fait que cela est maintenant possible, les règles d'annonce de route de [RFC4271] ne sont pas modifiées. En particulier, une nouvelle annonce pour un préfixe d'adresse donné et un identifiant de chemin donné remplace une annonce précédente pour le même préfixe d'adresse et identifiant de chemin. Si un locuteur BGP reçoit un message pour retirer un préfixe avec un identifiant de chemin non vu auparavant, il DEVRAIT (SHOULD) l'ignorer silencieusement.

Pour qu'un locuteur BGP puisse envoyer plusieurs chemins à son pair, ce locuteur BGP DOIT (MUST) annoncer la capacité ADD-PATH avec le champ Envoi/Réception défini à 2 ou 3, et DOIT (MUST) recevoir de son pair la capacité ADD-PATH avec le champ Envoi/Réception défini à 1 ou 3, pour le <AFI, SAFI> correspondant.

Un locuteur BGP DOIT (MUST) suivre les procédures définies dans [RFC4271] lors de la génération d'un message UPDATE pour un <AFI, SAFI> particulier à un pair, à moins que le locuteur BGP n'annonce la capacité ADD-PATH au pair indiquant sa capacité à envoyer plusieurs chemins pour le <AFI, SAFI>, et reçoive également la capacité ADD-PATH du pair indiquant sa capacité à recevoir plusieurs chemins pour le <AFI, SAFI>, auquel cas le locuteur DOIT (MUST) générer une mise à jour de route pour le <AFI, SAFI> basée sur la combinaison du préfixe d'adresse et de l'identifiant de chemin, et utiliser les encodages NLRI étendus spécifiés dans ce document. Le pair DOIT (SHALL) agir en conséquence lors du traitement d'un message UPDATE lié à un <AFI, SAFI> particulier.

Un locuteur BGP DEVRAIT (SHOULD) inclure la meilleure route [RFC4271] lorsque plus d'un chemin est annoncé à un voisin, sauf s'il s'agit d'un chemin reçu de ce voisin.

Comme les identifiants de chemin sont attribués localement et peuvent ou non être persistants à travers un redémarrage du plan de contrôle d'un locuteur BGP, une implémentation DEVRAIT (SHOULD) prendre un soin particulier afin que le plan de transfert sous-jacent d'un « locuteur récepteur » tel que décrit dans [RFC4724] ne soit pas affecté pendant le redémarrage gracieux d'une session BGP.