Groupe de travail Réseau	T. Li, Redback Networks, Inc.	
Request for Comments : 5302	H. Smit	
Rend obsolète la RFC 2966	T. Przygienda, Z2 Sagl	
RFC mise à jour : 1195	octobre 2008	
Catégorie : Sur la voie de la normalisation	Traduction Claude Brière de L'Isle	

Distribution de préfixe sur l'ensemble d'un domaine avec IS-IS à deux niveaux

Statut de ce mémoire
Le présent document spécifie un protocole de l’Internet en cours de normalisation pour la communauté de l’Internet, et appelle à des discussions et suggestions pour son amélioration. Prière de se référer à l’édition en cours des "Normes officielles des protocoles de l’Internet" (STD 1) pour connaître l’état de la normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.

Notice de copyright
Copyright (C) The Internet Society (2008).

Résumé
Le présent document décrit des extensions au protocole de système intermédiaire à système intermédiaire (IS-IS) pour la prise en charge de l'acheminement optimal au sein d'un domaine à deux niveaux. Le protocole IS-IS est spécifié dans la norme ISO 10589, avec des extensions pour la prise en charge de IPv4 spécifiées dans la RFC 1195. Le présent document remplace la RFC 2966.

Le présent document étend la sémantique présentée dans la RFC 1195 afin qu'un domaine d'acheminement fonctionnant avec des systèmes intermédiaires (IS, Intermediate System) de niveau 1 et 2 (routeurs) puisse distribuer des préfixes IP entre le niveau 1 et le niveau 2, et vice versa. Cette distribution exige certaines restrictions pour s'assurer que des boucles de transmission persistantes ne se forment pas .Le but de cette distribution de préfixes à l'échelle du domaine est d'augmenter la granularité des informations d'acheminement au sein du domaine.
Table des matières
1. Introduction	1
1.1 Motivations de la distribution de préfixe à l'échelle du domaine	2
1.2 Adaptabilité	3
1.3 Langage des exigences	3
2. Proposition de syntaxe et sémantique pour les routes inter zones L2->L1	3
2.1 Précisions sur le type de route externe et le type de métrique externe	4
2.2 Définition de préfixes IP externes dans les LSP de niveau 1	4
3. Types des routes IP dans IS-IS et leur ordre de préférence	4
3.1 Vue d'ensemble des types de préfixes IP dans les PDU d'état de liaison IS-IS	5
3.2 Ordre de préférence pour tous les types de routes IP dans IS-IS	6
3.3 Notes supplémentaires sur les préfixes à accepter ou annoncer	6
4. Inter opérabilité avec les anciennes mises en œuvre	7
5. Comparaison avec les autres propositions	7
6. Considérations sur la sécurité	8
7. Références	8
7.1 Références normatives	8
7.2 Références pour information	8
Adresse des auteurs	8
Déclaration complète de droits de reproduction	8

 	1.	Introduction

Le présent document décrit des extensions au protocole de système intermédiaire à système intermédiaire (IS-IS, Intermediate System to Intermediate System) pour prendre en charge l'acheminement optimal au sein d'un domaine à deux niveaux. Le protocole IS-IS est spécifié dans la norme [ISO-10589], avec les extensions pour prendre en charge IPv4 spécifiées dans la [RFC1195].

Le présent document remplace la [RFC2966], qui était un document d'information. Le présent document est sur la voie de la normalisation. Aucun autre changement intentionnel de substance n'a été fait.

Le présent document étend la sémantique présentée dans la RFC 1195 afin qu'un domaine d'acheminement fonctionnant avec les deux niveaux 1 et 2 de systèmes intermédiaire (routeurs) puisse distribuer des préfixes IP entre les niveaux 1 et 2, et vice versa. Cette distribution exige certaines restrictions pour assurer que des boucles de transmission persistantes ne se forment pas. Le but de cette distribution de préfixes à l'échelle du domaine est d'augmenter la granularité des informations d'acheminement au sein du domaine.

Un domaine d'acheminement IS-IS (autrement dit, un système autonome fonctionnant avec IS-IS) peut être partagé en plusieurs zones de niveau 1 (L1) et un sous ensemble connecté de niveau 2 (L2) de la topologie qui interconnecte toutes les zones de L1. Au sein de chaque zone de L1, tous les routeurs échangent des informations d'état de liaison. Les routeurs de niveau 2 échangent aussi des informations d'état de liaison de L2 pour calculer les chemins entre les zones.

