--- 1/draft-ietf-mboned-anycast-rp-03.txt 2006-02-05 00:19:15.000000000 +0100 +++ 2/draft-ietf-mboned-anycast-rp-04.txt 2006-02-05 00:19:15.000000000 +0100 @@ -1,23 +1,23 @@ MBONED Working Group Dorian Kim Internet Draft Verio David Meyer Cisco Systems Henry Kilmer Dino Farinacci Procket Networks Category Informational - November, 1999 + December, 1999 Anycast RP mechanism using PIM and MSDP - + 1. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC Internet-Drafts. 2026 are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. @@ -163,63 +163,55 @@ anycast RP address. If a dynamic mechanism such as auto-RP or the PIMv2 bootstrap mechanism is being used to advertise group to RP mappings, the anycast IP address should be used for the RP address. 6.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 is unique to the endpoints. A general guideline is to follow the addressing of the BGP peerings, e.g., loopbacks for - iBGP peering, physical interface addresses for eBGP peering. + iBGP peering, physical interface addresses for eBGP peering. Note + that the anycast address MUST NOT be used as the RP address in SA + messages (as this would case the peer-RPF check to fail). 6.1.4. Configure the non-RP's with the group-to-anycast-RP-address mappings Finally, each non-RP router must learn the set of group to RP mappings. This could be done via static configuration, auto-RP, or by PIMv2 bootstrap mechanism. 6.1.5. Ensure that the anycast IP address is reachable by all routers in the domain - This is typically accomplished by injecting the /32 into the domain's - IGP. + This is typically accomplished by causing each RP to inject the /32 + into the domain's IGP. 6.2. Interaction with MSDP Peer-RPF check Each MSDP peer receives and forwards the message away from the RP address in a "peer-RPF flooding" fashion. The notion of peer-RPF flooding is with respect to forwarding SA messages [MSDP]. The BGP routing tables are examined to determine which peer is the next hop towards the originating RP of the SA message. Such a peer is called - an "RPF peer". See [MSDP] for details of the Peer-RPF check. + an "RPF peer". See [MSDP] for details of the Peer-RPF check. Not + finally that the anycast address MUST NOT be used as the RP address + in the RP's SA messages. 6.3. State Implications It should be noted that using MSDP in this way forces the creation of (S,G) state along the path from the receiver to the source. This state may not be present if a single RP was used and receivers were forced to stay on the shared tree. -6.4. Further Applications of Anycast RP mechanism - - The solution described above can also be applied to external MSDP - peers that are used to join two PIM-SM domains together. This can - provide redundancy to the MSDP peering session, ease operational - complexity as well as simplify configuration management. A side - effect to be aware of with this design is that which of the - configured MSDP sessions comes up will be determined via the unicast - topology between two providers, and can be somewhat unpredictable. If - any of the backup peering sessions resets, the active session will - also reset. - 7. Security considerations Since the solution described here makes heavy use of anycast addressing, care must be taken to avoid spoofing. In particular unicast routing and PIM RPs must be protected. 7.1. Unicast Routing Both internal and external unicast routing can be weakly protected with keyed MD5 [RFC1828], as implemented in an internal protocol such