Moyennement gérable s’il y a 30/40 acteurs quand même…
On 18 mai 2018 13:54 +0200, Sébastien Lesimple <[email protected]>, wrote: > Hello, > > Si je devais remonter ma solution tech, la seule chose dont j'aurais > besoin, c'est le plan de num de chaque membre en fichier à plat dans un > SFTP (avec sa fréquence de mise a jour) et un trunk vers le membre > détenteur de ND. Les SLA et les CAPS de chacun pour pas bastonner trop > fort et c'est tout... > > En fait c'est déjà comme cela que je faisais en 2006, rien de nouveau. > Les usines a gaz ou je maitrise pas la terminaison, j'ai vécu avec Viatel... > Merci, mais non merci! > > Seb. > > Le 17/05/2018 à 12:08, Mickael Hubert a écrit : > > Bonjour à tous, > > > > Le 17 mai 2018 à 11:19, Richard DEMONGEOT <[email protected]> a écrit : > > > > > Hello, > > > > > > Toutes les idées a base de BGP sont très sexy, et intéressantes, mais il > > > reste un problème de base. Comment chaque opérateur va devoir implémenter > > > un composant liant BGP / Voix. > > > Cependant, comme évoqué à plusieurs reprises, pas de modifications > > > incessantes de la table de routage voix. > > > > > > > *Pour ma part le composant de routage pour la voix devrait-être le DNS > > (ENUM), je sais j'insiste sur ce point ;) , mais devoir trouver / > > développer un composant "gateway" entre BGP et voix pour gérer du trafic de > > prod me semble hasardeux.* > > *Bon, ce composant existe peut-être déjà, je ne sais pas...* > > > > > > > Pour la table de routage internationale, OSEF dans un IX. (ou alors, c'est > > > un GIE, donc avec plusieurs fournisseurs, et c'est plus complexe). Dans > > > tous les cas, les changements sur les non-membres : on s'en fout. (porta > > > depuis / vers les membres à gérer uniquement). Exemple : porta orange / > > > sfr > > > : quel impact vu qu'a moyen terme aucun des deux ne sera dessus? Pire, > > > belgacom / proxymus? > > > > > > Pour moi, le plus simple, sur, rapide, fonctionnel reste : > > > > > > Un IX dédié à la voix (qu'on peut multiplier à souhaits). > > > Sur cet IX : > > > - Chaque membre qui s'y connecte doit y mettre un ou plusieurs SBC; > > > - L'association fourni un ou plusieurs proxy SIP - en guise de voice route > > > server. > > > > > > Coût pour l'association : > > > 1 switch (1G/10G de préférence); > > > 3 serveurs (db + proxy). > > > > > > Le cheminement serai alors le suivant : > > > Le SBC du client envoie son INVITE SIP, sur le / l'un des proxy. > > > Le proxy intérroge la DB, fournie par l'APNF, et route sur le bon membre. > > > => Si c'est pas sur un membre, alors plusieurs cas sont possibles : > > > A/ L'association renvoi un code retour temporaire ou permanent sur ce > > > numéro (pas routable sur l'IX); > > > B/ L'association étant un GIE, et disposant de contrat de terminaison SIP > > > peut router le numéro. ==> Quid de la facturation/re-facturation? Par > > > contre, économie d'échelle si les contrats sont mutualisés. > > > => Si le membre ne réponds pas (SIP option réguliers) alors on réponds une > > > erreur temporaire. (ou on load balance sur moins d'IP si le membre a > > > plusieurs SBC) > > > > > > > *Chaque provider connecté au X doit avoir une réplication de la DB. Car si > > tout est géré (au niveau routage voix par le X) nous nous retrouverons dans > > le même cas (plantage d'Orange) si celui-ci plante.* > > > > > > *De plus, cela engendre du trafic SIP (et des réponses) pour pas grand > > chose.* > > > > *Je voyais cela plutôt:* > > > > *- lors de l'import de la DB APNF chez le provider, celui-ci sait qui se > > trouve connecté sur tel ou tel X et donc créé sa propre DB avec tel préfixe > > vers tel X (donc telle IP), puis tel préfixe vers l'autre X, etc ... (cela > > peut-être automatisé, voir même si on parle d'asso en plus de l'APNF, > > celle-ci pourrait fournir une DB modifiée avec les préfixes quelle gère)* > > > > *- lors d'un appel vers tel numéro hors de son réseau, la DB chez le > > provider sait où envoyer au plus proche* > > *- Sinon on envoie par défaut sur son transitaire voix (du genre Orange ;) > > )* > > > > > > > > > Dans les deux cas, ralentissement de l'établissement de quelques > > > milli-secondes pour le SBC appelant, c'est largement acceptable pour > > > fall-back sur un autre fournisseur. > > > > > > Dans le modèle IX, je préfère l'option A, qui simplifie le boulot pour > > > l'asso. > > > > > > Et pour la croissance me direz vous? > > > Là encore, deux options : > > > A/ On déploie un IX dans chaque DC, en se moquant complètement de > > > l'interco, c'est à dire que chaque POP est stand-alone; (coûts multipliés > > > par le nombre de POP) > > > > > > B/ On déploie un réseau multi DC (donc plus complexe), et les membres de > > > l'interco Lyon peuvent taper sur des ressources Bordeaux. Pour les SBC des > > > clients, c'est simple, ils mettent une interface en /28 sur le POP, et une > > > route vers la /22. (coût qui ne sont pas proportionnels au nombre de POP, > > > mais besoin d'équipement L3 pour gérer le backbone). > > > > > > Point bonus de la solution B, le proxy peut être anycasté entre plusieurs > > > POP. > > > > > > Dans tous les cas, l'asso ne gère pas de transcoding (les membres envoient > > > le RTP de pair à pair); > > > Tant que tous les membres respectent un critère simple, supporter au moins > > > le G.711, tout est inter-opérable; > > > Si deux membres veulent jouer avec de la visio, ou des codec de plus haute > > > qualité, ça n'a aucun impact sur les autres. > > > Les membres n'ont pas à avoir de connaissances BGP (je sais, on est sur > > > frnog, le BGP c'est simple) > > > > > > > *100% d'accord le X ne doit pas s'embêter avec du temps réel et du > > transcoding.* > > > > *chaque provider est assez grand pour se mettre d'accord avec son > > destinataire (vive le SDP)* > > > > > > > Avec juste le proxy sur les invite (donc initiation d'appel), l'asso ne > > > peut pas influer sur la qualité de la voix (mono POP). > > > Celle-ci est garantie, vue que les SBC parlent entre eux sur le même > > > subnet. Dans le cas d'un réseau multi-pop, c'est plus complexe. > > > > > > Côté revenus de l'association, les options seraient : > > > - coût au port d'interconnexion - fixe; > > > - coût à la BP réellement utilisée; > > > - coût d'initiation (ie par appel - mais complètement incohérent pour > > > moi). > > > > > > Et pour moi, l'asso est gérée par ses membres, avec une évolution vers un > > > GIE à terme : > > > Besoin de quelques SBC propres à l'association, de contrats de transit > > > Orange / SFR / BICS / ... et LCR vers ces destinations > > > > > > Cordialement, > > > > > > > > > Le 2018-05-16 09:48, David Ponzone a écrit : > > > > > > > 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 <[email protected]>, > > > > 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 <[email protected]> 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/ > > > > > > > > > > --------------------------- > > > 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/