La RFC 1195 définit les triplets de Type, Longueur et Valeur (TLV) qui sont utilisés pour transporter les informations d'acheminement IPv4 dans IS-IS. La RFC 1195 spécifie aussi la sémantique et les procédures d'interactions entre niveaux. Précisément, les routeurs dans une zone L1 vont échanger les informations au sein de la zone L1. Pour les destinations IP non trouvées dans les préfixes de la base de données de L1, le routeur L1 devrait transmettre les paquets au plus proche routeur qui est à la fois dans L1 et L2 (c'est-à-dire, un routeur L1L2) avec le "bit rattaché" établi dans son unité de données de protocole d'état de liaison L1.

Aussi, selon la RFC 1195, un routeur L1L2 devrait être configuré manuellement avec un ensemble de préfixes qui résument les préfixes IP accessibles dans cette zone L1. Ces résumés sont injectés dans L2. La RFC 1195 ne spécifie pas d'autres interactions entre L1 et L2 pour les préfixes IPv4.

 	1.1	Motivations de la distribution de préfixe à l'échelle du domaine
Les mécanismes spécifiés dans la RFC 1195 sont appropriés dans de nombreuses situations et conduisent à d'excellentes propriétés d'adaptabilité. Cependant, dans certaines circonstances, l'administrateur de domaine peut souhaiter sacrifier un peu d'adaptabilité et distribuer des informations plus spécifiques que ce qui est décrit par la RFC 1195. Ce paragraphe discute des diverses raisons pour lesquelles l'administrateur de domaine peut souhaiter faire un tel compromis.

Une raison majeure pour distribuer plus d'informations de préfixes est d'améliorer la qualité des chemins résultants. Une propriété bien connue de l'agrégation de préfixes ou de tout mécanisme d'abstraction est qu'il résulte nécessairement en une perte d'informations. Cette perte d'informations à son tour résulte en un calcul de chemin fondé sur moins d'informations, ce qui a fréquemment pour résultat que les chemins ne sont pas optimaux.

Un simple exemple peut servir à démontrer cela de façon adéquate. Supposons qu'une zone L1 ait deux routeurs L1L2 qui annoncent tous deux un seul résumé de tous les préfixes dans la zone L1. Pour accéder à une destination dans la zone L1, tout autre routeur L2 va calculer le plus court chemin jusqu'à un des deux routeurs L1L2 pour cette zone. Supposons, par exemple, que les deux routeurs L1L2 soient équidistants de la source L2 et que la source L2 choisisse arbitrairement un routeur L1L2. Ce routeur peut n'être pas le routeur optimal vu de la topologie de L1. En fait, ce peut être le cas que le chemin du routeur L1L2 choisi au routeur de destination traverse le routeur L1L2 qui n'a pas été choisi. Si des informations topologiques plus détaillées ou des informations de métrique plus détaillées avaient été disponibles au routeur de source L2, il aurait pu faire un calcul de chemin plus optimal.

Cette situation est symétrique en ce que un routeur L1 n'a pas d'informations sur les préfixes dans L2 ou dans une zone L1 différente. En utilisant le plus proche routeur L1L2, ce L1L2 injecte effectivement un chemin par défaut sans informations de métrique dans la zone L1. Le calcul de chemin qu'effectue le routeur L1 est similairement sous optimal.

À côté de l'optimisation des chemin calculés, il y a deux autres pilotes significatifs pour la distribution à l'échelle du domaine des informations de préfixe.

Quand un routeur apprend plusieurs chemins possibles à des destinations externes via BGP, il va choisir seulement un de ces chemins pour l'installer dans le tableau de transmission. Un des facteurs du choix de chemins de BGP est le coût IGP de l'adresse de prochain bond BGP. De nombreux fournisseurs de réseaux dépendent de cette technique, qui est connue comme "acheminement le plus court de sortie". Si un routeur L1 ne connaît pas la métrique IGP exacte pour tous les locuteurs BGP dans les autres zones L1, il ne peut pas faire un acheminement le plus court de sortie effectif.

Le troisième pilote est la pratique courante d'utiliser la métrique IGP (IS-IS) au titre du discriminant BGP multi sorties (MED, Multi-Exit Discriminator). La valeur de la MED est annoncée aux autres domaines et est utilisée pour informer les autres domaines du point d'entrée optimal dans le domaine courant. La pratique courante est de prendre la métrique IS-IS et de l'insérer dans la valeur de MED. Cela tend à causer l'entrée du trafic externe dans le domaine au point le plus proche du routeur de sortie. Noter que le domaine receveur PEUT, sur la base de sa politique, choisir d'ignorer le MED qui est annoncée. Cependant, la pratique courante est de distribuer la métrique IGP de cette façon afin d'optimiser l'acheminement chaque fois que possible. Ceci est possible dans les réseaux actuels qui sont seulement sur une zone, mais devient problématique si une hiérarchie doit être installée dans le réseau. Ceci est là encore parce que la perte des informations de métrique de bout en bout signifie que la valeur de MED ne va pas refléter la vraie distance à travers le domaine annoncé. La pleine distribution des informations de préfixe au sein du domaine résoudrait ce problème, car cela permettrait un calcul précis de la métrique IS-IS à travers le domaine, résultant en une valeur précise présentée dans le MED.

 	1.2	Adaptabilité
L'inconvénient d'une distribution de préfixe à l'échelle du domaine comme décrit ci-dessus est que cela a un impact sur l'adaptabilité de IS-IS. Les zones au sein de IS-IS aident à l'adaptabilité en ce que les LSP sont contenus dans une seule zone. Cela limite la taille de la base de données d'état de liaisons, ce qui à son tour limite la complexité du calcul des plus courts chemins.

De plus, l'agrégation des informations de préfixes aide à l'adaptabilité en ce que l'abstraction des informations de préfixes supprime un grand nombre des éléments de données à transporter et réduit le nombre de routes à calculer.

On devrait noter que la distribution de préfixes à l'échelle d'un domaine impacte l'adaptabilité de IS-IS à cet égard. Elle augmente le nombre de préfixes dans le domaine. Il en résulte une consommation accrue de mémoire, des exigences de transmission et de calcul dans tout le domaine.

Il faut aussi noter que la distribution de préfixes à l'échelle du domaine n'a pas d'effet sur le premier aspect de l'adaptabilité, à savoir l'existence de zones et la limitation de la distribution de la base de données d'état de liaison.

Donc, le résultat net est que l'introduction de la distribution de préfixes à l'échelle du domaine dans un réseau anciennement plat, constitué d'une seule zone, est un clair bénéfice pour l'adaptabilité de ce réseau. Cependant, c'est un compromis et cela ne donne pas l'adaptabilité maximale disponible avec IS-IS. Les domaines qui choisissent d'utiliser cette facilité devraient être conscients du compromis entre adaptabilité et optimisation et devraient provisionner et surveiller leurs réseaux en conséquence. Les lignes directrices normales de provisionnement qui s'appliqueraient à un déploiement pleinement hiérarchique de IS-IS ne vont pas s'appliquer à ce type de configuration.

 	1.3	Langage des exigences
Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" en majuscules dans ce document sont à interpréter comme décrit dans le BCP 14, [RFC2119].

 	2.	Proposition de syntaxe et sémantique pour les routes inter zones L2->L1

Le présent document définit la syntaxe de comment annoncer les chemins de niveau 2 dans les LSP de niveau 1. Le codage est une extension du codage de la RFC 1195.

Dans une certaine mesure, dans IS-IS le cœur de réseau de niveau 2 peut être vu lui-même comme une zone séparée. La RFC 1195 définit que tous les routeurs L1L2 peuvent annoncer les chemins IP qui ont été appris via l'acheminement L1 dans L2. Ces chemins peuvent être considérés comme inter zones. La RFC 1195 définit que ces chemins inter zones L1->L2 doivent être annoncés dans les LSP L2 dans le TLV "Informations d'accessibilité interne IP" (TLV 128). Les chemins L2 intra zone sont aussi annoncés dans les LSP L2 dans un TLV "Informations d'accessibilité interne IP". Donc, les chemins inter zones L1->L2 ne sont pas distinguables des chemins L2 intra zone.

La RFC 1195 ne définit pas les chemins L2->L1 inter zones. Une extension simple va être de permettre à un routeur L1L2 d'annoncer les chemins appris via l'acheminement L2 dans son LSP L1. Cependant, pour empêcher les boucles d'acheminement, les routeurs L1L2 NE DOIVENT PAS ré-annoncer dans L2 les chemins inter zones L2->L1 qu'ils apprennent via l'acheminement L1. Donc, il doit y avoir un moyen pour distinguer les chemins inter zones L2->L1 des chemins intra zone L1. La [RFC5305] définit le bit "actif/inactif" à cette fin dans le TLV Accessibilité IP étendue (TLV 135). La RFC 1195 définit les TLV 128 et 130 pour contenir les chemins IP. Les TLV 128 et 130 ont un champ Métrique qui consiste en quatre métriques de type de service (TOS, Type Of Service). La première métrique, dite "métrique par défaut", a le bit de poids fort réservé (bit 8). Les routeurs doivent régler ce bit à zéro à l'émission, et l'ignorer à réception.

Le présent document redéfinit ce bit de poids fort dans le champ Métrique par défaut des TLV 128 et 130 comme étant le bit actif/inactif. Les routeurs L1L2 DOIVENT régler ce bit à un pour les préfixes qui sont déduits de l'acheminement L2 et sont annoncés dans les LSP L1. Le bit DOIT être réglé à zéro pour tous les autres préfixes IP dans les LSP L1 ou L2. Les préfixes avec le bit activé/désactivé établi qui sont appris via l'acheminement L1 NE DOIVENT PAS être ré-annoncés par les routeurs L1L2 dans L2.

 	2.1	Précisions sur le type de route externe et le type de métrique externe
La RFC 1195 définit deux TLV pour porter les préfixes IP. Le TLV 128 est défini comme "Informations d'accessibilité interne IP", et devrait être utilisé pour porter les préfixes IP qui sont directement connectés aux routeurs IS-IS. Le TLV 130 est défini comme "Informations d'accessibilité externe IP", et devrait être utilisé pour porter les chemins appris de l'extérieur du domaine IS-IS. La RFC 1195 ne documente le TLV de type 130 que pour les LSP de niveau 2.

La RFC 1195 définit aussi deux types de métriques. Les métriques de type métrique interne devraient être utilisées quand la métrique est comparable aux métriques utilisées pour pondérer les liaisons à l'intérieur du domaine IS-IS. Les métriques de type métrique externe devraient être utilisées si la métrique d'un préfixe IP ne peut pas être directement comparée aux métriques internes. Le type de métrique externe peut seulement être utilisé pour les préfixes IP externes. Un résultat direct est que les métriques de type externe ne devraient jamais se voir dans le TLV 128.

Pour empêcher les confusions, le présent document déclare que quand un routeur calcule des chemins IP, il DOIT donner la même préférence aux chemins IP annoncés dans un TLV "Informations d'accessibilité interne IP" et aux chemins IP annoncés dans un TLV "Informations d'accessibilité externe IP". La RFC 1195 déclare cela assez clairement dans la note du paragraphe 3.10.2, point 2c). Le présent document ne change pas cette règle de préférence.

