draft-ietf-mboned-anycast-rp-03.txt   draft-ietf-mboned-anycast-rp-04.txt 
MBONED Working Group Dorian Kim MBONED Working Group Dorian Kim
Internet Draft Verio Internet Draft Verio
David Meyer David Meyer
Cisco Systems Cisco Systems
Henry Kilmer Henry Kilmer
Dino Farinacci Dino Farinacci
Procket Networks Procket Networks
Category Informational Category Informational
November, 1999 December, 1999
Anycast RP mechanism using PIM and MSDP Anycast RP mechanism using PIM and MSDP
<draft-ietf-mboned-anycast-rp-03.txt> <draft-ietf-mboned-anycast-rp-04.txt>
1. Status of this Memo 1. Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC Internet-Drafts. all provisions of Section 10 of RFC Internet-Drafts.
2026 are working documents of the Internet Engineering Task Force 2026 are working documents of the Internet Engineering Task Force
(IETF), its areas, and its working groups. Note that other groups (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet- Drafts. may also distribute working documents as Internet- Drafts.
skipping to change at page 5, line 11 skipping to change at page 5, line 11
anycast RP address. If a dynamic mechanism such as auto-RP or the anycast RP address. If a dynamic mechanism such as auto-RP or the
PIMv2 bootstrap mechanism is being used to advertise group to RP PIMv2 bootstrap mechanism is being used to advertise group to RP
mappings, the anycast IP address should be used for the RP address. 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 6.1.3. Configure MSDP peerings between each of the anycast RPs in the
set set
Unlike the group to RP mapping advertisements, MSDP peerings must use Unlike the group to RP mapping advertisements, MSDP peerings must use
an IP address that is unique to the endpoints. A general guideline is 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 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 6.1.4. Configure the non-RP's with the group-to-anycast-RP-address
mappings mappings
Finally, each non-RP router must learn the set of group to RP 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 mappings. This could be done via static configuration, auto-RP, or by
PIMv2 bootstrap mechanism. PIMv2 bootstrap mechanism.
6.1.5. Ensure that the anycast IP address is reachable by all routers in 6.1.5. Ensure that the anycast IP address is reachable by all routers in
the domain the domain
This is typically accomplished by injecting the /32 into the domain's This is typically accomplished by causing each RP to inject the /32
IGP. into the domain's IGP.
6.2. Interaction with MSDP Peer-RPF check 6.2. Interaction with MSDP Peer-RPF check
Each MSDP peer receives and forwards the message away from the RP Each MSDP peer receives and forwards the message away from the RP
address in a "peer-RPF flooding" fashion. The notion of peer-RPF address in a "peer-RPF flooding" fashion. The notion of peer-RPF
flooding is with respect to forwarding SA messages [MSDP]. The BGP flooding is with respect to forwarding SA messages [MSDP]. The BGP
routing tables are examined to determine which peer is the next hop 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 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 6.3. State Implications
It should be noted that using MSDP in this way forces the creation of 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 (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 state may not be present if a single RP was used and receivers were
forced to stay on the shared tree. 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 7. Security considerations
Since the solution described here makes heavy use of anycast Since the solution described here makes heavy use of anycast
addressing, care must be taken to avoid spoofing. In particular addressing, care must be taken to avoid spoofing. In particular
unicast routing and PIM RPs must be protected. unicast routing and PIM RPs must be protected.
7.1. Unicast Routing 7.1. Unicast Routing
Both internal and external unicast routing can be weakly protected Both internal and external unicast routing can be weakly protected
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/