draft-ietf-mboned-anycast-rp-02.txt   draft-ietf-mboned-anycast-rp-03.txt 
skipping to change at page 1, line 14 skipping to change at page 1, line 14
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 November, 1999
Anycast RP mechanism using PIM and MSDP Anycast RP mechanism using PIM and MSDP
<draft-ietf-mboned-anycast-rp-02.txt> <draft-ietf-mboned-anycast-rp-03.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 RFC2026. all provisions of Section 10 of RFC Internet-Drafts.
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 may also distribute working documents as Internet- Drafts.
Internet-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 9 skipping to change at page 4, line 9
all the sources and receivers of a given group are in Europe, they all the sources and receivers of a given group are in Europe, they
are joining towards the RP in USA and the data will be traversing are joining towards the RP in USA and the data will be traversing
relatively expensive pipe(s) twice, once to get to RP, and back down relatively expensive pipe(s) twice, once to get to RP, and back down
the RP rooted tree again, creating inefficient use of expensive the RP rooted tree again, creating inefficient use of expensive
resources. resources.
5.3. Distant RP Dependencies 5.3. Distant RP Dependencies
As outlined above, a single active RP per group may cause local As outlined above, a single active RP per group may cause local
sources and receivers to become dependent on a topologically distant sources and receivers to become dependent on a topologically distant
RP. In case of a scenario where there are backup RPs configured, RP. In addition, when multiple RPs are configured, there can be
distant RP dependence can be created due to the failure of the considerable convergence delay involved in switching to the backup
primary RP, which is topologically closer, and may become exacerbated RP. This delay may exist independent of the toplogical location of
by switching to the backup RP, which may be even more distant the primary and backup RPs.
topologically, which may lead to inferior performance, if not
outright loss of connectivity to an RP serving the group, depending
on the network condition at the given moment.
6. Solution 6. Solution
Given the problem set outlined above, a good solution would allow an Given the problem set outlined above, a good solution would allow an
operator to configure multiple RPs per group, and distribute those operator to configure multiple RPs per group, and distribute those
RPs in a topologically significant manner to the sources and RPs in a topologically significant manner to the sources and
receivers. receivers.
6.1. Mechanisms 6.1. Mechanisms
All the RPs serving a given group or set of groups are configured All the RPs serving a given group or set of groups are configured
with identical unicast address, using a numbered interface on the RPs with identical unicast address, using a numbered interface on the RPs
(frequently a logical interface such as a loopback is used). RPs then (frequently a logical interface such as a loopback is used). RPs then
advertise group to RP mappings using this interface address. This advertise group to RP mappings using this interface address. This
will cause group members (senders) to join (register) towards the will cause group members (senders) to join (register) towards the
topologically closest RP. RPs MSDP peer with each other using an topologically closest RP. RPs MSDP peer with each other using an
address unique to each RP. Note that if the router implementation address unique to each RP. Note that if the router implementation
chooses the anycast address as the router ID, then peerings and/or chooses the anycast address as the router ID, then peerings and/or
adjacencies may not be established. adjacencies may not be established.
Operationally, the following steps are required: In summary then, the following steps are required:
6.1.1. Create the set of group-to-anycast-RP-address mappings 6.1.1. Create the set of group-to-anycast-RP-address mappings
The first step is to create the set of group-to-anycast-RP-address The first step is to create the set of group-to-anycast-RP-address
mappings to be used in the domain. Each RP participating in a anycast mappings to be used in the domain. Each RP participating in a anycast
RP set must be configured with a consistent set of group to RP RP set must be configured with a consistent set of group to RP
address mappings. This mapping will be used by the non-RP routers in address mappings. This mapping will be used by the non-RP routers in
the domain. the domain.
6.1.2. Configure each RP for the group range with the anycast RP address 6.1.2. Configure each RP for the group range with the anycast RP address
skipping to change at page 7, line 12 skipping to change at page 7, line 7
protocol message integrity protection and group-wise message origin protocol message integrity protection and group-wise message origin
authentication. authentication.
7.3. MSDP Peer Integrity 7.3. MSDP Peer Integrity
As is the the case for BGP, MSDP peers can be protected using keyed As is the the case for BGP, MSDP peers can be protected using keyed
MD5 [RFC1828]. MD5 [RFC1828].
8. Acknowledgments 8. Acknowledgments
John Meylor, Dave Thaler and Tom Pusateri provided insightful John Meylor, Bill Fenner, Dave Thaler and Tom Pusateri provided
comments on earlier versions for this idea. insightful comments on earlier versions for this idea.
9. References 9. References
[MSDP] D. Farinacci, et. al., "Multicast Source Discovery [MSDP] D. Farinacci, et. al., "Multicast Source Discovery
Protocol (MSDP)", draft-ietf-msdp-spec-02.txt, Protocol (MSDP)", draft-ietf-msdp-spec-02.txt,
November, 1999. 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.
 End of changes. 

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