Enterprise IPv4 Multicast - MSDP Peering Diagram

This is part 3 in the IPv4 multicast series.  Part 1 covered scoping and address assignment.  Part 2 covered scoping and RP placement.

The traffic scopes we've defined are: building, campus, region and enterprise.  This article explains the strategy we're going to use when bolting these various scopes together with MSDP.

Our hypothetical enterprise has nine sites, arranged according to the following diagram.
There's a lot going on in this diagram. It's all meaningful, and I'm going to talk through a good portion of that minutia, but want to begin with the following:  The lines on the diagram represent MSDP peering.  MSDP is a multihop protocol, so the lines have nothing to do with layer1/2/3 topology, nor with PIM neighbor relationships.  This is just the map of how routers around the enterprise share multicast metadata among themselves.

The small colored circles represent individual routers which act as RPs. Their color indicates the scope of data for which the RP holds top-level responsibility.

Each RP is in a building (blue oval). Buildings are in a campus (green oval). Campuses are in a region (red oval). All regions are within the enterprise (no boundary shown).

The lines connecting between RPs indicate the scope of MSDP source-active (SA) advertisements flowing between those routers. The colored lines never cross their same-colored scope boundaries:

• Blue lines represent building scope SA's, so they never cross out of building (blue oval) 
• Green lines represent campus scope SA's, so they never cross out of a campus (green oval) 
• Red lines represent region scope SA's, so they never cross out of a region (red oval) 

Our enterprise has two data centers in the Chicago campus: Building 1 and Building 2. They're responsible for propagating enterprise scope data everywhere, as well as being responsible for the various smaller scopes that they happen to fall in. The RPs in building 3 and 4 share only building scope data among themselves. They exchange SA messages for all larger scopes only with their upstream RPs in the data centers.

The Tokyo office is the only site in the Asia-Pac region, so the Tokyo RPs share building, campus and regional multicast data only among themselves, as explained in Part 2. Enterprise scope data is shared only with the RPs in Chicago.

Finally, I want to call your attention to the pair of RPs in Paris. They share building and campus data among themselves, and share regional data with their upstream RPs in London and Madrid. But with whom do they talk about enterprise flows? Rather than going straight to the source (Chicago 1 and 2), they go to their upstream in-region peers. That's the model for all of this peering: Every router may peer only with his direct neighbor, or with a router one layer above or below in the hierarchy. This isn't the only way to do it, but it's the model I've chosen for this hypothetical deployment.