Bof, ca s'automatise a tous les niveaux si vous filez des API bien foutus. Trunk, plans de num etc...
Le 18/05/2018 à 13:55, David Ponzone a écrit : > 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/