Note : les chemins internes (chemins pour les destinations annoncées dans le champ "Informations d'accessibilité interne IP" ) et les chemins externes qui utilisent des métriques internes (chemins pour les destinations annoncées dans le champ "Informations d'accessibilité externe IP", avec une métrique de type "interne") sont traites de façon identique pour les besoins de l'ordre de préférence de chemin, et le calcul de Dijkstra.

Cependant, les chemins IP annoncés dans les "Informations d'accessibilité externe IP" avec le type de métrique externe DOIVENT recevoir une préférence moindre que les mêmes chemins IP annoncés avec le type de métrique interne, sans considération de la valeur des métriques.

Bien que les routeurs IS-IS NE DOIVENT PAS donner une préférence différente aux préfixes IP appris via des "Informations d'accessibilité interne IP" et "Informations d'accessibilité externe IP" quand ils exécutent le calcul de Dijkstra, les routeurs qui mettent en œuvre plusieurs IGP sont libres d'utiliser cette distinction entre chemins internes et externes pour comparer les chemins déduits de différents IGP à inclure dans leur base de données d'informations d'acheminement mondial (RIB, Routing Information Base).

 	2.2	Définition de préfixes IP externes dans les LSP de niveau 1
La RFC 1195 ne définir pas de TLV "Informations d'accessibilité externe IP" pour les LSP L1. Cependant, il n'y a pas de raison pour qu'une mise en œuvre de IS-IS ne pourrait pas permettre la redistribution de chemins externes dans L1. Certaines mises en œuvre de IS-IS permettent déjà aux administrateurs de réseau de le faire. Le présent document relâche les restrictions de la RFC 1195 et permet l'inclusion du TLV "Informations d'accessibilité externe IP" dans les LSP L1.

