3. Overview of Operations (aperçu du fonctionnement)
3. Overview of Operations (aperçu du fonctionnement)
Lorsqu'un BGP speaker [RFC4271] qui prend en charge l'annonce de capacités envoie un message OPEN à son BGP peer, le message PEUT inclure un Optional Parameter appelé Capabilities. Ce paramètre liste les capacités prises en charge par le locuteur.
Un BGP speaker détermine les capacités prises en charge par son pair en examinant la liste des capacités présentes dans le Capabilities Optional Parameter porté par le message OPEN que le locuteur reçoit du pair.
Un BGP speaker qui prend en charge une capacité particulière peut utiliser cette capacité avec son pair après avoir déterminé (comme décrit ci-dessus) que le pair prend en charge cette capacité. En termes simples, une capacité donnée peut être utilisée sur un peering si cette capacité a été annoncée par les deux pairs. Si l'un ou l'autre pair ne l'a pas annoncée, la capacité ne peut pas être utilisée.
Un BGP speaker détermine que son pair ne prend pas en charge l'annonce de capacités si, en réponse à un message OPEN portant le Capabilities Optional Parameter, le locuteur reçoit un message NOTIFICATION dont l'Error Subcode est Unsupported Optional Parameter. (Il s'agit d'une conséquence de la spécification de base BGP-4 [RFC4271] et non d'une nouvelle exigence.) Dans ce cas, le locuteur DEVRAIT tenter de rétablir une connexion BGP avec le pair sans envoyer au pair le Capabilities Optional Parameter.
Si un BGP speaker qui prend en charge une certaine capacité détermine que son pair ne prend pas en charge cette capacité, le locuteur PEUT envoyer un message NOTIFICATION au pair et mettre fin au peering (voir la section « Extensions to Error Handling » pour plus de détails). Par exemple, un BGP speaker peut devoir mettre fin au peering s'il a établi le peering pour échanger des routes IPv6 et détermine que son pair ne prend pas en charge les Multiprotocol Extensions for BGP-4 [RFC4760]. L'Error Subcode du message NOTIFICATION est alors Unsupported Capability. Le message DOIT contenir la ou les capacités qui amènent le locuteur à envoyer le message. La décision d'envoyer le message et de mettre fin au peering est locale au locuteur. Si le peering est terminé, un tel peering NE DEVRAIT PAS être rétabli automatiquement.
Si un BGP speaker reçoit de son pair une capacité qu'il ne prend pas en charge ou ne reconnaît pas, il DOIT ignorer cette capacité. En particulier, le message NOTIFICATION Unsupported Capability NE DOIT PAS être généré et la session BGP NE DOIT PAS être terminée en réponse à la réception d'une capacité non prise en charge par le locuteur local.