Groupe de travail Réseau	E. Chen, MCI	
Request for Comments : 1998	T. Bates, cisco Systems      	
Catégorie : Information	août 1996	
Traduction Claude Brière de L'Isle		

Application de l'attribut BGP Communauté dans l'acheminement multi rattachement

Statut de ce mémoire
Le présent mémoire apporte des informations pour la communauté de l'Internet. Il ne spécifie aucune sorte de norme de l'Internet. La distribution du présent mémoire n'est soumise à aucune restriction.

Résumé
Le présent document présente une application de l'attribut BGP Communauté [RFC1997] qui simplifie la mise en œuvre et la configuration des politiques d'acheminement dans l'environnement multi fournisseurs de l'Internet. Il montre comment la configuration fondée sur la communauté peut être utilisée pour remplacer la personnalisation fondée sur le système autonome de l'attribut "LOCAL_PREF" de BGP, la méthode courante utilisée aujourd'hui. Non seulement la technique présentée simplifie la configuration et la gestion au niveau du fournisseur, mais elle représente aussi un changement de paradigme en ce qu'elle offre au consommateur le contrôle potentiel de sa propre politique d'acheminement par rapport à son fournisseur de service, ainsi que la capacité de faire la configuration de politique avec une granularité fondée sur le préfixe plutôt que celle plus courante fondée sur le système autonome (AS).

1.	Introduction

Dans l'Internet multi fournisseurs, il est courant qu'un abonné à un service (c'est-à-dire, un consommateur) ait plus d'un fournisseur de service (FAI), ou ait des arrangements pour une connectivité redondante à l'Internet mondial. Comme exposé dans la RFC1771 [1], les stratégies d'acheminement exigent habituellement dans ces cas une coordination entre l'abonné au service et ses fournisseurs, ce qui conduit normalement à la personnalisation des configurations de routeurs (par exemple, le "LOCAL_PREF" de BGP) non seulement par l'abonné, mais aussi par ses fournisseurs. Du fait du grand nombre d'abonnés que dessert un fournisseur, la personnalisation des configurations de routeurs au niveau du fournisseur peut poser des problèmes de gestion et d'adaptation.

Le présent document illustre une application de l'attribut Communauté de BGP qui simplifie la mise en œuvre des stratégies d'acheminement dans l'Internet multi fournisseurs. Plus précisément, la technique présentée utilise une configuration de "LOCAL_PREF" de BGP fondée sur la communauté, plutôt que sur le système autonome (AS) courant. Elle supprime essentiellement le besoin d'une configuration personnalisée de l'attribut "LOCAL_PREF" de BGP au niveau du fournisseur tout en maintenant le même niveau de fonctionnalité et de souplesse de l'acheminement.

Elle représente aussi un changement de paradigme en ce qu'elle donne au consommateur la possibilité de contrôler sa propre politique d'acheminement par rapport à son fournisseur de service, ainsi que la capacité de configurer la politique avec une granularité fondée sur le préfixe plutôt que celle fondée sur l'AS qui est couramment utilisée aujourd'hui.

2.	La configuration fondée sur l'AS et ses inconvénients

Comme exposé dans [3], dans l'Internet multi fournisseurs d'aujourd'hui, la configuration personnalisée de l'attribut "LOCAL_PREF" de BGP est souvent requise pour mettre en œuvre des stratégies courantes d'acheminement comme le partage de charge ou la sauvegarde. Il y a deux raisons principales à cela :

o	Le manque de mises en œuvre disponibles de logiciels d'acheminement qui prennent en charge l'attribut de préférence de destination (DPA, Destination Preference Attribute) spécifié dans [4].

	L'attribut DPA permet de spécifier une préférence globalement transitive de sorte que le trafic de retour favorise certains chemins. Comme exposé dans [3], l'attribut sera très utile pour influencer le choix du chemin entre ceux qui ont un "LOCAL_PREF" identique et une longueur de chemin d'AS égale.

o	Dans l'internet multi fournisseurs, il est courant qu'un fournisseur alloue des valeurs de "LOCAL_PREF" BGP supérieures aux chemins provenant de ses abonnés qu'à ceux qui proviennent des autres fournisseurs de service. Cette pratique apporte un certain degré de protection aux chemins de ses abonnés, et elle facilite la mise en œuvre de certaines stratégies d'acheminement. Elle complique cependant aussi la mise en œuvre des autres acheminements comme les arrangements de sauvegarde, et donc exige une configuration personnalisée de "LOCAL_PREF".

La Figure 1 montre un cas typique d'arrangement de sauvegarde dans l'Internet multi fournisseur. Dans la Figure 1, AS1 et AS2 sont tous deux des fournisseurs, et AS3 et AS4 sont des abonnés, respectivement de AS1 et AS2. AS3 a passé un accord bilatéral avec AS4 pour une sauvegarde mutuelle. C'est-à-dire que AS3 utiliserait sa liaison directe avec AS4 pour atteindre seulement AS4 dans des circonstances normales, et pour le transit dans le cas d'une défaillance entre AS3 et AS1. Pour réaliser cet accord d'acheminement, AS3 demande que son fournissseur AS1 ajuste sa configuration de "LOCAL_PREF" de telle sorte que AS1 atteigne AS4 via AS2.

                          +------+      +------+
                          | AS1  |------| AS2  |
                          +------+      +------+
                             |             |
                          +------+      +------+
                          | AS3  |------|  AS4 |
                          +------+      +------+

Figure 1 : Typical Backup Scenario

Du fait principalement de soucis d'adaptabilité et de gestion, la plupart des fournisseurs ne font la personnalisation de "LOCAL_PREF" que sur la base des AS, et non sur celle des préfixes IP. Si la configuration de "LOCAL_PREF" fondée sur le préfixe IP est nécessaire, une technique connue sous le nom de manipulation BGP de chemin d'AS peut être utilisée. Cependant, elle n'est actuellement disponible que dans les produits de certains fabricants.

Il y a plusieurs inconvénients à la pratique de la configuration de "LOCAL_PREF" fondée sur l'AS de BGP au niveau du fournisseur :

o	La mise en œuvre tend à être moins efficace du fait du processus de coordination et de configuration. Plus important, le processus doit être répété chaque fois que survient un changement (par exemple, l'ajout d'un nouvel AS).

o	La personnalisation fondée sur l'AS complique la configuration des routeurs et augmente la complexité du fonctionnement du réseau. Cela est devenu un problème d'adaptabilité sérieux pour les fournisseurs.

o	On ne peut pas mettre en œuvre la configuration fondée sur le préfixe sans manipulation du chemin d'AS (c'est à dire, sans utiliser de faux AS).