La RFC 1195 définit que les chemins IP appris via l'acheminement L1 doivent toujours être annoncés dans les LSP L2 dans un TLV "Informations d'accessibilité interne IP". Maintenant que le présent document permet les TLV "Informations d'accessibilité externe IP" dans les LSP L1 et permet l'annonce des chemins appris via l'acheminement L2 dans L1, la règle ci-dessus a besoin d'une extension.

Quand un routeur L1L2 annonce un chemin L1 dans L2, et que le chemin L1 a été appris via un préfixe annoncé dans un TLV "Informations d'accessibilité externe IP", ce routeur L1L2 DEVRAIT annoncer ce préfixe dans son LSP L2 au sein d'un TLV "Informations d'accessibilité externe IP". Les chemins L1 appris via un TLV "Informations d'accessibilité interne IP" DEVRAIENT quand même être annoncés dans un TLV "Informations d'accessibilité interne IP". Ces règles devraient aussi être appliquées lors de l'annonce des chemins IP déduits de l'acheminement L2 dans L1. Bien sûr, dans ce cas, le bit activé/désactivé DOIT aussi être établi.

La RFC 1195 définit que si un routeur voit le même préfixe externe annoncé par deux routeurs ou plus avec la même métrique externe, il doit choisir le chemin qui est annoncé par le routeur qui est le plus proche de lui. On devrait noter que maintenant que les chemins externes peuvent être annoncés de L1 dans L2, et vice versa, le routeur qui annonce un préfixe externe dans son LSP pourrait ne pas être le routeur qui a injecté à l'origine ce préfixe dans le domaine IS-IS. Donc, il est moins utile d'annoncer les chemins externes avec des métriques externes dans les autres niveaux.

 	3.	Types des routes IP dans IS-IS et leur ordre de préférence

