Il y a aussi le cas des porta. IMAO on a déjà la réponse dans les algo de routage
une route spécifique :) donc un /36 et un /40. Ceci permet aussi de prendre en compte le cas des porta. L'APNF alloue des /24, et lors des porta l'opérateur destinataire de la porta annonce les routes spécifiques. Par contre, c'est peut être moi qui ai loupé un truc cette fois. 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/AAAAAAOQIBAAARZrylAAAFlmiY0AAPiDvlwAFihtAAVMlQBa- > 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/
