Je balance une idée en l’air entre 2 tartines. Si on prenait quelques octets en plus devant le numéro de téléphone pour y mettre le préfixe de porta (celui de l’ARCEP si l’opérateur en a un, sinon un attribué par l’association). Ainsi, le SBC de l’opérateur a toutes les infos dans la route. L’AS et le next-hop, c’est celui du RS de l’IX-Voix de toute façon, car pour moi c’est un IX dont les membres peerent seuleement avec le RS, qui est un tiers de confiance qui envoie une information contrôlée. Le SBC de l’opérateur peut alors récupérer le préfixe de porta dans la route. Si le prefixe de porta est 10000 par exemple, il cherche dans une table interne ou alors il fait un lookup DNS pour avoir les champs TXT par exemple de la zone 10000.domain.gtld, qui vont contenir les différentes IP des SBC auxquels il faut envoyer l’appel (soit les SBC de l’autre opérateur, soit ceux de l’IX, en fonction du modèle technico-économique choisi).
On 16 mai 2018 09:08 +0200, Alexis Lameire <alexis.lame...@gmail.com>, wrote: > Raphaël, > Ta remarque est pertinente sauf que ton plan de num est différent selon le > pays, donc c'est 3digit + padding + num. On a besoin de mettre le padding à > cette endroit pour que la notion de masque reste valide (et profiter de > l’agrégation). > > L'identification d'un opérateur ne peut se faire uniquement avec le numéro > d'AS, il y a toujours/souvent un enregistrement local complémentaire qui > est nécessaire à la vérification de la validité du plan de num annoncé. Il > faut donc le recevoir dans l'annonce BGP. On pourrais utiliser le vpnv6 > mais utiliser la notion de vrf pour coder l'identification de l'opérateur > c'est pas crédible. On souhaite isoler les plan de num par pays et non par > opérateur (dont le numéro pourrait se recouvrir sur deux pays différent) > > On peut sinon concevoir de transférer l'information d'identification ARCEP > via l'utilisation d'un bloc de communauté well know et rester dans les > clous. Comme ça on rajoute le moins de truc au protocole. > > Le seul truc sur lequel il faut pas transiger, c'est l'utilisation > mémoire/tcam. Et donc il faut définir une extension pour router des bloc de > 64bit avec prefix. > > Alexis > > Le 16 mai 2018 à 08:46, Raphaël Jacquot <sxp...@sxpert.org> a écrit : > > > > > > > On 15/05/2018 20:07, Alexis Lameire wrote: > > > > ainsi la EZABPQ 011234 se code avec : > > > un prefix binaire représenté en hexa : 01:12:34:00:00 > > > un masque binaire représenté en hexa : FF:FF:FF:00:00 > > > > > > On peut ainsi employer la notation CIDR en 01:12:34:00:00/24 les routes > > > spécifique étant en /40 > > > > > > > STOP right there... > > > > je pense qu'une solution est possible sans même ajouter d'extension a > > BGP... > > > > * une adresse IPv6 est composée de 128 bits, soit 32 blocs de 4 bits. > > * d'après https://en.wikipedia.org/wiki/Telephone_numbering_plan > > un numéro de téléphone, au niveau mondial, a 15 caracteres BCD > > > > Il serait donc extremement simple, et le plus naturel du monde, de mapper > > tout ca sur un seul /64, > > * le code pays est sur 3 digits > > * le reste du numéro sur les 13 digits restants > > > > ce qui simplifierai grandement les tables de routages au niveau > > international > > > > Raphaël > > > > > > > > > > > > > > --------------------------- > > Liste de diffusion du FRnOG > > http://www.frnog.org/ > > > > --------------------------- > Liste de diffusion du FRnOG > http://www.frnog.org/ --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