La RFC 1195 et le présent document définissent plusieurs façons d'annoncer les chemins IP dans IS-IS. Quatre variables sont impliquées.

1.	Le niveau du LSP dans lequel le chemin est annoncé. Il y a actuellement deux valeurs possibles : niveau 1 et niveau 2.

2.	Le type de chemin, qui peut être déduit du type de TLV dans lequel le préfixe est annoncé. Les chemins internes sont annoncés dans les TLV Informations d'accessibilité interne IP (TLV 128), et les chemins externes sont annoncés dans les TLV Informations d'accessibilité externe IP (TLV 130).

3.	Le type de métrique : interne ou externe. Le type de métrique est déduit du bit Type de métrique interne/externe dans le champ Métrique (bit 7).

4.	Le fait que ce chemin est descendu dans la hiérarchie, et donc ne peut plus être annoncé. Cette information peut être déduite du bit nouvellement défini activé/désactivé dans le champ Métrique par défaut.

 	3.1	Vue d'ensemble des types de préfixes IP dans les PDU d'état de liaison IS-IS
La combinaison Informations d'accessibilité interne IP et Type de métrique externe n'est pas permise. Aussi, le bit activé/désactivé NE DOIT PAS être établi dans les LSP L2. Cela nous laisse avec 8 différents types d'annonces IP dans IS-IS. Cependant, il y a plus de 8 raisons pour que les préfixes IP soient annoncés dans IS-IS. La liste suivante décrit les types de préfixes IP et comment ils sont codés.

Chemin L1 intra zone : ils sont annoncés dans les LSP L1, dans le TLV 128. Le bit activé/désactivé est réglé à zéro, le type de métrique est métrique interne. Ces préfixes IP sont directement connectés au routeur annonceur.

Chemins L1 externes : ils sont annoncés dans les LSP L1, dans le TLV 130. Le bit activé/désactivé est réglé à zéro, le type de métrique est métrique interne. Ces préfixes IP sont appris des autres IGP, et sont ne sont généralement pas directement connectés au routeur annonceur.

Chemins L2 intra zone : ils sont annoncés dans les LSP L2, dans le TLV 128. Le bit activé/désactivé est réglé à zéro, le type de métrique est métrique interne. Ces préfixes IP sont directement connectés au routeur annonceur. Ces préfixes ne peuvent pas être distingués des chemins L1->L2 inter zones.

Chemins L2 externes : ils sont annoncés dans les LSP L2, dans le TLV 130. Le bit activé/désactivé est réglé à zéro, le type de métrique est métrique interne. Ces préfixes IP sont appris des autres IGP, et ne sont généralement pas directement connectés au routeur annonceur. Ces préfixes ne peuvent pas être distingués des chemins L1->L2 inter zones externes.

Chemins L1->L2 inter zones : ils sont annoncés dans les LSP L2, dans le TLV 128. Le bit activé/désactivé est réglé à zéro, le type de métrique est métrique interne. Ces préfixes IP sont appris via l'acheminement L1, et ont été déduits durant le calcul de plus court chemin en premier (SPF, Shortest Path First) de L1 des préfixes annoncés dans les LSP L1 dans le TLV 128. Ces préfixes ne peuvent pas être distingués des chemins L2 intra zone.

Chemins L1->L2 inter zones externes : ils sont annoncés dans les LSP L2, dans le TLV 130. Le bit activé/désactivé est réglé à zéro, le type de métrique est métrique interne. Ces préfixes IP sont appris via l'acheminement L1, et ont été déduits durant le calcul de SPF L1 des préfixes annoncés dans les LSP L1 dans le TLV 130. Ces préfixes ne peuvent pas être distingués des chemins L2 externes.

Chemins L2->L1 inter zones : ils sont annoncés dans les LSP L1, dans le TLV 128. Le bit activé/désactivé est réglé à un, le type de métrique est métrique interne. Ces préfixes IP sont appris via l'acheminement L2, et ont été déduits durant le calcul de SPF L2 des préfixes annoncés dans le TLV 128.

Chemins L2->L1 inter zones externes : ils sont annoncés dans les LSP L1, dans le TLV 130. Le bit activé/désactivé est réglé à un, le type de métrique est métrique interne. Ces préfixes IP sont appris via l'acheminement L2, et ont été déduits durant le calcul de SPF L2 des préfixes annoncés dans les LSP L2 dans le TLV 130.

