Enterprise IPv4 Multicast - Rendezvous Points

Having established a scheme for assigning applications to multicast groups, we need to figure out what to do about RPs.

In a vanilla PIM deployment, every router knows the one router that serves as RP for any given multicast group.  You can have a single active RP (serving all groups), or many RPs, each one serving a different range of groups.

PIM routers can learn the RP address for a given group through one of several mechanisms:

Method	Syntax	Pros	Cons
static	ip pim rp-address rp-address	Simple	Not Robust
Auto-RP	ip pim autorp listener ip pim send rp-announce scope    ttl-value ip pim send-rp-discovery scope    ttl-value	Automagic	Cisco proprietary. Complicated when running multiple overlapping scopes
BSR	ip pim bsr-candidate    interface-type interface-number ip pim rp-candidate    interface-type interface-number	Like Auto-RP, but standards based	Not widely used. Complicated when running multiple overlapping scopes
Anycast Pim	N/A	Standards based, scalable, awesome.	Cisco only supports on NX-OS, not IOS
Anycast RP + MSDP	ip pim rp-address rp-address Plus a mess of MSDP configuration	Scalable, awesome, interoperable.	?

Anycast RP + MSDP
Anycast RP is far more simple than the election-based mechanisms, and lets us do lots of nifty scoping tricks fairly simply.  It also saves us from the pain of running multiple different RPs for different purposes. If you're not familiar with anycast, it's a simple concept: Run the same service on the same IP address on multiple different areas in a network, and advertise those IPs into your IGP. Routing protocols will deliver your packets to the closest implementation of that service (IP address). It works great for connectionless services (like PIM or DNS), where it doesn't matter if every packet you send hits exactly the same server.

In the case of anycast RP, we just spin up a loopback interface on every participating router, using the same IP address on each of them.  Be careful if the anycast address has the numerically highest address among loopback interfaces.  Then manually configure the anycast IP as the RP on all leaf routers in the network, just like you would for static RP configuration.

Leaf routers will now send PIM traffic to the closest RP.  But there's a missing bit here:

The missing piece is synchronization between RPs, and that's where Multicast Source Discovery Protocol (MSDP) fits in.  MSDP was designed to share information about active multicast sources between the (presumably single) RPs in different administrative domains.  You might use MSDP peering with your ISP to learn about active multicast flows out in the Internet, or with a business partner in order to attract flows from their network, because once your RP knows about an active source, it can send subscription requests (PIM joins) in the direction of the active source.

A clever use of MSDP is peering between your own Anycast RPs, so that each of the many simultaneously active RPs will know about all active flows in your network:

Anycast RP + MSDP is a great solution.  Anycast PIM (available on NX-OS) lacks rich filtering capability, which is key to the enterprise scoping scheme.  You can do interesting combinations of anycast RP with Auto-RP, but it gets complicated quickly, and I don't see a compelling use case for it.

Where do RPs belong?
So, having established that we're going to run lots of RPs, where do they belong exactly?  Lots of people spend lots of time thinking about exactly where RPs should go relative to sources and receivers.  Someplace between them is ideal, if you can manage it.  ...But it probably doesn't matter much.  With the default PIM sparse configuration, data won't flow through the RPs, except for a brief moment when subscribers initially come online.  If your packet rates are high enough, and your subscribers transient enough, then you should place RPs carefully.

So, where exactly do we need RPs?  Start with the smallest routable scope.  In our case, it's "building".  If there will be intra-building multicast flows, then by definition there must be an RP in each building.  And if you need one RP, then you probably need a second one for redundancy.  So, that settles it:  Two RPs in each building.  With wild, crazy and carefully planned MSDP peering to bring them all together.