Domaine principal
Routage multicast
Au sein de la facette Domaine principal, l'analyse Routage multicast regroupe les articles par domaine principal afin que les lecteurs puissent suivre un périmètre précis de l'infrastructure Internet, de la gouvernance, des marchés de connectivité ou du capital numérique. Cette page rassemble les articles associés, les preuves publiques, les institutions, les entreprises, les personnes, l'exposition régionale, les dépendances opérationnelles et le contexte de marché qui pourraient sinon être répartis entre différentes pages de catégories. Elle explique le domaine, la classe d'acteurs probable, le contexte de marché ou de gouvernance, ainsi que les sources que les lecteurs devraient utiliser pour comparer les signaux. Opérateurs, analystes et lecteurs de gouvernance peuvent voir comment un même domaine se manifeste à travers les événements, les profils, les évolutions de marché, les preuves issues de sources publiques, les dépendances régionales et les décisions d'infrastructure à plus long cycle au fil du temps.
IETF
Sans Hello, PIM Light déplace deux décisions de redondance hors de l’interface
La RFC 9739 permet de transmettre l’état multicast sans établir au préalable un voisinage PIM. Le domaine peut ainsi alléger sa frontière, mais doit conserver ailleurs l’élection du routeur qui relaie les demandes, le choix d’un seul flux amont et le retrait effectif des…
Dossier
Deux sources, un choix, mais aucune preuve de continuité : RFC 9856
La redondance multicast ne vaut que si le récepteur obtient un flux unique et exploitable. RFC 9856 organise le choix dans un EVPN; elle ne transforme pas ce choix en verdict de service.
Dossier
Le chemin de secours était prêt. Le service multicast restait à prouver : RFC 9860
En étendant MoFRR avec un chemin calculé par TI-LFA, la RFC 9860 réduit une attente importante. Elle ne supprime pas la nécessité de démontrer ce qui s'est passé entre l'état de routage, la bascule locale et les récepteurs.
