Actually, it doesn’t I know, it’s strange. I can understand how the lack of a physical interface or device assigned the RP IP address is strange and difficult to grasp. In the document I shared above, the way this works is stated, but I will attempt to clarify.
First of all, you choose the IP address of your RP so that it belongs to a particular network segment. It can be an address of a physical interface, or not, but it must be within the network segment (subnet) that you want to serve the function of getting sources and receivers to learn
about each other.
It is configured using the
ip pim rp-address 220.127.116.11 <acl> bidir command on all participating routers if you want to configure it statically, and the document describes how to do it using Auto-RP as well. So that’s how it is configured. How does it work? Let’s use the diagram they use in the document:
You can see that RP 18.104.22.168 is just an IP address in the particular segment between the routers. Traffic from the source is going to be forwarded hop by hop to that destination, or to that subnet. Joins from receivers will also be sent to that subnet. The multicat routing mechanism knows thats the RP because we configured it as shown above.
Let me now share what it says in page 9 of the document, which states it better than I could:
Let’s start at the receiver end. Receivers, as usual, will send IGMP reports which will trigger a (*,G) join from the router toward the rendezvous point, creating a shared tree from the rendezvous point to the receiver as shown on the
show ip mroute output. Note that in the “mroute” entry the incoming interface (or Bidir-Upstream interface) is Ethernet0/0 which is the RPF interface to the rendezvous point address; that means that any traffic received on Ethernet0/0 will be forwarded downstream through the shared tree.
Moving to the source side of the topology, the state for the left router shows that it is the designated forwarder on Ethernet1/0. That means that whenever it receives traffic for a Bidir group on that interface it will forward it “upstream” toward the rendezvous point, out Ethernet 0/0. When the packets reach that network, the connectivity from the source to the receiver is achieved. So, in a way it is the subnet (22.214.171.124/24) and not a physical router that is acting as the rendezvous point.
I added the highlights for emphasis.
Well, in this case, the traffic must flow through the specific network segment or subnet, so the same thing is achieved.
I hope this has been helpful!