draft-ietf-mboned-anycast-rp-00.txt   draft-ietf-mboned-anycast-rp-01.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
Category Informational Category Informational
October, 1999 November, 1999
Anycast RP mechanism using PIM and MSDP Anycast RP mechanism using PIM and MSDP
<draft-ietf-mboned-anycast-rp-00.txt> <draft-ietf-mboned-anycast-rp-01.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 2026. all provisions of Section 10 of RFC 2026.
Internet-Drafts are working documents of the Internet Engineering 2026 are working documents of the Internet Engineering Task Force
Task Force (IETF), its areas, and its working groups. Note that (IETF), its areas, and its working groups. Note that other groups
other groups may also distribute working documents as Internet- may also distribute working documents as Internet- Drafts.
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
skipping to change at page 4, line 45 skipping to change at page 4, line 45
if the logical address chosen is the highest IP address configured on if the logical address chosen is the highest IP address configured on
the router, and the router implementation that automatically chooses the router, and the router implementation that automatically chooses
a router ID based upon highest IP address assigned to interfaces). a router ID based upon highest IP address assigned to interfaces).
Finally, the solution described here can be implemented without any Finally, the solution described here can be implemented without any
modification to existing protocols or their implementations. modification to existing protocols or their implementations.
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. The BGP or MBGP flooding is with respect to forwarding SA messages [MSDP]. The BGP or
routing tables are examined to determine which peer is the next hop MBGP routing tables are examined to determine which peer is the next
towards the originating RP of the SA message. Such a peer is called hop towards the originating RP of the SA message. Such a peer is
an "RPF peer". There are a few simple rules that govern how MSDP called an "RPF peer". See [MSDP] for details of the Peer-RPF check.
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.
6.3. Further Applications of Anycast RP mechanism 6.3. Further Applications of Anycast RP mechanism
The solution described above can also be applied to external MSDP The solution described above can also be applied to external MSDP
peers that are used to join two PIM-SM domains together. This can peers that are used to join two PIM-SM domains together. This can
provide redundancy to the MSDP peering session, ease operational provide redundancy to the MSDP peering session, ease operational
complexity as well as simplify configuration management. A side complexity as well as simplify configuration management. A side
effect to be aware of with this design is that which of the effect to be aware of with this design is that which of the
configured MSDP sessions comes up will be determined via the unicast configured MSDP sessions comes up will be determined via the unicast
topology between two providers, and can be some what unpredictable. topology between two providers, and can be some what unpredictable.
skipping to change at page 8, line 43 skipping to change at page 6, line 43
comments on earlier versions for this idea. comments on earlier versions for this idea.
10. References 10. References
[CLUSTERS] D. Farinacci, et. al., "Use of Anycast Clusters for [CLUSTERS] D. Farinacci, et. al., "Use of Anycast Clusters for
Inter-Domain Multicast Routing", Inter-Domain Multicast Routing",
draft-ietf-farinacci-anycast-clusters-01.txt, March, draft-ietf-farinacci-anycast-clusters-01.txt, March,
1998. ftp://ftpeng.cisco.com/ipmulticast/internet-drafts 1998. ftp://ftpeng.cisco.com/ipmulticast/internet-drafts
[MSDP] D. Farinacci, et. al., "Multicast Source Discovery [MSDP] D. Farinacci, et. al., "Multicast Source Discovery
Protocol (MSDP)", draft-farinacci-msdp-00.txt, Protocol (MSDP)", draft-ietf-msdp-spec-02.txt,
June, 1998. November, 1999.
[PIMAUTH] L. Wei, et al., "Authenticating PIM version 2 messages", [PIMAUTH] L. Wei, et al., "Authenticating PIM version 2 messages",
draft-ietf-pim-v2-auth-00.txt, November, 1998. draft-ietf-pim-v2-auth-00.txt, November, 1998.
[RFC1825] Atkinson, R., "IP Security Architecture", August 1995. [RFC1825] Atkinson, R., "IP Security Architecture", August 1995.
[RFC1828] P. Metzger and W. Simpson, "IP Authentication using Keyed [RFC1828] P. Metzger and W. Simpson, "IP Authentication using Keyed
MD5", RFC 1828, August, 1995. MD5", RFC 1828, August, 1995.
[RFC2362] D. Estrin, et. al., "Protocol Independent Multicast- [RFC2362] D. Estrin, et. al., "Protocol Independent Multicast-
 End of changes. 

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