o	La mise à jour des configurations est parfois problématique.

3.	Comment peut aider l'attribut Communauté de BGP
3.1	Vue d'ensemble de l'attribut Communauté
L'attribut de chemin BGP Communauté est un attribut facultatif transitif de longueur variable [1], [2]. L'attribut consiste en un ensemble de quatre valeurs d'octet, chacune spécifiant une communauté. Les valeurs d'attribut Communauté sont codées en utilisant un numéro d'AS dans les deux premiers octets, les deux octets restants étant définis par l'AS. Comme défini dans la RFC1997 [2], une communauté est un groupe de destinations (c'est-à-dire, de préfixes) qui partagent un certain attribut commun. Chaque destination peut appartenir à plusieurs communautés. Tous les prefixes qui ont l'attribut Communauté appartiennent aux communautés énumérées dans l'attribut.

La communauté BGP permet de grouper un ensemble de préfixes et de mettre en application des décisions d'acheminement sur la base de l'identité du groupe.

Les communautés bien connues  NO_EXPORT (0xFFFFFF01) et NO_ADVERTISE (0xFFFFFF02) sont intuitives, et peuvent être utilisées pour optimiser l'acheminement et pour améliorer l'agrégation de chemins.

3.2	Configuration fondée sur Communauté
Avec l'attribut Communauté de BGP [2], un fournisseur peut maintenant utiliser une configuration de "LOCAL_PREF" de BGP fondée sur la communauté, plutôt que fondée sur l'AS. Le fournisseur a d'abord besoin de se coordonner avec ses abonnés pour qu'un ensemble de communautés soient transposées en certaines valeurs de "LOCAL_PREF" de BGP. Le fournisseur peut alors appliquer une configuration BGP uniforme à tous ceux de ses abonnés qui voudraient suivre des chemins portant les valeurs de la communauté, et régler les valeurs appropriées de "LOCAL_PREF" BGP en conséquence. Un abonné qui demande la personnalisation de la configuration de "LOCAL_PREF" BGP de son fournisseur peut simplement envoyer les valeurs de communauté appropriées dans ses annonces d'acheminement.

Les avantages majeurs de l'utilisation de cette technique sont :

o	que l'abonné a le plein contrôle du processus, qui est assez logique car le consommateur est en position de mieux comprendre sa propre topologie et les exigences de la politique d'acheminement ;

o	que les effets de la personnalisation fondée sur le chemin dans la configuration de "LOCAL_PREF" BGP par les fournisseurs peuvent maintenant être atteints, et donc suppriment le besoin dans certains cas des manipulations de chemin d'AS ;

o	qu'il règle le problème de l'adaptabilité des fournisseurs car il répartit les travail de configuration entre les consommateurs quio demandent la personnalisation.
4.	Exemple de mise en œuvre réelle
MCI fait actuellement un usage lourd de la valeur d'attribut "LOCAL_PREF" de BGP au titre de son processus de configuration de politique d'acheminement. Différentes valeurs de "LOCAL_PREF" BGP sont allouées pour des chemins provenant de différentes sources. Le tableau 1 détaille ces valeurs :

Catégorie	LOCAL_PREF	
Chemins d'abonnés	100	
Chemins de sauvegarde d'abonnés	90	
Autres chemins de FAI	80	
Sauvegardes d'abonné/fournisseur	70	

Tableau 1 : Valeurs de LOCAL_PREF définies

Note :	o	La valeur '100' est la valeur par défaut utilisée au sein de notre configuration de réseau.
	o	Dans la plupart des cas, l'attribut MED établi par un consommateur est suffisant pour les chemins de sauvegarde d'abonné (par exemple, T1 sauvegarde T3). Cependant, dans certains cas, la configuration de "LOCAL_PREF" sera encore nécessaire jusqu'à ce que l'attribut DPA de BGP soit disponible.

Pour utiliser l'attribut Communauté de BGP, plusieurs valeurs de communauté (le numéro d'AS : 3561 = 0x0DE9 de MCI) ont été définies pour être utilisées par les consommateurs pour étiqueter les chemins afin que les valeurs appropriées de "LOCAL_PREF" soient configurées. Le tableau 2 fait la liste des valeurs appropriées de l'attribut Communauté (et les transpositions de Communauté en LOCAL_PREF) :