Chemins L1 externes avec métrique externe : ils sont annoncés dans les LSP L1, dans le TLV 130. Le bit activé/désactivé est réglé à zéro, le type de métrique est métrique externe. Ces préfixes IP sont appris des autres IGP, et ne sont généralement pas directement connectés au routeur annonceur.

Chemins L2 externes avec métrique externe : ils sont annoncés dans les LSP L2, dans le TLV 130. Le bit activé/désactivé est réglé à zéro, le type de métrique est métrique externe. Ces préfixes IP sont appris des autres IGP, et ne sont généralement pas directement connectés au routeur annonceur. Ces préfixes ne peuvent pas être distingués des chemins L1->L2 inter zones externes avec métrique externe.

Chemins L1->L2 inter zones externes avec métrique externe : ils sont annoncés dans les LSP L2, dans le TLV 130. Le bit activé/désactivé est réglé à zéro, le type de métrique est métrique externe. Ces préfixes IP sont appris via l'acheminement L1, et ont été déduits durant le calcul de SPF L1 des préfixes annoncés dans les LSP L1 dans le TLV 130 avec métriques externes. Ces préfixes ne peuvent pas être distingués des chemins L2 externes avec métrique externe.

Chemins L2->L1 inter zones externes avec métrique externe : ils sont annoncés dans les LSP L1, dans le TLV 130. Le bit activé/désactivé est réglé à un, le type de métrique est métrique externe. Ces préfixes IP sont appris via l'acheminement L2, et ont été déduits durant le calcul de SPF L1 des préfixes annoncés dans les LSP L2 dans le TLV 130 avec des métriques externes.

 	3.2	Ordre de préférence pour tous les types de routes IP dans IS-IS
