Sinon, il reste LISP. On prend l'e164 en EID, et une @IPv6 en RLOC (ça ne marchera que pour la VoIP) ou bien l'adresse SS7 (pour le legacy).
C'est un système à base de mapping, donc de la grosse DB, et là, c'est quand même carrément statique le bordel (on swappe pas de n° de tel tous les jours, et les IPv6 pour 99% des besoins non plus, vu que de l'extérieur, l'IPv6 sera surement celle du PxTR et non celle du device final, donc un truc stable dans le temps). Backend sur une base repliquée / shardée type MongoDB, un truc du genre, et ça doit pouvoir scaller des milliards de mapping. Et puis pour une fois qu'on pourrait trouver une application concrète à ce protocole :D Le 16 mai 2018 à 18:27, Guillaume Barrot <guillaume.bar...@gmail.com> a écrit : > D'où mon analogie à EVPN. On summarise pas les @Macs. Depuis les > portabilités de n°, on ne peut plus summariser les routes SS7 non plus :). > Bref, c'est bien du routage de "/32" pour n millions de clients, mais ça > reste ultra statique. > > Le 15 mai 2018 à 20:18, David Ponzone <david.ponz...@gmail.com> a écrit : > >> Ce qui me dérange, c’est que vous semblez oublier qu’une plage de numéros >> client c’est par exemple un /36 dans ton exemple (ZABPQMCD), mais il arrive >> souvent qu’un numéro ait été sorti pour une ligne analogique (fax) donc ton >> /36 devient 9 /40. >> Difficile d’évaluer le nombre de routes que ça représente, probablement >> gérable entre opérateurs petits, mais si un SFR ou Free se pointe, ça va >> faire mal (les particuliers ont tous un /40, et rien à aggréger). >> >> J’ai raté un truc ? >> >> On 15 mai 2018 20:07 +0200, Alexis Lameire <alexis.lame...@gmail.com>, >> wrote: >> > Hello frnog, >> > >> > Je ne suis pas un spécialiste voix, mais je suis aussi convaincu qu'il >> y a >> > des choses a faire avec une extensions à BGP. Je vais rajouter my 2 >> cent au >> > schmilblick >> > >> > qu'est ce qui fait que BGP c'est le bien : >> > * l'aggrégation des prefix >> > * l'algo dee routage déjà tout fait >> > * la responsabilité du routage laissé à chaque acteurs de la boucle >> > * l'ouverture a d'autre protocole. >> > >> > Déjà premier truc dont je suis pas d'accord, la RFC sur l'EVPN me semble >> > pas trop adapté, j’aurais tendance à me basé sur l'extension vpnv4. >> > >> > On a besoin en premier lieux de définir des zones cloisonnées de >> routages, >> > avec un numéro d'identification par pays. Dans ce cadre la, le country >> code >> > peut être utiliser. >> > Ensuite chaque entité à besoin d'être identifié à la fois de façon >> globale >> > et de façon locale. L'identité sur internet me semble être un numéro >> d'AS >> > enregistrer auprès d'un RIR il n'y a pas à tortiller mille an. Par >> contre >> > d'un point de vue local cela dépend de l'entité administrative locale. >> Dans >> > le cadre de la france, l'ARCEP. On pourrait par exemple concevoir le >> numéro >> > d'enregistrement auprès de l'ARCEP comme une bonne variable >> > d'identification. Mais il s'agit d'un champ de taille fixe dépendant du >> > pays. >> > >> > Le second élément à prendre en compte est l’agrégation. Nous avons un >> > soucis avec tous les plan de numérotation c'est qu'ils sont conçu en >> base >> > 10 et non dans une puissance de 2. Il faut donc trouver un codage >> > intelligent. Je propose de coder les routes et les masques en >> > BCD[1] >> > >> > 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 >> > >> > Il faut maintenant fournir les services d'un serveur de route auprès des >> > différents opérateur. Un bon serveur de route se doit : >> > * de vérifier la validité de ses membres : on peut ici utiliser RPKI, il >> > faut simplement héberger les clef au niveau de l'APNF ou avoir une >> > procédure auprès de l'iX pour vérifier la validité du peer. >> > * de vérifier les bogon : comme certains transitaire vont vérifier les >> > bases des RIR, la ressource de numérotion peut être vérifié auprès de >> > l'APNF. >> > * de vérifier la sécurité des annonce : on a une RFC qui est récente : >> > BGPSEC >> > >> > La ou ça s'arete, c'est qu'en pratique les règle d'interco peuvent >> différer >> > d'un opérateur à l'autre et il faut pouvoir prendre en compte ces >> > changement. Les informations de numérotation sont ainsi à fournir à la >> > brique du backbone de l'opérateur téléphonique qui gére le LCR (pas la >> NUM, >> > on a toujours le cas des numéro d'urgence qui sont à réencoder et qui ne >> > sont pas adapté à BGP (le cas des numéros qui changent selon l'heure)). >> > C'est aussi nécessaire par ce que l'opérateur doit être en mesure >> > d'appliquer des mesures anti fraude avant de transférer le trafic à >> > l'I-SBC. >> > >> > Pour gérer l'interco au niveau du SBC il faut aussi prévoir deux champ >> > obligatoire avec l'addresse du peer sur l'IX ainsi que la norme >> d'interco >> > suivie. Ceci est nécessaire par ce qu'on ne souhaite pas que les RR >> gére le >> > dataplane. >> > >> > Ceci clos la partie purement voix. Pour gérer l'interco sur l'IX et >> éviter >> > le L2 il faudra aussi prévoir une interco BGP classique sur le routeur >> en >> > aval du I-SBC pour redistribuer les routes pour joindre les SBC des >> copain. >> > Mais rien de bien complexe. >> > >> > Enfin, d'un point de vue facturation, ayant dans les annonces BGP le >> numero >> > d'enregistrement auprès de l'APNF il est facile de mettre ça dans les >> CDR >> > pour se refacturer entre copain. On pourrait même concevoir que l'IX >> > fournisse la liste des adresse de facturation de ses membre pour >> simplifier >> > les choses voir pour les plus petit prenne en charge la refacturation >> > contre quelques % des sommes dues. >> > >> > C'était un long pavé, mais je veux bien vos avis :) >> > Cordialement >> > Alexis Lameire >> > >> > [1] https://fr.wikipedia.org/wiki/D%C3%A9cimal_cod%C3%A9_binaire >> > >> > Le 15 mai 2018 à 19:05, Xavier ROCA <x.r...@sipleo.com> a écrit : >> > >> > > Pour ceux que cela intéresse voilà la com d'OVH >> > > >> > > http://mj.ovh.com/lnk/AAAAAAOQIBAAARZrylAAAFlmiY0AAPiDvlwAFi >> htAAVMlQBa- >> > > wUyiluYDoEjRGWTTD_qsQggRAABHT4/1/cV-o3neJSH8uzaDa7FERdQ/ >> > > aHR0cDovL21qLm92aC5jb20vbmwyLzVyN2wvMTJvaXQuaHRtbD9tPUFBQUFB >> > > QU9RSUJBQUFSWnJ5bEFBQUZsbWlZMEFBUGlEdmx3QUZpaHRBQVZNbFFCYS13 >> > > VXlpbHVZRG9FalJHV1RURF9xc1FnZ1JBQUJIVDQmYj1hMGNhNzI2OCZlPTlk >> > > Mjg3NTA3JmVtYWlsPW92aEBzZGkuZnI >> > > >> > > Même si ce n'est pas super réglementaire certains on bien compris que >> > > l'échange strictement privé a une part de bon sens. >> > > Mais apparemment SFR n'a pas traité tout le monde de la même manière >> > > aujourd'hui donc ca reste du SFR... >> > > >> > > >> > > >> > > --------------------------- >> > > 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/ >> > > > > -- > Cordialement, > > Guillaume BARROT > -- Cordialement, Guillaume BARROT --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
