RFC 3446

Part 1 of 2 ✨

Title Block 🎀

Okay so this one is RFC 3446, and it's classed as Informational 💅 which means it's sharing knowledge with the Internet community, not setting an official standard. It's from the Network Working Group and it's dated January 2003 🌸

The writers are D. Kim from Verio, and D. Meyer, H. Kilmer and D. Farinacci from Procket Networks 🦋 The title block doesn't list any RFCs this one obsoletes or updates, so it's standing on its own, no drama.

The title is: "Anycast Rendevous Point (RP) mechanism using Protocol Independent Multicast (PIM) and Multicast Source Discovery Protocol (MSDP)" 👑

---

Status of this Memo 🌈

Bestie, this part is just the legal-ish stuff. The memo gives information to the Internet community, and it does not specify an Internet standard of any kind. Distribution is unlimited, so share it wherever ✨

Copyright Notice 💜

Copyright (C) The Internet Society (2003). All Rights Reserved. 🫶

Abstract 🦋

This doc describes a mechanism that lets you have an arbitrary number of Rendevous Points (RPs) per group in a single shared-tree Protocol Independent Multicast-Sparse Mode (PIM-SM) domain. Multiple RPs, one group, no cap, it's giving flexibility 🔥

1. Introduction ✨

Okay so, RFC 2362 says PIM-SM only lets you have ONE active RP per group 🙈 That makes picking the best spot for the RP kinda messy when your network spans multiple regions 🌍

Anycast RP loosens that rule, because the thing it breaks is that only one group-to-RP mapping can be active at any time. That single-mapping thing causes a bunch of problems, like traffic concentration, bad scaling of register decapsulation when you're on the shared tree, slow convergence when an active RP dies, possibly sub-optimal forwarding of multicast packets, and distant RP dependencies 💀 These problems have been shown in real continental and intercontinental multicast deployments, so it's not theoretical bestie 😭 So ISP backbones clearly need a way to have multiple active RPs per group in one PIM-SM domain, and that mechanism should also fix the stuff listed above ✨

This mechanism is aimed at better fail-over (convergence time) and at sharing the register decapsulation load among the RPs in a domain (again, on the shared tree) 💅 It's mainly for networks running MBGP, the Multicast Source Discovery Protocol [MSDP], and PIM-SM for native multicast deployment, but it isn't limited to those protocols. Anycast RP works in any PIM-SM network that also supports MSDP, because MSDP is needed so the RPs in the domain all have a consistent view of which sources are active 🧚 Heads up though, a domain using Anycast RP is not required to run MBGP 🙌 And the big general rule: the anycast address MUST NOT be used as the RP address in the RP's SA messages ⭐

The anycast address MUST NOT be used as the RP address in the RP's SA messages. Seriously, this one is the main rule, don't skip it 🚨

The keywords MUST, MUST NOT, MAY, OPTIONAL, REQUIRED, RECOMMENDED, SHALL, SHALL NOT, SHOULD, SHOULD NOT are to be interpreted as defined in BCP 14, RFC 2119 [RFC2119] 🎀

2. Problem Definition 🌸

The anycast RP solution handles both fast fail-over and shared-tree load balancing across any number of active RPs in a domain. Iconic 👑

2.1. Traffic Concentration and Distributing Decapsulation Load Among RPs 💖

Even though PIM-SM lets you define multiple RPs for a given group, only one group-to-RP mapping can be active at a time. The old-school way to split the register decapsulation load between RPs is to carve up the 224.0.0.0/4 space between the defined RPs 🍓 That's fine while multicast traffic is low, but it gets messy as traffic grows. The operator who splits the group space doesn't always know ahead of time how traffic is spread across groups. You can fix that with periodic reconfigurations, but the operational overhead makes this approach scale poorly 😭

2.2. Sub-optimal Forwarding of Multicast Packets 🦋

When one RP serves a given multicast group, every join to that group gets sent to that RP, no matter how far it is from the sources and receivers. Initial data also goes toward the RP until the configured shortest path tree switch threshold is reached, or it always goes toward the RP if the network is set to always use the RP-rooted shared tree. This happens even when all the sources and receivers are in one single region and the RP is topologically far away. It's an artifact of how dynamic group members are, plus operators don't always know where group members physically sit 🙈

Put together, this can get really wasteful. For example, all the sources and receivers of a group could be in Europe, but they're all joining toward an RP in the USA. The data then crosses a pricey pipe (or pipes) twice, once to reach the RP and again on the way back down the RP-rooted tree. That's an inefficient use of expensive resources, and it's so not it 💀

2.3. Distant RP Dependencies 🌈