Malheureusement, IS-IS ne peut pas dépendre des seules métriques pour le choix des chemins. Certains types de routes doivent toujours être préférés à d'autres, sans considération des coûts qui ont été calculés dans le calcul de Dijkstra. Une des raisons est que les chemins inter zones peuvent seulement être annoncés avec une métrique maximum de 63. Une autre raison est que cette valeur maximum de 63 ne signifie pas l'infini (par exemple, comme un compte de bonds de 16 dans RIP note l'inaccessibilité). Introduire une valeur de coût infini dans les chemins IS-IS inter zones introduirait un comportement de compte jusqu'à l'infini via deux routeurs L1L2 ou plus, ce qui aurait un mauvais impact sur la stabilité du réseau.

L'ordre de préférence des chemins IP dans IS-IS se fonde sur quelques hypothèses.

o	La RFC 1195 définit que les chemins déduits de l'acheminement L1 sont préférés à ceux déduits de l'acheminement L2.

o	La note du point 2c du paragraphe 3.10.2 de la RFC 1195 définit que les chemins internes avec type de métrique interne et préfixes externes avec type de métrique interne ont la même préférence.

o	La RFC 1195 définit que les chemins externes avec type de métrique interne sont préférés aux chemins externes avec type de métrique externe.

o	Les chemins déduits de l'acheminement L2 sont préférés aux chemins L2->L1 déduits de l'acheminement L1.

Sur la base de ces hypothèses, le présent document définit les préférences de chemin suivantes :

1.	Les chemins L1 intra zone avec métrique interne ; les chemins L1 externes avec métrique interne.

2.	Les chemins L2 intra zone avec métrique interne ; les chemins L2 externes avec métrique interne ; les chemins L1->L2 inter zones avec métrique interne ; les chemins L1->L2 inter zones externes avec métrique interne.

3.	Les chemins L2->L1 inter zones avec métrique interne ; les chemins L2->L1 inter zones externes avec métrique interne.

4.	Les chemins L1 externes avec métrique externe.

5.	Les chemins L2 externes avec métrique externe ; les chemins L1->L2 inter zones externes avec métrique externe.

6.	Les chemins L2->L1 inter zones externes avec métrique externe.

 	3.3	Notes supplémentaires sur les préfixes à accepter ou annoncer
Le paragraphe 3.1 énumère tous les types de chemins IP utilisés dans IS-IS. À côté de ces type de chemins définis, le codage utilisé permettrait quelques combinaisons potentielles supplémentaires. Une d'elles est la combinaison de "Informations d'accessibilité interne IP" et Type de métrique externe. Cette combinaison NE DEVRAIT PAS être utilisée lors de la construction d'un LSP. À réception d'un préfixe IP avec cette combinaison, les routeurs DOIVENT ignorer ce préfixe. Une autre question serait l'usage du bit activé/désactivé dans les LSP L2. Parce que IS-IS est actuellement défini avec deux niveaux de hiérarchie, il ne devrait jamais y avoir besoin d'établir le bit activé/désactivé dans les LSP L2. Cependant, si IS-IS devait être étendu avec plus de deux niveaux de hiérarchie, des routeurs L2 seulement (ou L1L2) devraient être capables d'accepter les chemins IPL2 avec le bit activé/désactivé établi. Donc, il est RECOMMANDÉ que les mises en œuvre ignorent le bit activé/désactivé dans les LSP L2, et acceptent les préfixes dans les LSP L2 sans considérer si le bit activé/désactivé est établi. Cela va permettre une migration plus simple une fois que plus de deux niveaux de hiérarchie auront été définis.

Un autre détail dont les mises en œuvre devraient avoir connaissance est le fait que les routeurs L1L2 DEVRAIENT seulement annoncer dans leurs LSP L2 les chemins L1 qu'ils utilisent pour leurs propres transmissions. Ils NE DEVRAIENT PAS annoncer inconditionnellement dans L2 tous les préfixes provenant des LSP de la base de données L1.

Tous les préfixes n'ont pas besoin d'être annoncés du haut en bas de la hiérarchie. Les mises en œuvre pourraient permettre un filtrage ou agrégation manuelle supplémentaire pour réduire encore le nombre de préfixes inter zones qu'ils annoncent dans leurs LSP. Il est aussi RECOMMANDÉ que la configuration par défaut des routeurs L1L2 n'annonce pas de chemins L2 dans L1 (voir aussi la Section 4).

 	4.	Inter opérabilité avec les anciennes mises en œuvre

La solution du présent document n'est pas pleinement compatible avec la RFC 1195. C'est une extension à la RFC 1195. Si les routeurs n'utilisent pas la nouvelle fonctionnalité des chemins externes L1 ou des chemins L2->L1 inter zones, les mises en œuvre plus anciennes qui suivent strictement la RFC 1195 vont être compatibles avec les mises en œuvre plus récentes qui suivent le présent document.

Les mises en œuvre qui n'acceptent pas le TLV "Informations d'accessibilité externe IP" dans les LSP L1 ne vont pas être capables de calculer les chemins externes L1. Ceci pourrait causer des boucles d'acheminement entre routeurs seulement de couche 1 qui comprennent les chemins externes L1 pour une destination particulière, et les routeurs seulement de couche 1 qui utilisent le chemin par défaut pointant sur le plus proche routeur rattaché L1L2 pour cette destination.

Les mises en œuvre qui suivent la RFC 1195 DEVRAIENT ignorer le bit 8 dans le champ Métrique par défaut quand elles calculent les chemins. Donc, même les mises en œuvre plus anciennes qui ne connaissent pas le bit activé/désactivé devraient être capables d'accepter les nouveaux chemins L2->L1 inter zones. Ces plus anciennes mises en œuvre vont installer les nouveaux chemins L2->L1 inter zones comme des chemins L1 intra zone, mais cela ne cause pas par soi-même de boucle d'acheminement parmi les routeurs seulement de couche 1.

Cependant, il est vital que le bit activé/désactivé soit reconnu par les routeurs L1L2. Comme on l'a déclaré précédemment, les routeurs L1L2 NE DOIVENT PAS ré-annoncer de chemins L2->L1 inter zones dans L2. Donc, si des chemins L2 sont annoncés dans une zone L1, il est exigé que tous les routeurs L1L2 dans la zone aient un logiciel qui comprenne le nouveau bit activé/désactivé. Les mises en œuvre plus anciennes qui suivent la RFC 1195 et ne comprennent pas le nouveau bit activé/désactivé vont traiter les chemins L2->L1 inter zones comme des chemins L1 intra zone, et elles vont annoncer ces chemins en retour dans L2. Cela peut causer des boucles d'acheminement, un acheminement sous optimal, ou une instabilité d'acheminement supplémentaire. Pour cette raison, il est RECOMMANDÉ que les mises en œuvre n'annoncent pas par défaut de chemins L2 dans L1. Les mises en œuvre DEVRAIENT forcer l'administrateur de réseau à configurer manuellement les routeurs L1L2 à annoncer tout chemin L2 dans L1.

 	5.	Comparaison avec les autres propositions

Dans la [RFC5305], un nouveau TLV est défini pour transporter les informations de préfixe IP. Ce format de TLV définit aussi un bit activé/désactivé pour permettre les chemins L2->L1 inter zones. La RFC 5305 définit aussi un nouveau TLV pour décrire les liaisons. Ces deux TLV ont un espace de métrique plus grand et ont la possibilité de définir des sous TLV pour annoncer des informations supplémentaires appartenant à la liaison ou au préfixe. Le plus grand espace de métrique dans les TLV de préfixe IP permet des informations de métrique de granularité plus fine sur les coûts de chemin inter zones. Pour utiliser pleinement le plus grand espace de métrique, les administrateurs de réseau doivent déployer les deux nouveaux TLV en même temps.

Le déploiement de la RFC 5305 exige une mise à niveau de tous les routeurs du réseau et une transition aux nouveaux TLV. Une telle mise à niveau du réseau et cette transition peuvent n'être pas une tâche facile. Dans ce cas, la solution définie dans le présent document, qui exige seulement une mise à niveau des routeurs L1L2 dans les zones choisie pourrait être une bonne solution de remplacement à la solution définie dans la RFC 5305.

 	6.	Considérations sur la sécurité

Le présent document ne soulève pas de nouvelle question de sécurité pour IS-IS ; pour les considérations générales de sécurité pour IS-IS, voir la [RFC5304].

 	7.	Références
 	7.1	Références normatives

[ISO10589]	Norme internationale ISO 10589, "Technologie de l'information - Télécommunications et échanges d'informations entre systèmes - Protocole d'échange d'informations d'acheminement intra domaine de système intermédiaire à système intermédiaire à utiliser en conjonction avec le protocole de fourniture du service réseau en mode sans connexion(ISO8473)", seconde édition, 2002.

[RFC2119]	S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997. (MàJ par RFC8174)

[RFC1195]	R. Callon, "Utilisation de l'IS-IS OSI pour l'acheminement dans les environnements TCP/IP et duels", décembre 1990. (Mise à jour par les RFC 1349, 5302, 5304)

 	7.2	Références pour information

[RFC2966]	T. Li, T. Przygienda, H. Smit, "Distribution de préfixes sur un domaine avec IS-IS à deux niveaux", octobre 2000. (Obsolète, voir RFC5302) (Information)

[RFC5304]	T. Li et R. Atkinson, "Authentification cryptographique IS-IS", octobre 2008. (Remplace RFC3567, MàJ RFC1195) (PS)

[RFC5305]	T. Li, H. Smit, "Extensions IS-IS pour l'ingénierie du trafic", octobre 2008. (Remplace RFC3784, MàJ par RFC5307) (P.S. ; MàJ par RFC8918)

 	Adresse des auteurs

Tony Li	Henk Smit	Tony Przygienda	
Redback Networks, Inc.	mél : hhw.smit@xs4all.nl 	Z2 Sagl	
300 Holger Way		Via Tersaggio 20	
San Jose, CA  95134		CH-6949 Comano	
USA		Switzerland	
téléphone : +1 408 750 5160		mél : prz@net4u.ch 	
mél : tony.li@tony.li 			

 	Déclaration complète de droits de reproduction

Copyright (C) The Internet Society (2008).

Le présent document est soumis aux droits, licences et restrictions contenus dans le BCP 78, et à www.rfc-editor.org, et sauf pour ce qui est mentionné ci-après, les auteurs conservent tous leurs droits.

Le présent document et les informations contenues sont fournies sur une base "EN L’ÉTAT" et le contributeur, l’organisation qu’il ou elle représente ou qui le/la finance (s’il en est), la INTERNET SOCIETY et la INTERNET ENGINEERING TASK FORCE déclinent toutes garanties, exprimées ou implicites, y compris mais non limitées à toute garantie que l’utilisation des informations ci encloses ne violent aucun droit ou aucune garantie implicite de commercialisation ou d’aptitude à un objet particulier.

Propriété intellectuelle
L’IETF ne prend pas position sur la validité et la portée de tout droit de propriété intellectuelle ou autres droits qui pourrait être revendiqués au titre de la mise en œuvre ou l’utilisation de la technologie décrite dans le présent document ou sur la mesure dans laquelle toute licence sur de tels droits pourrait être ou n’être pas disponible ; pas plus qu’elle ne prétend avoir accompli aucun effort pour identifier de tels droits. Les informations sur les procédures de l’ISOC au sujet des droits dans les documents de l’ISOC figurent dans les BCP  78 et BCP 79.
Des copies des dépôts d’IPR faites au secrétariat de l’IETF et toutes assurances de disponibilité de licences, ou le résultat de tentatives faites pour obtenir une licence ou permission générale d’utilisation de tels droits de propriété par ceux qui mettent en œuvre ou utilisent la présente spécification peuvent être obtenues sur répertoire en ligne des IPR de l’IETF à http://www.ietf.org/ipr .
L’IETF invite toute partie intéressée à porter son attention sur tous copyrights, licences ou applications de licence, ou autres droits de propriété qui pourraient couvrir les technologies qui peuvent être nécessaires pour mettre en œuvre la présente norme. Prière d’adresser les informations à l’IETF à ietf- ipr@ietf.org .

Remerciement 
Le financement de la fonction d’édition des RFC est actuellement fourni par la Internet Society.