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/