Like we covered, a single active RP per group can make local sources and receivers depend on an RP that's topologically far away. Also, when multiple RPs are configured, there can be a lot of convergence delay when switching over to the backup RP. That delay can exist no matter where the primary and backup RPs are located in the topology 🧚

3. Solution ✨

Given the problems above, a good solution would let an operator configure multiple RPs per group and place those RPs in a topologically meaningful way for the sources and receivers 👑

3.1. Mechanisms 🎀

Every RP serving a given group or set of groups gets configured with the same anycast address, set on a numbered interface on the RPs (usually a logical interface like a loopback) 💅 The RPs then advertise group-to-RP mappings using that interface address. This makes group members (senders) register toward the topologically closest RP 🦋 RPs MSDP peer with each other using an address unique to each RP 🫶

Here's the tricky bit. The anycast address isn't a unique address by definition, so a router MUST NOT choose the anycast unicast address as its router ID. Doing that can stop peerings and/or adjacencies from ever coming up 😭

So, in summary, these steps are required:

3.1.1. Create the set of group-to-anycast-RP-address mappings 🌸

Step one: create the set of group-to-anycast-RP-address mappings you want to use in the domain. Every RP in an anycast RP set has to be configured with a consistent set of group-to-RP address mappings. The non-RP routers in the domain will use this mapping 💖

3.1.2. Configure each RP for the group range with the anycast RP address 🍓

Next, configure each RP for the group range with the anycast RP address. If you're using a dynamic mechanism to advertise group-to-RP mappings, like auto-RP or the PIMv2 bootstrap mechanism, then the anycast IP address should be used as the RP address ✨

3.1.3. Configure MSDP peerings between each of the anycast RPs in the set 🦋

Unlike the group-to-RP mapping advertisements, MSDP peerings must use an IP address that's unique to the endpoints. In other words, the MSDP peering endpoints MUST use a unicast rather than anycast address 🙌 A good rule of thumb is to follow the addressing used for the BGP peerings, so loopbacks for iBGP peering and physical interface addresses for eBGP peering 🧚 Also, the anycast address MUST NOT be used as the RP address in SA messages, because that would cause the peer-RPF check to fail 💀

3.1.4. Configure the non-RP's with the group-to-anycast-RP-address mappings 💜

Last step: each non-RP router has to learn the set of group-to-RP mappings. That can happen through static configuration, auto-RP, or the PIMv2 bootstrap mechanism 🌈

3.1.5. Ensure that the anycast IP address is reachable by all routers in the domain 🌍

This usually happens by having each RP inject the /32 into the domain's IGP ⭐

3.2. Interaction with MSDP Peer-RPF check 🫶

Each MSDP peer receives SA messages and forwards them away from the RP address using a "peer-RPF flooding" approach. Peer-RPF flooding is defined with respect to forwarding SA messages [MSDP]. The BGP routing tables get examined to figure out which peer is the next hop toward the RP that originated the SA message. That peer is called an "RPF peer" 👑 Check [MSDP] for the full details of the Peer-RPF check 🎀

3.3. State Implications 🌸

Heads up, using MSDP this way forces the creation of (S,G) state along the path from the receiver to the source. That state might not exist if you used a single RP and receivers were stuck on the shared tree 🙈

7. Author's Address 💖

okay so here are the lovely humans who wrote this one 🫶

Dorian Kim Verio, Inc. EMail: dorian@blackrose.org

Hank Kilmer EMail: hank@rem.com

Dino Farinacci Procket Networks EMail: dino@procket.com

David Meyer EMail: dmm@maoz.com

8. Full Copyright Statement 🎀

Copyright (C) The Internet Society (2003). All Rights Reserved. 📜

bestie, the rules for copying this doc are kinda specific, so listen up 👂 You can copy it and share it with anyone, and you can make derivative works that comment on or explain it, or help people implement it. You can publish and distribute all of that, in whole or in part, with no restrictions 🦋 The one catch is that the copyright notice and this paragraph have to stay on every copy and derivative work.

BUT the document itself can't be modified in any way. So no removing the copyright notice, and no deleting the references to the Internet Society or other Internet organizations. The only exceptions are when you're developing Internet standards (then you have to follow the copyright procedures in the Internet Standards process) or when you're translating it into a language other than English. 🌍

The permissions above are perpetual, meaning the Internet Society and its successors or assigns won't ever take them back 💜

This document and the information in it are provided on an "AS IS" basis, and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 🙈

Acknowledgement 🍓

Funding for the RFC Editor function is currently provided by the Internet Society. 🌈 Thank you, Internet Society, for keeping the RFC Editor running 👑