Skip to main content

Topic

Multicast Routing

Within the Topic facet, Multicast Routing topic intelligence connects articles that share a specific subject, signal focus, or monitoring theme. The page gives readers a richer path through related reporting, source evidence, market actors, and infrastructure implications, with enough context to understand why the topic matters across company movements, governance decisions, regional exposure, and operational risk. Readers can compare recurring signals, affected organisations, public evidence, market context, service continuity, procurement, competition, compliance, and strategic planning questions behind the subject instead of stopping at a thin list of matching articles. It explains what the topic covers, which infrastructure actors or policies are involved, what evidence supports the coverage, and why the subject may matter for operators, customers, investors, and policy readers.

Dino Farinacci in an AI editorial portrait, with abstract local-network paths converging and separating to illustrate collision detection and resolution.

IETF

Dino Farinacci and the Requirement That Did Not Allocate a Multicast Address

A requirements document can make a future system easier to judge. It cannot make that system exist. That distinction is the useful way to read RFC 10019, an IETF document co-authored by Dino Farinacci with Nate Karstens and Mike McBride.

Sep 4, 2026
Hooman Bidgoli in an AI editorial portrait beside distinct membership, controller, replication-tree and receiver layers.

IETF

Hooman Bidgoli and the Leaf Set That Was Not a Delivered Multicast Service

The control plane can produce an orderly list of intended receivers while the data plane is still divided across controller state, replication segments, service context and receivers that have not seen a packet. RFC 10018 makes the list useful. It does not make the list a…

Sep 1, 2026
Mike McBride in an AI editorial portrait beside one overlapping multicast group-ID field separating into six registry lanes.

IETF

Mike McBride and the Multicast Registry That Prevented One Kind of Collision

Two IPv6 multicast allocation methods had been told to draw identifiers from the same box. RFC 10028 divided the box before a future host protocol and an old server protocol could make the same choice—and left operators with the harder job of proving that their networks had…

Aug 31, 2026
One receiver selects a single amber source path through a branching glass multicast network while two other sources remain outside the admitted channel.

IETF

Joining the group is no longer enough: SSM makes the receiver name the sender

Source-Specific Multicast turns a multicast join into a choice: the receiver must identify both the group it wants and the source it is willing to hear.

Aug 26, 2026