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 <rich...@demongeot.biz> 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 <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/ >>> >> >> --------------------------- >> 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/
