--- 1/draft-ietf-mboned-anycast-rp-00.txt 2006-02-05 00:19:11.000000000 +0100 +++ 2/draft-ietf-mboned-anycast-rp-01.txt 2006-02-05 00:19:11.000000000 +0100 @@ -1,32 +1,31 @@ MBONED Working Group Dorian Kim Internet Draft Verio David Meyer Cisco Systems Henry Kilmer Dino Farinacci Category Informational - October, 1999 + November, 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 2026. - Internet-Drafts 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. + 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. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at @@ -150,102 +149,24 @@ if the logical address chosen is the highest IP address configured on the router, and the router implementation that automatically chooses a router ID based upon highest IP address assigned to interfaces). Finally, the solution described here can be implemented without any modification to existing protocols or their implementations. 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. The BGP or MBGP - 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". There are a few simple rules that govern how MSDP - Peer-RPF checks. These rules should be kept in mind when configuring - Anycast RP: - -6.2.1. Singly Homed MSDP Speaker - - A singly homed MSDP speaker always accepts SA messages from its peer. - -6.2.2. RP in SA is a MSDP Peer - - A MSDP speaker always accepts SAs for which the RP in the SA message - is a peer. - -6.2.3. Router is itself RP in SA message - - A MSDP speaker always rejects an SA from any peer if it the RP in the - SA message. - -6.2.4. Router has default peers - - If a MSDP speaker has one or more default peers configured, then it - will accept an SA message if comes from the default peer for the RP - in the SA message. - -6.2.5. Complex MSDP Scenario - - Consider routers R1, R2, and R3 form an Anycast RP mesh for an AS. C1 - and C2 are customer routers (and the BGP session not multi-hop); RP - is C1's RP. P1 is a peer router. The picture is as follows: - - MSDP/MBGP Anycast RPs - C1 ============= R1----------------R2 - | SA(S,G,RP) / - | / - | MBGP/MSDP MSDP MSDP / - | / - | / - C2 SA(S',G',RP') / - / - R3 ============== P1 - SA(S,G,RP) - -------> - -6.2.6. Internal MSDP Peering - - When R1 sees SA(S,G,RP) from C1, it sees the next-hop toward prefix - covering RP is through C1, so R1 accepts the SA. R1 will forward - SA(S,G,RP) to R2 and R3, which will only accept SA(S,G,RP) if R1 is - announcing (and is) the next-hop towards the originating RP each SA - message. Note that operationally, this means next-hop needs to be the - same as the MSDP connect-source. - - This implies that if you want to pass on an SA internally, you have - to be announcing the next-hop towards the AS that originates the - prefix covering the originating RP. Note that the MSDP connect-source - has to be the interface that is configured with the address of the - next-hop. - - Now, if C2 tries MSDP peer with R1 directly (cutting out transit - provider C1), then C2's SA RPF fails at R1, because R1 expects SA - message to come from a MSDP peer in the next AS in the AS-PATH - towards the originating RP, which in this case would C1. - -6.2.6.1. RULE - - An internal MSDP peer will accept an SA message from another internal - peer iff that peer is the advertiser of towards the prefix covering - the RP which originated the SA. - -6.2.7. External MSDP Peering - - External peer P1 will accept an SA from R3 iff R3 comes from the next - AS in the path. This breaks, for example, if P1 peers with C1. - -6.2.7.1. RULE - - An external MSDP peer will accept an SA message from another peer iff - the peer is in the next AS in the path towards the AS originating the - prefix covering the RP in the SA message. + flooding is with respect to forwarding SA messages [MSDP]. The BGP or + MBGP 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. 6.3. 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 some what unpredictable. @@ -304,22 +225,22 @@ comments on earlier versions for this idea. 10. References [CLUSTERS] D. Farinacci, et. al., "Use of Anycast Clusters for Inter-Domain Multicast Routing", draft-ietf-farinacci-anycast-clusters-01.txt, March, 1998. ftp://ftpeng.cisco.com/ipmulticast/internet-drafts [MSDP] D. Farinacci, et. al., "Multicast Source Discovery - Protocol (MSDP)", draft-farinacci-msdp-00.txt, - June, 1998. + Protocol (MSDP)", draft-ietf-msdp-spec-02.txt, + November, 1999. [PIMAUTH] L. Wei, et al., "Authenticating PIM version 2 messages", draft-ietf-pim-v2-auth-00.txt, November, 1998. [RFC1825] Atkinson, R., "IP Security Architecture", August 1995. [RFC1828] P. Metzger and W. Simpson, "IP Authentication using Keyed MD5", RFC 1828, August, 1995. [RFC2362] D. Estrin, et. al., "Protocol Independent Multicast-