Communauté	LOCAL_PREF	
3561:70 (0x0DE90046)	70	
3561:80 (0x0DE90050)	80	
3561:90 (0x0DE9005A)	90	

Tableau 2 : Transposition de Communauté à LOCAL_PREF

Un consommateur qui demande à MCI de configurer des valeurs de "LOCAL_PREF" BGP autres que par défaut peut étiqueter ses chemins avec les communautés définies. Les valeurs de communauté peuvent être configurées sur la base soit d'une liste de chemins d'AS, soit d'une liste d'adresses d'accès IP. Un exemple de configuration spécifique du logiciel de cisco systems est donné à l'Appendice A pour montrer comment cela peut être réalisé.

Une configuration BGP uniforme (voir à l'Appendice B, encore un logiciel spécifique de cisco systems) est appliquée par MCI pour échanger du trafic avec les consommateurs qui configurent les valeurs appropriées de "LOCAL_PREF" sur la base des communautés reçues.

Cette technique a été vérifiée et est utilisée avec plusieurs consommateurs, et la réponse a été très positive. Nous sommes sur le point de faire migrer toutes les autres configurations personnalisées de "LOCAL_PREF" BGP vers cette approche de configuration fondée sur la communauté uniforme.

5.	Références

[1]	Y. Rekhter, T. Li , "Protocole de routeur frontière v. 4 (BGP-4)", RFC1771, mars 1995. (Obsolète, voir RFC4271)
[2]	R. Chandra, P. Traina, T. Li, "Attribut Community de BGP", RFC1997, août 1996. (P.S.)
[3]	Chen, E., and T. Bates, "Current Practice of Implementing Symmetric Routing and Load Sharing in the Multi-Provider Internet", Travail en cours.
[4]	Chen, E., and T. Bates, "Destination Preference Attribute for BGP", Travail en cours.
[5]	Chen, E., and T. Bates, "Application of the BGP Destination Preference Attribute in Implementing Symmetric Routing", Travail en cours.
[6]	cisco systems, "cisco IOS Software Version 10.3 Router Products Configuration Guide (Addendum)", mai 1995.

6.	Considérations pour la sécurité

Les questions de sécurité ne sont pas abordées dans le présent mémoire.

7.	Remercieents

Les auteurs tienne à remercier tout particulièrement Ravi Chandra, Tony Li et Paul Traina de cisco systems pour avoir imaginé et mis en œuvre l'attribut Communauté.

8.	 Adresse des auteurs

Enke Chen	Tony Bates	
MCI	cisco Systems	
2100 Reston Parkway	170 West Tasman Drive	
Reston, VA 22091	San Jose, CA 95134	
USA	USA	
téléphone : +1 703 715 7087	téléphoneh: +1 408 527 2470	
mél : enke@mci.net 	mél : tbates@cisco.com 	

Appendices

Ces appendices font la liste des exemples de configuration spécifiques de logiciel cisco systems pour configurer des communautés, et des définitions de transposition de chemin uniforme qui établissent les valeurs appropriées de "LOCAL_PREF" sur la base des valeurs correspondantes de communauté. Ces exemples ne sont donnés que pour montrer un exemple réel de la façon dont l'effet recherché exposé dans le présent document peut être réalisé. Prière de se référer à [6] pour des informations plus spécifiques sur la configuration et la syntaxe de cisco .

Appendice A	Configuration de Communauté

Les valeurs de communauté peuvent être configurées sur la base 'une liste de chemins d'AS ou sur la base d'une liste d'adresses d'accès IP. Voici un exemple qui comporte les ceux cas :

!!
router bgp xxxx
neighbor x.x.x.x remote-as 3561
neighbor x.x.x.x filter-list 20 out
neighbor x.x.x.x route-map config-community out
neighbor x.x.x.x send-community
!
!!# correspond à tout
ip as-path access-list 1 permit .*
!
!!# liste des AS consommateurs
ip as-path access-list 20 permit ^$
ip as-path access-list 20 permit ^64700_
ip as-path access-list 20 deny .*
!
!!# Chemins d'AS sur la base de la sauvegarde correspondant pour un autre consommateur de FAI
ip as-path access-list 40 permit _64710_
ip as-path access-list 40 permit _64711_
ip as-path access-list 40 deny .*
!
!!# Transposition de chemin
route-map config-community permit 10
match as-path 40
set community 0x0DE90046
route-map config-community permit 20
match as-path 1
!

Note : La communauté peut aussi être configurée sur la base des préfixes IP au lieur des numéros d'AS. Par exemple,

!
access-list 101 permit ip 192.160.154.0 0.0.0.0 255.255.255.0 0.0.0.0
!
route-map config-community permit 10
match ip address 101
set community 0x0DE90046
route-map config-community permit 20
match as-path 1
!

Appendice B	Configuration de transposition de chemin uniforme

Voici la transposition de chemin uniforme qui peut être utilisée pour tous les consommateurs BGP :

!!# chemins principalement via un autre FAI
ip community-list 70 permit 0x0DE90046
ip community-list 70 deny
!
!!# chemins aussi rattachés à un autre FAI, mais avec DPA ou avec la ongueur du chemin d'AS comme départage
ip community-list 80 permit 0x0DE90050
ip community-list 80 deny
!
!!# Chemins de sauvegarde du consommateur
ip community-list 90 permit 0x0DE9005A
ip community-list 90 deny
!
!!# la transposition de chemin appliquée aux consommateurs BGP
route-map set-customer-local-pref permit 10
match community 70
set local-preference 70
route-map set-customer-local-pref permit 20
match community 80
set local-preference 80
route-map set-customer-local-pref permit 30
match community 90
set local-preference 90
route-map set-customer-local-pref permit 40
match as-path 1
set local-preference 100
!