http://www.bortzmeyer.org/7153.html
---------------------------- Auteur(s) du RFC: Eric C. Rosen (Cisco Systems), Yakov Rekhter (Juniper Networks) Chemin des normes ---------------------------- Rien de dramatiquement nouveau dans ce RFC sur le protocole de routage BGP. Il s'agit juste d'une réorganisation des registres qui stockent les « communautés étendues », des attributs d'une annonce BGP. Les communautés étendues déjà enregistrées ne sont pas modifiées, les valeurs ne changent pas, le code continue à tourner comme avant, c'est juste la relation entre registres et les règles d'enregistrement qui sont clarifiées. Ces communautés étendues sont normalisées dans le RFC 4360. Plus grandes que les anciennes communautés du RFC 1997, elles sont structurées en un *type*, parfois un *sous-type* et une *valeur*. (Rappel : il existe en ligne une liste des communautés des principaux opérateurs <http://onesc.net/communities/>.) Le type indique entre autres si la communauté est transitive (si elle doit être transmise aux AS voisins) ou pas. S'il n'y a pas de sous-type, on parle de « types normaux » et, s'il y en a un, de « types étendus ». Types et sous-types sont mis dans un registre IANA. Les politiques d'allocation (cf. RFC 5226) varient, une partie de l'espace étant sous une politique restrictive (pour garantir qu'elle ne s'épuisera pas trop vite) et une autre sous une politique plus laxiste (pour faciliter la vie des utilisateurs). Par exemple, une communauté étendue qui commence par 0x0107 indique une propriété spécifique à un préfixe IPv4 (type 0x01), en l'occurence le "Route ID / route type" (sous-type 0x07) d'OSPF (cf. RFC 4577). Les anciennes règles étaient spécifiées dans le RFC 4360 mais d'une manière qui s'est avérée trop confuse. D'où la réforme des registres (pas du protocole : les annonces BGP ne changent pas). Donc, les nouveaux registres, tels que les décrit la section 2 de notre RFC : * Un registre des types transitifs <http://www.iana.org/assignments/bgp-extended-communities/bgp-extended-c ommunities.xhtml#transitive>, * Un registre des types non transitifs <http://www.iana.org/assignments/bgp-extended-communities/bgp-extended-c ommunities.xhtml#non-transitive>, * Un registre des sous-types par type étendu (ceux qui ont des sous-types)., par exemple il y en a un pour les sous-types spécifiques à un AS de quatre octets <http://www.iana.org/assignments/bgp-extended-communities/bgp-extended-c ommunities.xhtml#trans-four-octet-as>, un autre pour les sous-types spécifiques à une adresse IPv4 <http://www.iana.org/assignments/bgp-extended-communities/bgp-extended-c ommunities.xhtml#trans-ipv4>, etc. Les registres des types doivent découper l'espace de nommage en trois, chaque partie ayant une politique d'allocation différente. De 0x00 à 0x3F, c'est du premier arrivé, premier servi. De 0x80 à 0x8F, réservé à un usage expérimental. Et de 0x90 à 0xBF, il faut une norme. Pour les registres des sous-types, ce découpage est fait une fois pour toutes : de 0x00 à 0xBF (les sous-types sont codés sur un octet, cf. RFC 4360, section 3), la politique est « premier arrivé, premier servi » (très laxiste, donc, cf. RFC 5226), de 0xC0 à 0xFF, la politique « Examen par l'IETF » (très stricte, au contraire : il faut un RFC, et pas un RFC soumis individuellement). Rappelez-vous que tous les types n'ont pas de sous-types. Le fait d'avoir des sous-types est une propriété définie à la création du type (et indiquée dans le registre). Un cas particulier est traité dans la section 3, celui des communautés étendues spécifiques pour les adresses IPv6. Créées par le RFC 5701, sur le modèle de communautés étendues spécifiques pour les adresses IPv4, elles n'ont en fait jamais été alignées, malgré la demande du RFC 5701 : les sous-types ne correspondent pas toujours. Notre RFC 7153 en prend donc acte et supprime cette demande d'alignement entre les sous-types IPv6 et les IPv4. Les deux registres pour IPv6 sont disponibles, un pour les transitifs <http://www.iana.org/assignments/bgp-extended-communities/bgp-extended-c ommunities.xhtml#trans-ipv6> et un pour les non-transitifs <http://www.iana.org/assignments/bgp-extended-communities/bgp-extended-c ommunities.xhtml#non-trans-ipv6>. OK, et si je veux déclarer un type ou un sous-type et qu'il se retrouve dans ces beaux registres qui viennent d'être réorganisés, je fais quoi ? La section 4 décrit les procédures d'enregistrement. D'abord, le demandeur doit se poser la question « faut-il un nouveau type ou bien un sous-type d'un type existant peut-il suffire ? » Ensuite, s'il faut un type, doit-il être transitif ou pas ? (Certains types ont un sens dans les deux cas et doivent donc être ajoutés dans deux registres. Et le type aura t-il des sous-types ? (Ce n'est pas obligatoire d'en avoir mais cela doit être mentionné dès le début.) Et, si oui, ces sous-types seront-ils dans un registre à part (c'est le cas de tous les types à sous-types aujourd'hui) ou bien réutiliseront-ils un registre de sous-types existant ? Enfin, la section 5 du RFC contient la valeur actuelle des registres, qui sont désormais en ligne <http://www.iana.org/assignments/bgp-extended-communities/bgp-extended-c ommunities.xhtml> à l'IANA. --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
