draft-ietf-mboned-msdp-deploy-06.txt		rfc4611.txt
	INTERNET-DRAFT M. McBride		Network Working Group M. McBride
	J. Meylor		Request for Comments: 4611 J. Meylor
	D. Meyer		BCP: 121 D. Meyer
	Category Best Current Practice		Category: Best Current Practice August 2006
	Multicast Source Discovery Protocol (MSDP) Deployment Scenarios
	<draft-ietf-mboned-msdp-deploy-06.txt>
	Status of this Document
	This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of RFC2026.
	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.
	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		Multicast Source Discovery Protocol (MSDP) Deployment Scenarios
	http://www.ietf.org/ietf/1id-abstracts.txt
	The list of Internet-Draft Shadow Directories can be accessed at		Status of This Memo
	http://www.ietf.org/shadow.html.
	This document is a product of the MBONED Working Group. Comments		This document specifies an Internet Best Current Practices for the
	should be addressed to the authors, or the mailing list at		Internet Community, and requests discussion and suggestions for
	mboned@lists.uoregon.edu.		improvements. Distribution of this memo is unlimited.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2004). All Rights Reserved.		Copyright (C) The Internet Society (2006).
	Abstract		Abstract
	This document describes best current practices for intra-domain and		This document describes best current practices for intra-domain and
	inter-domain deployment of the Multicast Source Discovery Protocol		inter-domain deployment of the Multicast Source Discovery Protocol
	(MSDP) in conjunction with Protocol Independent Multicast Sparse Mode		(MSDP) in conjunction with Protocol Independent Multicast Sparse Mode
	(PIM-SM).		(PIM-SM).
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction ....................................................2
	1.1. BCP, Experimental Protocols and Normative References. . . . 5		1.1. BCP, Experimental Protocols, and Normative References ......3
	2. Inter-domain MSDP Peering Scenarios. . . . . . . . . . . . . . 6		2. Inter-domain MSDP Peering Scenarios .............................4
	2.1. Peering between PIM Border Routers. . . . . . . . . . . . . 7		2.1. Peering between PIM Border Routers .........................4
	2.2. Peering between Non-Border Routers. . . . . . . . . . . . . 8		2.2. Peering between Non-Border Routers .........................5
	2.3. MSDP Peering without BGP. . . . . . . . . . . . . . . . . . 9		2.3. MSDP Peering without BGP ...................................7
	2.4. MSDP Peering at a Multicast Exchange. . . . . . . . . . . . 10		2.4. MSDP Peering at a Multicast Exchange .......................7
	3. Intra-domain MSDP Peering Scenarios. . . . . . . . . . . . . . 10		3. Intra-domain MSDP Peering Scenarios .............................7
	3.1. Peering between MSDP and MBGP Configured Routers. . . . . . 10		3.1. Peering between MSDP- and MBGP-Configured Routers ..........8
	3.2. MSDP Peer is not BGP Peer (or no BGP Peer). . . . . . . . . 11		3.2. MSDP Peer Is Not BGP Peer (or No BGP Peer) .................8
	3.3. Hierarchical Mesh Groups. . . . . . . . . . . . . . . . . . 12		3.3. Hierarchical Mesh Groups ...................................9
	3.4. MSDP and Route Reflectors . . . . . . . . . . . . . . . . . 13		3.4. MSDP and Route Reflectors .................................10
	3.5. MSDP and Anycast RPs. . . . . . . . . . . . . . . . . . . . 14		3.5. MSDP and Anycast RPs ......................................11
	4. Security Considerations. . . . . . . . . . . . . . . . . . . . 14		4. Security Considerations ........................................11
	4.1. Filtering SA messages . . . . . . . . . . . . . . . . . . . 15		4.1. Filtering SA Messages .....................................11
	4.2. SA message state limits . . . . . . . . . . . . . . . . . . 15		4.2. SA Message State Limits ...................................12
	5. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 15		5. Acknowledgements ...............................................12
	6. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 16		6. References .....................................................12
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17		6.1. Normative References ......................................12
	7.1. Normative References. . . . . . . . . . . . . . . . . . . . 17		6.2. Informative References ....................................13
	7.2. Informative References. . . . . . . . . . . . . . . . . . . 18
	8. Author's Addresses . . . . . . . . . . . . . . . . . . . . . . 18
	9. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 18
	10. Intellectual Property . . . . . . . . . . . . . . . . . . . . 19
	11. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 19
	1. Introduction		1. Introduction
	MSDP [RFC3618] is used primarily in two deployment scenarios:		MSDP [RFC3618] is used primarily in two deployment scenarios:
	o Between PIM Domains		o Between PIM Domains
	MSDP can be used between Protocol Independent Multicast Sparse		MSDP can be used between Protocol Independent Multicast Sparse
	Mode (PIM-SM) [PIM-SM] domains to convey information		Mode (PIM-SM) [RFC4601] domains to convey information about active
	about active sources available in other domains. MSDP peering		sources available in other domains. MSDP peering used in such
	used in such cases is generally one to one peering, and		cases is generally one-to-one peering, and utilizes the
	utilizes the deterministic peer-RPF (Reverse Path Forwarding)		deterministic peer-RPF (Reverse Path Forwarding) rules described
	rules described in the MSDP specification (i.e., does not use		in the MSDP specification (i.e., it does not use mesh-groups).
	mesh-groups). Peerings can be aggregated on a single MSDP		Peerings can be aggregated on a single MSDP peer. Such a peer can
	peer. Such a peer can typically have from one to hundreds of		typically have from one to hundreds of peerings, which is similar
	peerings, which is similar in scale to BGP peerings.		in scale to BGP peerings.
	o Within a PIM Domain		o Within a PIM Domain
	MSDP is often used between Anycast Rendezvous Points		MSDP is often used between Anycast Rendezvous Points (Anycast-RPs)
	(Anycast-RPs) [RFC3446] within a PIM domain to synchronize		[RFC3446] within a PIM domain to synchronize information about the
	information about the active sources being served by each		active sources being served by each Anycast-RP peer (by virtue of
	Anycast-RP peer (by virtue of IGP reachability). MSDP peering		IGP reachability). MSDP peering used in this scenario is
	used in this scenario is typically based on MSDP mesh groups,		typically based on MSDP mesh groups, where anywhere from two to
	where anywhere from two to tens of peers can comprise a given		tens of peers can comprise a given mesh group, although more than
	mesh group, although more than ten is not typical. One or more		ten is not typical. One or more of these mesh-group peers may
	of these mesh-group peers may then also have additional		also have additional one-to-one peerings with MSDP peers outside
	one-to-one peering with MSDP peers outside that PIM domain for		that PIM domain for discovery of external sources. MSDP for
	discovery of external sources. MSDP for anycast-RP without		anycast-RP without external MSDP peering is a valid deployment
	external MSDP peering is a valid deployment option and common.		option and common.
	Current best practice for MSDP deployment utilizes PIM-SM and the		Current best practice for MSDP deployment utilizes PIM-SM and the
	Border Gateway Protocol with multi-protocol extensions (MBGP)		Border Gateway Protocol with multi-protocol extensions (MBGP)
	[RFC1771, RFC2858]. This document outlines how these protocols work		[RFC4271, RFC2858]. This document outlines how these protocols work
	together to provide an intra-domain and inter-domain Any Source		together to provide an intra-domain and inter-domain Any Source
	Multicast (ASM) service.		Multicast (ASM) service.
	The PIM-SM specification assumes that SM operates only in one PIM		The PIM-SM specification assumes that SM operates only in one PIM
	domain. MSDP is used to enable the use of multiple PIM domains by		domain. MSDP is used to enable the use of multiple PIM domains by
	distributing the required information about active multicast sources		distributing the required information about active multicast sources
	to other PIM domains. Due to breaking the Internet multicast		to other PIM domains. Due to breaking the Internet multicast
	infrastructure down to multiple PIM domains, MSDP also enables the		infrastructure down to multiple PIM domains, MSDP also enables the
	possibility to set policy on the visibility of the groups and		possibility of setting policy on the visibility of the groups and
	sources.		sources.
	Transit IP providers typically deploy MSDP to be part of the global		Transit IP providers typically deploy MSDP to be part of the global
	multicast infrastructure by connecting to their upstream and peer		multicast infrastructure by connecting to their upstream and peer
	multicast networks using MSDP.		multicast networks using MSDP.
	Edge multicast networks typically have two choices: to use their		Edge multicast networks typically have two choices: to use their
	Internet providers RP, or to have their own RP and connect it to		Internet providers' RP, or to have their own RP and connect it to
	their ISP using MSDP. By deploying their own RP and MSDP, one can		their ISP using MSDP. By deploying their own RP and MSDP, they can
	use internal multicast groups which are not visible to the provider's		use internal multicast groups that are not visible to the provider's
	RP. This helps with internal multicast being able to continue to work		RP. This helps internal multicast be able to continue to work in the
	in the event there is a problem with connectivity to the provider or		event that there is a problem with connectivity to the provider or
	the provider's RP/MSDP is experiencing difficulties. In the simplest		that the provider's RP/MSDP is experiencing difficulties. In the
	cases where no internal multicast groups are necessary, there is		simplest cases, where no internal multicast groups are necessary,
	often no need to deploy MSDP.		there is often no need to deploy MSDP.
	1.1. BCP, Experimental Protocols and Normative References		1.1. BCP, Experimental Protocols, and Normative References
	This document describes the best current practice for a widely		This document describes the best current practice for a widely
	deployed Experimental protocol, MSDP. There is no plan to advance the		deployed Experimental protocol, MSDP. There is no plan to advance
	MSDP's status (for example, to Proposed Standard). The reasons for		the MSDP's status (for example, to Proposed Standard). The reasons
	this include:		for this include:
	o MSDP was originally envisioned as a temporary protocol to be		o MSDP was originally envisioned as a temporary protocol to be
	supplanted by whatever the IDMR working group produced as an		supplanted by whatever the IDMR working group produced as an
	inter-domain protocol. However, the IDMR WG (or subsequently,		inter-domain protocol. However, the IDMR WG (or subsequently, the
	the BGMP WG) never produced a protocol that could be deployed		BGMP WG) never produced a protocol that could be deployed to
	to replace MSDP.		replace MSDP.
	o One of the primary reasons given for MSDP to be classified as		o One of the primary reasons given for MSDP to be classified as
	Experimental was that the MSDP Working Group came up with		Experimental was that the MSDP Working Group came up with
	modifications to the protocol that the WG thought made it		modifications to the protocol that the WG thought made it better
	better but that implementors didn't see any reasons to		but that implementors didn't see any reasons to deploy. Without
	deploy. Without these modifications (e.g., UDP or GRE		these modifications (e.g., UDP or GRE encapsulation), MSDP can
	encapsulation), MSDP can have negative consequences to initial		have negative consequences to initial packets in datagram streams.
	packets in datagram streams.
	o Scalability: Although we don't know what the hard limits might		o Scalability: Although we don't know what the hard limits might be,
	be, readvertising everything you know every 60 seconds clearly		readvertising everything you know every 60 seconds clearly limits
	limits the amount of state you can advertise.		the amount of state you can advertise.
	o MSDP reached near ubiquitous deployment as the de-facto		o MSDP reached nearly ubiquitous deployment as the de facto standard
	standard inter-domain multicast protocol in the IPv4 Internet.		inter-domain multicast protocol in the IPv4 Internet.
	o No consensus could be reached regarding the reworking of MSDP		o No consensus could be reached regarding the reworking of MSDP to
	to address the many concerns of various constituencies within		address the many concerns of various constituencies within the
	the IETF. As a result, a decision was taken to document what is		IETF. As a result, a decision was taken to document what is
	(ubiquitously) deployed and move that document to Experimental.		(ubiquitously) deployed and to move that document to Experimental.
	While advancement of MSDP to Proposed Standard was considered,		While advancement of MSDP to Proposed Standard was considered, for
	for the reasons mentioned above, it was immediately discarded.		the reasons mentioned above, it was immediately discarded.
	o The advent of protocols such as source specific multicast and		o The advent of protocols such as source-specific multicast and bi-
	bi-directional PIM, as well as embedded RP techniques for		directional PIM, as well as embedded RP techniques for IPv6, have
	IPv6, have further reduced consensus that a replacement		further reduced consensus that a replacement protocol for MSDP for
	protocol for MSDP for the IPv4 Internet is required.		the IPv4 Internet is required.
	The RFC Editor's policy regarding references is that they be split		The RFC Editor's policy regarding references is that they be split
	into two categories known as "normative" and "informative". Normative		into two categories known as "normative" and "informative".
	references specify those documents which must be read to understand		Normative references specify those documents that must be read for
	or implement the technology in an RFC (or whose technology must be		one to understand or implement the technology in an RFC (or whose
	present for the technology in the new RFC to work) [RFCED]. In order		technology must be present for the technology in the new RFC to work)
	to understand this document, one must also understand both the PIM		[RFCED]. In order to understand this document, one must also
	and MSDP documents. As a result, references to these documents are		understand both the PIM and MSDP documents. As a result, references
	normative.		to these documents are normative.
	The IETF has adopted the policy that BCPs must not have normative		The IETF has adopted the policy that BCPs must not have normative
	references to Experimental protocols. However, this document is a		references to Experimental protocols. However, this document is a
	special case in that the underlying Experimental document (MSDP) is		special case in that the underlying Experimental document (MSDP) is
	not planned to be advanced to Proposed Standard.		not planned to be advanced to Proposed Standard.
	The MBONED Working Group requests approval under the Variance		The MBONED Working Group has requested approval under the Variance
	Procedure as documented in RFC 2026 [RFC2026].		Procedure as documented in RFC 2026 [RFC2026]. The IESG followed the
			Variance Procedure and, after an additional 4 week IETF Last Call,
	Note to RFC-Editor: If IETF/IESG approves this, please change the		evaluated the comments and status, and has approved this document.
	above sentence into: The MBONED Working Group has requested approval
	under the Variance Procedure as documented in RFC 2026 [RFC2026].
	The IESG followed the Variance Procedure, and after an additional 4
	week IETF Last Call evaluated the comments and status and has
	approved this document.
	The key words "MUST"", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [RFC 2119].		document are to be interpreted as described in RFC 2119 [RFC 2119].
	2. Inter-domain MSDP Peering Scenarios		2. Inter-domain MSDP Peering Scenarios
	The following sections describe the most common inter-domain MSDP		The following sections describe the most common inter-domain MSDP
	peering possibilities and their deployment options.		peering possibilities and their deployment options.
	2.1. Peering between PIM Border Routers		2.1. Peering between PIM Border Routers
	In this case, the MSDP peers within the domain have their own RP		In this case, the MSDP peers within the domain have their own RP
	located within a bounded PIM domain. In addition, the domain will		located within a bounded PIM domain. In addition, the domain will
	typically have its own Autonomous System (AS) number and one or more		typically have its own Autonomous System (AS) number and one or more
	MBGP speakers. The domain may also have multiple MSDP speakers. Each		MBGP speakers. The domain may also have multiple MSDP speakers.
	border router has an MSDP and MBGP peering with its peer routers.		Each border router has an MSDP and MBGP peering with its peer
	These external MSDP peering deployments typically configure the MBGP		routers. These external MSDP peering deployments typically configure
	peering and MSDP peering using the same directly connected next hop		the MBGP peering and MSDP peering using the same directly connected
	peer IP address or other IP address from the same router. Typical		next hop peer IP address or other IP address from the same router.
	deployments of this type are providers who have a direct peering with		Typical deployments of this type are providers who have a direct
	other providers, providers peering at an exchange, or providers who		peering with other providers, providers peering at an exchange, or
	use their edge router to MSDP/MBGP peer with customers.		providers who use their edge router to MSDP/MBGP peer with customers.
	For a direct peering inter-domain environment to be successful, the		For a direct peering inter-domain environment to be successful, the
	first AS in the MBGP best path to the originating RP should be the		first AS in the MBGP best path to the originating RP should be the
	same as the AS of the MSDP peer. As an example, consider the		same as the AS of the MSDP peer. As an example, consider the
	following topology:		following topology:
	AS1----AS2----AS4		AS1----AS2----AS4
	| /		| /
	| /		| /
	| /		| /
	AS3		AS3
	In this case, AS4 receives a Source Active (SA) message, originated		In this case, AS4 receives a Source Active (SA) message, originated
	by AS1, from AS2. AS2 also has an MBGP peering with AS4. The MBGP		by AS1, from AS2. AS2 also has an MBGP peering with AS4. The MBGP
	first hop AS from AS4, in the best path to the originating RP, is		first hop AS from AS4, in the best path to the originating RP, is
	AS2. The AS of the sending MSDP peer is also AS2. In this case, the		AS2. The AS of the sending MSDP peer is also AS2. In this case, the
	peer-Reverse Path Forwarding check (peer-RPF check) passes and the SA		peer-Reverse Path Forwarding check (peer-RPF check) passes, and the
	message is forwarded.		SA message is forwarded.
	A peer-RPF failure would occur in this topology when the MBGP first		A peer-RPF failure would occur in this topology when the MBGP first
	hop AS, in the best path to the originating RP, is AS2 while the		hop AS, in the best path to the originating RP, is AS2 and the origin
	origin AS of the sending MSDP peer is AS3. This reliance upon BGP AS		AS of the sending MSDP peer is AS3. This reliance upon BGP AS PATH
	PATH information prevents endless looping of SA packets.		information prevents endless looping of SA packets.
	Router code, which has adopted the latest rules in the MSDP draft,		Router code, which has adopted the latest rules in the MSDP document,
	will relax the rules Between AS's a bit. In the following topology we		will relax the rules between AS's a bit. In the following topology,
	have an MSDP peering between AS1<->AS3 and AS3<->AS4:		we have an MSDP peering between AS1<->AS3 and AS3<->AS4:
	RP		RP
	AS1----AS2----AS3----AS4		AS1----AS2----AS3----AS4
	If the first AS in best path to the RP does not equal the MSDP peer,		If the first AS in best path to the RP does not equal the MSDP peer,
	MSDP peer-RPF fails. So AS1 cannot MSDP peer with AS3 since AS2 is		MSDP peer-RPF fails. So AS1 cannot MSDP peer with AS3, since AS2 is
	the first AS in the MBGP best path to AS4 RP. With the latest MSDP		the first AS in the MBGP best path to AS4 RP. With the latest MSDP
	draft compliant code, AS 1 will choose the peer in the closest AS		document compliant code, AS1 will choose the peer in the closest AS
	along best AS path to the RP. AS1 will then accept SA's coming from		along best AS path to the RP. AS1 will then accept SA's coming from
	AS3. If there are multiple MSDP peers to routers within the same AS,		AS3. If there are multiple MSDP peers to routers within the same AS,
	the peer with the highest IP address is chosen as the RPF peer.		the peer with the highest IP address is chosen as the RPF peer.
	2.2. Peering between Non-Border Routers		2.2. Peering between Non-Border Routers
	When MSDP peering between border routers, intra-domain MSDP		For MSDP peering between border routers, intra-domain MSDP
	scalability is restricted because it is necessary to also maintain		scalability is restricted because it is necessary to also maintain
	MBGP and MSDP peerings internally towards their border routers.		MBGP and MSDP peerings internally towards their border routers.
	Within the intra-domain, the border router becomes the announcer of		Within the intra-domain, the border router becomes the announcer of
	the next hop towards the originating RP. This requires that all		the next hop towards the originating RP. This requires that all
	intra-domain MSDP peerings must mirror the MBGP path back towards the		intra-domain MSDP peerings mirror the MBGP path back towards the
	border router. External MSDP (eMSDP) peerings rely upon AS path for		border router. External MSDP (eMSDP) peerings rely upon AS path for
	peer RPF checking, while internal MSDP (iMSDP) peerings rely upon the		peer RPF checking, while internal MSDP (iMSDP) peerings rely upon the
	announcer of the next hop.		announcer of the next hop.
	While the eMBGP peer is typically directly connected between border		While the eMBGP peer is typically directly connected between border
	routers, it is common for the eMSDP peer to be located deeper into		routers, it is common for the eMSDP peer to be located deeper into
	the transit providers AS. Providers, which desire more flexibility in		the transit provider's AS. Providers, which desire more flexibility
	MSDP peering placement, commonly choose a few dedicated routers		in MSDP peering placement, commonly choose a few dedicated routers
	within their core network for the inter-domain MSDP peerings to their		within their core networks for the inter-domain MSDP peerings to
	customers. These core MSDP routers will also typically be in the		their customers. These core MSDP routers will also typically be in
	providers intra-domain MSDP mesh group and configured for Anycast RP.		the provider's intra-domain MSDP mesh group and be configured for
	All multicast routers in the providers AS should statically point to		Anycast RP. All multicast routers in the provider's AS should
	the Anycast RP address. Static RP assignment is the most commonly		statically point to the Anycast RP address. Static RP assignment is
	used method for group to RP mapping due to its deterministic nature.		the most commonly used method for group-to-RP mapping due to its
	Auto-RP [AUTORP] and/or the Bootstrap Router (BSR) [BSR] dynamic RP		deterministic nature. Auto-RP [RFC4601] and/or the Bootstrap Router
	mapping mechanisms could be also used to disseminate RP information		(BSR) [BSR] dynamic RP mapping mechanisms could also be used to
	within the provider's network		disseminate RP information within the provider's network
	For an SA message to be accepted in this (multi-hop peering)		For an SA message to be accepted in this (multi-hop peering)
	environment, we rely upon the next (or closest, with latest MSDP		environment, we rely upon the next (or closest, with latest MSDP
	spec) AS in the best path towards originating RP for the RPF check.		spec) AS in the best path towards the originating RP for the RPF
	The MSDP peer address should be in the same AS as the AS of the		check. The MSDP peer address should be in the same AS as the AS of
	border router's MBGP peer. The MSDP peer address should be advertised		the border router's MBGP peer. The MSDP peer address should be
	via MBGP.		advertised via MBGP.
	For example, using the diagram below, if customer R1 router is MBGP		For example, in the diagram below, if customer R1 router is MBGP
	peering with R2 router and if R1 is MSDP peering with R3 router, then		peering with the R2 router and if R1 is MSDP peering with the R3
	R2 and R3 must be in the same AS (or appear, to AS1, to be from the		router, then R2 and R3 must be in the same AS (or must appear, to
	same AS in the event private AS numbers are deployed). The MSDP peer		AS1, to be from the same AS in the event that private AS numbers are
	with the highest IP address will be chosen as the MSDP RPF peer. R1		deployed). The MSDP peer with the highest IP address will be chosen
	must also have the MSDP peer address of R3 in its MBGP table.		as the MSDP RPF peer. R1 must also have the MSDP peer address of R3
			in its MBGP table.
	+--+ +--+ +--+		+--+ +--+ +--+
	|R1|----|R2|----|R3|		|R1|----|R2|----|R3|
	+--+ +--+ +--+		+--+ +--+ +--+
	AS1 AS2 AS2		AS1 AS2 AS2
	From R3's perspective, AS1 (R1) is the MBGP next AS in the best path		From R3's perspective, AS1 (R1) is the MBGP next AS in the best path
	towards the originating RP. As long as AS1 is the next AS (or		towards the originating RP. As long as AS1 is the next AS (or
	closest) in the best path towards the originating RP, RPF will		closest) in the best path towards the originating RP, RPF will
	succeed on SAs arriving from R1.		succeed on SAs arriving from R1.
	In contrast, with the single hop scenario, with R2 (instead of R3)		In contrast, with the single hop scenario, with R2 (instead of R3)
	border MSDP peering with R1 border, R2's MBGP address becomes the		border MSDP peering with R1 border, R2's MBGP address becomes the
	announcer of the next hop for R3, towards the originating RP, and R3		announcer of the next hop for R3, towards the originating RP, and R3
	must peer with that R2 address. And all AS2 intra-domain MSDP peers		must peer with that R2 address. Moreover, all AS2 intra-domain MSDP
	need to follow iMBGP (or other IGP) peerings towards R2 since iMSDP		peers need to follow iMBGP (or other IGP) peerings towards R2 since
	has a dependence upon peering with the address of the MBGP (or other		iMSDP has a dependence upon peering with the address of the MBGP (or
	IGP) announcer of the next hop.		other IGP) announcer of the next hop.
	2.3. MSDP Peering without BGP		2.3. MSDP Peering without BGP
	In this case, an enterprise maintains its own RP and has an MSDP		In this case, an enterprise maintains its own RP and has an MSDP
	peering with their service provider, but does not BGP peer with them.		peering with its service provider but does not BGP peer with them.
	MSDP relies upon BGP path information to learn the MSDP topology for		MSDP relies upon BGP path information to learn the MSDP topology for
	the SA peer-RPF check. MSDP can be deployed without BGP, however, and		the SA peer-RPF check. MSDP can be deployed without BGP, however,
	as a result there are some special cases where the requirement to		and as a result, there are some special cases where the requirement
	perform an peer-RPF check on the BGP path information is suspended.		to perform a peer-RPF check on the BGP path information is suspended.
	These cases are:		These cases are:
	o There is only a single MSDP peer connection		o There is only a single MSDP peer connection.
	o A default peer (default MSDP route) is configured
	o The originating RP is directly connected		o A default peer (default MSDP route) is configured.
	o A mesh group is used		o The originating RP is directly connected.
	o An implementation is used which allows for an MSDP peer-RPF		o A mesh group is used.
	check using an IGP
	These cases are when there is only a single MSDP peer connection, a		o An implementation is used that allows for an MSDP peer-RPF check
	default peer (default MSDP route) is configured, the originating RP		using an IGP.
	is directly connected, a mesh group is used, or an implementation is
	used which allows for an MSDP peer-RPF check using an IGP.
	An enterprise will typically configure a unicast default route from		An enterprise will typically configure a unicast default route from
	their border router to the provider's border router and then MSDP		its border router to the provider's border router and then MSDP peer
	peer with the provider's MSDP router. If internal MSDP peerings are		with the provider's MSDP router. If internal MSDP peerings are also
	also used within the enterprise, then an MSDP default peer will need		used within the enterprise, then an MSDP default peer will need to be
	to be configured on the border router pointing to the provider. In		configured on the border router that points to the provider. In this
	this way, all external multicast sources will be learned and internal		way, all external multicast sources will be learned, and internal
	sources can be advertised. If only a single MSDP peering was used (no		sources can be advertised. If only a single MSDP peering was used
	internal MSDP peerings) towards the provider, then this stub site		(no internal MSDP peerings) towards the provider, then this stub site
	will MSDP default peer towards the provider and skip the peer-RPF		will MSDP default peer towards the provider and skip the peer-RPF
	check.		check.
	2.4. MSDP Peering at a Multicast Exchange		2.4. MSDP Peering at a Multicast Exchange
	Multicast exchanges allow multicast providers to peer at a common IP		Multicast exchanges allow multicast providers to peer at a common IP
	subnet (or by using point to point virtual LANs) and share MSDP SA		subnet (or by using point-to-point virtual LANs) and share MSDP SA
	updates. Each provider will MSDP and MBGP peer with each others		updates. Each provider will MSDP and MBGP peer with each others
	directly connected exchange IP address. Each exchange router will		directly connected exchange IP address. Each exchange router will
	send/receive SAs to/from their MSDP peers. They will then be able to		send/receive SAs to/from their MSDP peers. They will then be able to
	forward SAs throughout their domain to their customers and any direct		forward SAs throughout their domain to their customers and any direct
	provider peerings.		provider peerings.
	3. Intra-domain MSDP Peering Scenarios		3. Intra-domain MSDP Peering Scenarios
	The following sections describe the different intra-domain MSDP		The following sections describe the different intra-domain MSDP
	peering possibilities and their deployment options.		peering possibilities and their deployment options.
	3.1. Peering between MSDP and MBGP Configured Routers		3.1. Peering between MSDP- and MBGP-Configured Routers
	The next hop IP address of the iBGP peer is typically used for the		The next hop IP address of the iBGP peer is typically used for the
	MSDP peer-RPF check (IGP can also be used). This is different from		MSDP peer-RPF check (IGP can also be used). This is different from
	the inter-domain BGP/MSDP case, where AS path information is used for		the inter-domain BGP/MSDP case, where AS path information is used for
	the peer-RPF check. For this reason, it is necessary for the IP		the peer-RPF check. For this reason, it is necessary for the IP
	address of the MSDP peer connection be the same as the internal MBGP		address of the MSDP peer connection to be the same as the internal
	peer connection whether or not the MSDP/MBGP peers are directly		MBGP peer connection whether or not the MSDP/MBGP peers are directly
	connected. A successful deployment would be similar to the following:		connected. A successful deployment would be similar to the
			following:
	+----+		+----+
	| Rb | 3.3.3.3		| Rb | 3.3.3.3
	/ +----+		/ +----+
	AS1 AS2 / |		AS1 AS2 / |
	+---+ +--+ / |		+---+ +--+ / |
	|RP1|---------|Ra| |		|RP1|---------|Ra| |
	+---+ +--+ |		+---+ +--+ |
	1.1.1.1 2.2.2.2 |		1.1.1.1 2.2.2.2 |
	\ |		\ |
	\ |		\ |
	\ +-----+		\ +-----+
	| RP2 |		| RP2 |
	+-----+		+-----+
	Where RP2 MSDP and MBGP peers with Ra (using 2.2.2.2) and with Rb		where RP2 MSDP and MBGP peers with Ra (using 2.2.2.2) and with Rb
	(using 3.3.3.3). When the MSDP SA update arrives on RP2 from Ra, the		(using 3.3.3.3). When the MSDP SA update arrives on RP2 from Ra, the
	MSDP RPF check for 1.1.1.1 passes because RP2 receives the SA update		MSDP RPF check for 1.1.1.1 passes because RP2 receives the SA update
	from MSDP peer 2.2.2.2 which is also the correct MBGP next hop for		from MSDP peer 2.2.2.2, which is also the correct MBGP next hop for
	1.1.1.1.		1.1.1.1.
	When RP2 receives the same SA update from MSDP peer 3.3.3.3, the MBGP		When RP2 receives the same SA update from MSDP peer 3.3.3.3, the MBGP
	lookup for 1.1.1.1 shows a next hop of 2.2.2.2 so RPF correctly		lookup for 1.1.1.1 shows a next hop of 2.2.2.2, so RPF correctly
	fails, preventing a loop.		fails, preventing a loop.
	This deployment could also fail on an update from Ra to RP2 if RP2		This deployment could also fail on an update from Ra to RP2 if RP2
	was MBGP peering to an address other than 2.2.2.2 on Ra. Intra-domain		was MBGP peering to an address other than 2.2.2.2 on Ra. Intra-
	deployments must have MSDP and MBGP (or other IGP) peering addresses		domain deployments must have MSDP and MBGP (or other IGP) peering
	which match, unless a method to skip the peer-RPF check is deployed.		addresses that match, unless a method to skip the peer-RPF check is
			deployed.
	3.2. MSDP Peer is not BGP Peer (or no BGP Peer)		3.2. MSDP Peer Is Not BGP Peer (or No BGP Peer)
	This is a common MSDP intra-domain deployment in environments where		This is a common MSDP intra-domain deployment in environments where
	few routers are running MBGP or where the domain is not running MBGP.		few routers are running MBGP or where the domain is not running MBGP.
	The problem here is that the MSDP peer address needs to be the same		The problem here is that the MSDP peer address needs to be the same
	as the MBGP peer address. To get around this requirement, the intra-		as the MBGP peer address. To get around this requirement, the intra-
	domain MSDP RPF rules have been relaxed in the following topologies:		domain MSDP RPF rules have been relaxed in the following topologies:
	o By configuring the MSDP peer as a mesh group peer		o By configuring the MSDP peer as a mesh group peer.
	o By having the MSDP peer be the only MSDP peer		o By having the MSDP peer be the only MSDP peer.
			o By configuring a default MSDP peer.
	o By configuring a default MSDP peer
	o By peering with the originating RP.		o By peering with the originating RP.
	o By relying upon an IGP for MSDP peer-RPF		o By relying upon an IGP for MSDP peer-RPF.
	The common choice around the intra-domain BGP peering requirement,		The common choice around the intra-domain BGP peering requirement,
	when more than one MSDP peer is configured, is to deploy MSDP mesh		when more than one MSDP peer is configured, is to deploy MSDP mesh
	groups. When a MSDP mesh group is deployed, there is no RPF check on		groups. When an MSDP mesh group is deployed, there is no RPF check
	arriving SA messages when received from a mesh group peer.		on arriving SA messages when they are received from a mesh group
	Subsequently, SA messages are always accepted from mesh group peers.		peer. Subsequently, SA messages are always accepted from mesh group
	MSDP mesh groups were developed to reduce the amount of SA traffic in		peers. MSDP mesh groups were developed to reduce the amount of SA
	the network since SAs, which arrive from a mesh group peer, are not		traffic in the network since SAs, which arrive from a mesh group
	flooded to peers within that same mesh group. Mesh groups must be		peer, are not flooded to peers within that same mesh group. Mesh
	fully meshed.		groups must be fully meshed.
	If recent (but not currently widely deployed) router code is running		If recent (but not currently widely deployed) router code is running
	which is fully complaint with the latest MSDP draft, another option,		that is fully compliant with the latest MSDP document, another
	to work around not having BGP to MSDP RPF peer, is to RPF using an		option, to work around not having BGP to MSDP RPF peer, is to RPF
	IGP like OSPF, IS-IS, RIP, etc. This new capability will allow for		using an IGP like OSPF, IS-IS, RIP, etc. This new capability will
	enterprise customers, who are not running BGP and who don't want to		allow for enterprise customers, who are not running BGP and who don't
	run mesh groups, to use their existing IGP to satisfy the MSDP peer-		want to run mesh groups, to use their existing IGP to satisfy the
	RPF rules.		MSDP peer-RPF rules.
	3.3. Hierarchical Mesh Groups		3.3. Hierarchical Mesh Groups
	Hierarchal Mesh Groups are occasionally deployed in intra-domain		Hierarchical mesh groups are occasionally deployed in intra-domain
	environments where there are a large number of MSDP peers. Allowing		environments where there are a large number of MSDP peers. Allowing
	multiple mesh groups to forward to one another can reduce the number		multiple mesh groups to forward to one another can reduce the number
	of MSDP peerings per router (due to the full mesh requirement) and		of MSDP peerings per router (due to the full mesh requirement) and
	hence reduce router load. A good hierarchical mesh group		hence reduce router load. A good hierarchical mesh group
	implementation (one which prevents looping) contains a core mesh		implementation (one that prevents looping) contains a core mesh group
	group in the backbone and these core routers serve as mesh group		in the backbone, and these core routers serve as mesh group
	aggregation routers:		aggregation routers:
	[R2]{A,2}		[R2]{A,2}
	/ \		/ \
	/ \		/ \
	/ \		/ \
	/ \		/ \
	/ \		/ \
	/ \		/ \
	/ \		/ \
	{A,1}[R1]-------------[R3]{A,3}		{A,1}[R1]-------------[R3]{A,3}
	In this example, R1, R2, R3 are in MSDP mesh group A (the core mesh		In this example, R1, R2, and R3 are in MSDP mesh group A (the core
	group) and each serves as MSDP aggregation routers for their leaf (or		mesh group), and each serves as MSDP aggregation routers for their
	second tier) mesh groups 1, 2, and 3. Since SA messages received from		leaf (or second tier) mesh groups 1, 2, and 3. Since SA messages
	a mesh group peer are not forwarded to peers within that same mesh		received from a mesh group peer are not forwarded to peers within
	group, SA messages will not loop. Do not create topologies which		that same mesh group, SA messages will not loop. Do not create
	connect mesh-groups in a loop. In the above example for instance,		topologies that connect mesh groups in a loop. In the above example,
	second tier mesh-groups 1, 2, and 3 must not directly exchange SA		for instance, second-tier mesh groups 1, 2, and 3 must not directly
	messages with each other or an endless SA loop will occur.		exchange SA messages with each other or an endless SA loop will
			occur.
	Redundancy, between mesh groups, will also cause a loop and is		Redundancy between mesh groups will also cause a loop and is
	subsequently not available with Hierarchical mesh groups. For		subsequently not available with hierarchical mesh groups. For
	instance, assume R3 had two routers connecting its leaf mesh group 3		instance, assume that R3 had two routers connecting its leaf mesh
	with the core mesh group A. A loop would be created between mesh		group 3 with the core mesh group A. A loop would be created between
	group 3 and mesh group A because each mesh group must be fully meshed		mesh group 3 and mesh group A because each mesh group must be fully
	between peers.		meshed between peers.
	3.4. MSDP and Route Reflectors		3.4. MSDP and Route Reflectors
	BGP requires all iBGP speakers, that are not route-reflector clients		BGP requires all iBGP speakers that are not route-reflector clients
	or confederation members, be fully meshed to prevent loops. In the		or confederation members be fully meshed to prevent loops. In the
	route reflector environment, MSDP requires that the route reflector		route reflector environment, MSDP requires that the route reflector
	clients peer with the route reflector since the router reflector (RR)		clients peer with the route reflector since the router reflector (RR)
	is the BGP announcer of the next hop towards the originating RP. The		is the BGP announcer of the next hop towards the originating RP. The
	RR is not the BGP next hop, but is the announcer of the BGP next hop.		RR is not the BGP next hop, but is the announcer of the BGP next hop.
	The announcer of the next hop is the address typically used for MSDP		The announcer of the next hop is the address typically used for MSDP
	peer-RPF checks. For example, consider the following case:		peer-RPF checks. For example, consider the following case:
	Ra--------RR		Ra--------RR
	/|\		/|\
	/ | \		/ | \
	A B C		A B C
	Ra is forwarding MSDP SAs to the route reflector RR. Routers A, B,		Ra is forwarding MSDP SAs to the route reflector RR. Routers A, B,
	and C also MSDP peer with RR. When RR forwards the SA to A, B, and C,		and C also MSDP peer with RR. When RR forwards the SA to A, B, and
	these RR clients will accept the SA because RR is the announcer of		C, these RR clients will accept the SA because RR is the announcer of
	the next hop to the originating RP address.		the next hop to the originating RP address.
	An SA will peer-RPF fail, if Ra MSDP peers directly with Routers A,		An SA will peer-RPF fail if Ra MSDP peers directly with Routers A, B,
	B, or C, because the announcer of the next hop is RR, but the SA		or C because the announcer of the next hop is RR but the SA update
	update came from Ra. Proper deployment is to have RR clients MSDP		came from Ra. Proper deployment is to have RR clients MSDP peer with
	peer with the RR. MSDP mesh groups may be used to work around this		the RR. MSDP mesh groups may be used to work around this
	requirement. External MSDP peerings will also prevent this		requirement. External MSDP peerings will also prevent this
	requirement since the next AS is compared between MBGP and MSDP		requirement since the next AS is compared between MBGP and MSDP
	peerings, rather than the IP address of the announcer of the next		peerings, rather than the IP address of the announcer of the next
	hop.		hop.
	Some recent MSDP implementations conform to the latest MSDP draft		Some recent MSDP implementations conform to the latest MSDP document,
	which relaxes the requirement of peering with the Advertiser of the		which relaxes the requirement of peering with the Advertiser of the
	Next Hop (the Route Reflector). This new rule allows for peering with		next hop (the Route Reflector). This new rule allows for peering
	the Next-Hop, in addition to the Advertiser of the next hop. In the		with the next hop, in addition to the Advertiser of the next hop. In
	example above, for instance, if Ra is the Next-Hop (perhaps due to		the example above, for instance, if Ra is the next hop (perhaps due
	using BGP's Next hop self attribute) and if routers A,B,C are peering		to using BGP's next hop self attribute), and if routers A, B, and C
	with Ra, the SA's received from Ra will now succeed.		are peering with Ra, the SA's received from Ra will now succeed.
	3.5. MSDP and Anycast RPs		3.5. MSDP and Anycast RPs
	A network, with multiple RPs, can achieve RP load sharing and		A network with multiple RPs can achieve RP load sharing and
	redundancy by using the Anycast RP mechanism in conjunction with MSDP		redundancy by using the Anycast RP mechanism in conjunction with MSDP
	mesh groups [RFC3446]. This mechanism is a common deployment		mesh groups [RFC3446]. This mechanism is a common deployment
	technique used within a domain by service providers and enterprises		technique used within a domain by service providers and enterprises
	which deploy several RPs within their domain. These RPs will each		that deploy several RPs within their domains. These RPs will each
	have the same IP address configured on a Loopback interface (making		have the same IP address configured on a Loopback interface (making
	this the Anycast address). These RPs will MSDP peer with each other		this the Anycast address). These RPs will MSDP peer with each other
	using a separate loopback interface and are part of the same fully		using a separate loopback interface and are part of the same fully
	meshed MSDP mesh group. This loopback interface, used for MSDP		meshed MSDP mesh group. This loopback interface, used for MSDP
	peering, will typically also be used for the MBGP peering. All		peering, will typically also be used for the MBGP peering. All
	routers within the provider's domain will learn of the Anycast RP		routers within the provider's domain will learn of the Anycast RP
	address either through Auto-RP, BSR, or a static RP assignment. Each		address through Auto-RP, BSR, or a static RP assignment. Each
	designated router in the domain will send source registers and group		designated router in the domain will send source registers and group
	joins to the Anycast RP address. Unicast routing will direct those		joins to the Anycast RP address. Unicast routing will direct those
	registers and joins to the nearest Anycast RP. If a particular		registers and joins to the nearest Anycast RP. If a particular
	Anycast RP router fails, unicast routing will direct subsequent		Anycast RP router fails, unicast routing will direct subsequent
	registers and joins to the nearest Anycast RP. That RP will then		registers and joins to the nearest Anycast RP. That RP will then
	forward an MSDP update to all peers within the Anycast MSDP mesh		forward an MSDP update to all peers within the Anycast MSDP mesh
	group. Each RP will then forward (or receive) the SAs to (from)		group. Each RP will then forward (or receive) the SAs to (from)
	external customers and providers.		external customers and providers.
	4. Security Considerations		4. Security Considerations
	An MSDP service should be secured by explicitly controlling the state		An MSDP service should be secured by explicitly controlling the state
	which is created by, and passed within, the MSDP service. As with		that is created by, and passed within, the MSDP service. As with
	unicast routing state, MSDP state should be controlled locally, at		unicast routing state, MSDP state should be controlled locally, at
	the edge origination points. Selective filtering at the multicast		the edge origination points. Selective filtering at the multicast
	service edge helps ensure that only intended sources result in SA		service edge helps ensure that only intended sources result in SA
	message creation, and this control helps to reduce the likelihood of		message creation, and this control helps to reduce the likelihood of
	state-aggregation related problems in the core. There are a variety		state-aggregation related problems in the core. There are a variety
	of points where local policy should be applied to the MSDP service.		of points where local policy should be applied to the MSDP service.
	4.1. Filtering SA messages		4.1. Filtering SA Messages
	The process of originating SA messages should be filtered to ensure		The process of originating SA messages should be filtered to ensure
	only intended local sources are resulting in SA message origination.		that only intended local sources are resulting in SA message
	In addition, MSDP speakers should filter on which SA messages get		origination. In addition, MSDP speakers should filter which SA
	received and forwarded.		messages get received and forwarded.
	Typically there is a fair amount of (S,G) state in a PIM-SM domain		Typically, there is a fair amount of (S,G) state in a PIM-SM domain
	that is local to the domain. However, without proper filtering, sa-		that is local to the domain. However, without proper filtering, SA
	messages containing these local (S,G) announcements may be advertised		messages containing these local (S,G) announcements may be advertised
	to the global MSDP infrastructure. Examples of this includes domain		to the global MSDP infrastructure. Examples of this include domain-
	local applications that use global IP multicast addresses and sources		local applications that use global IP multicast addresses and sources
	that use RFC 1918 addresses [RFC1918]. To improve on the scalability		that use RFC 1918 addresses [RFC1918]. To improve on the scalability
	of MSDP and to avoid global visibility of domain local (S,G)		of MSDP and to avoid global visibility of domain local (S,G)
	information, an external SA filter list is recommended to help		information, an external SA filter list is recommended to help
	prevent unnecessary creation, forwarding, and caching of well-known		prevent unnecessary creation, forwarding, and caching of well-known
	domain local sources.		domain local sources.
	4.2. SA message state limits		4.2. SA Message State Limits
	Proper filtering on SA message origination, receipt, and forwarding		Proper filtering on SA message origination, receipt, and forwarding
	will significantly reduce the likelihood of unintended and unexpected		will significantly reduce the likelihood of unintended and unexpected
	spikes in MSDP state However, a sa-cache state limit SHOULD be		spikes in MSDP state. However, an SA-cache state limit SHOULD be
	configured as a final safeguard to state spikes. When an MSDP peering		configured as a final safeguard to state spikes. When an MSDP
	has reached a stable state (i.e., when the peering has been		peering has reached a stable state (i.e., when the peering has been
	established and the initial SA state has been transferred), it may		established and the initial SA state has been transferred), it may
	also be desirable to configure a rate limiter for the creation of new		also be desirable to configure a rate limiter for the creation of new
	SA state entries.		SA state entries.
	5. IANA Considerations		5. Acknowledgements
	This document creates no new requirements on IANA namespaces
	[RFC2434].
	6. Acknowledgments
	The authors would like to thank Pekka Savola, John Zwiebel, Swapna		The authors would like to thank Pekka Savola, John Zwiebel, Swapna
	Yelamanchi, Greg Shepherd, and Jay Ford for their feedback on earlier		Yelamanchi, Greg Shepherd, and Jay Ford for their feedback on earlier
	versions of this document.		versions of this document.
	7. References		6. References
	7.1. Normative References
	[PIM-SM] Fenner, B., et. al, "Protocol Independent Multicast -
	Sparse Mode (PIM-SM): Protocol Specification
	(Revised)", draft-ietf-pim-sm-v2-new-09.txt. Work
	in progress.
	[RFC1771] Rekhter, Y., and T. Li, "A Border Gateway
	Protocol 4 (BGP-4)", RFC 1771, March 1995.
	[RFC1918] Y. Rekhter, R. Moskowitz, D. Karrenberg, G. de
	Groot, E. Lear, "Address Allocation for Private
	Internets", RFC 1918, Feburary, 1996.
	[RFC2119] Bradner, S., "Key words for use in RFCs to
	Indicate Requirement Levels" RFC 2119/BCP 14,
	March 1997.
	[RFC2365] Meyer, D. "Administratively Scoped IP Multicast",		6.1. Normative References
	RFC 2365, July, 1998.
	[RFC2434] Narten, T., and H. Alvestrand, "Guidelines for		[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
	Writing an IANA Considerations Section in		"Protocol Independent Multicast - Sparse Mode (PIM-SM):
	RFCs", RFC 2434/BCP 0026, October, 1998.		Protocol Specification (Revised)", RFC 4601, August 2006.
	[RFC2858] Bates T., Y. Rekhter, R. Chandra, D. Katz,		[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
	"Multiprotocol Extensions for BGP-4", RFC 2858,		Protocol 4 (BGP-4)", RFC 4271, January 2006.
	June 2000.
	[RFC3330] IANA, "Special-User IPv4 Addresses", RFC 3330,		[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
	September 2002.		and E. Lear, "Address Allocation for Private Internets",
			BCP 5, RFC 1918, February 1996.
	[RFC3446] Kim, D., et. al., "Anycast Rendezvous Point (RP)		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Mechanism using Protocol Independent Multicast		Requirement Levels", BCP 14, RFC 2119, March 1997.
	(PIM) and Multicast Source Discovery Protocol
	(MSDP)", RFC 3446, January, 2003.
	[RFC3618] Meyer, D. and W. Fenner (Editors), "The Multicast		[RFC2858] Bates, T., Rekhter, Y., Chandra, R., and D. Katz,
	Source Discovery Protocol (MSDP)", RFC 3618,		"Multiprotocol Extensions for BGP-4", RFC 2858, June 2000.
	October, 2003.
	7.2. Informative References		[RFC3446] Kim, D., Meyer, D., Kilmer, H., and D. Farinacci, "Anycast
			Rendevous Point (RP) mechanism using Protocol Independent
			Multicast (PIM) and Multicast Source Discovery Protocol
			(MSDP)", RFC 3446, January 2003.
	[AUTORP] Fenner, W., et. al., " Protocol Independent		[RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery
	Multicast - Sparse Mode (PIM-SM): Protocol		Protocol (MSDP)", RFC 3618, October 2003.
	Specification (Revised)", draft-ietf-pim-sm-v2-new-08.txt,
	April, 2004. Work in progress.
	[BSR] Fenner, W., et. al., "Bootstrap Router (BSR)		6.2. Informative References
	Mechanism for PIM Sparse Mode", draft-ietf-pim-sm-bsr-03.txt,
	February, 2003. Work in progress.
	[IANA] http://www.iana.org		[BSR] Fenner, W., et. al., "Bootstrap Router (BSR) Mechanism for
			PIM Sparse Mode", Work in Progress, February 2003.
	[RFCED] http://www.rfc-editor.org/policy.html#policy.refs		[RFCED] http://www.rfc-editor.org/policy.html
	8. Author's Addresses		Authors' Addresses
	Mike McBride		Mike McBride
	Cisco Systems		Cisco Systems
	Email: mcbride@cisco.com
			EMail: mcbride@cisco.com
	John Meylor		John Meylor
	Cisco Systems		Cisco Systems
	Email: jmeylor@cisco.com
			EMail: jmeylor@cisco.com
	David Meyer		David Meyer
	Email: dmm@1-4-5.net
	9. Full Copyright Statement		EMail: dmm@1-4-5.net
	Copyright (C) The Internet Society (2004). This document is subject		Full Copyright Statement
	to the rights, licenses and restrictions contained in BCP 78 and
	except as set forth therein, the authors retain all their rights.
	This document and translations of it may be copied and furnished to		Copyright (C) The Internet Society (2006).
	others, and derivative works that comment on or otherwise explain it
	or assist in its implementation may be prepared, copied, published
	and distributed, in whole or in part, without restriction of any
	kind, provided that the above copyright notice and this paragraph are
	included on all such copies and derivative works. However, this
	document itself may not be modified in any way, such as by removing
	the copyright notice or references to the Internet Society or other
	Internet organizations, except as needed for the purpose of
	developing Internet standards in which case the procedures for
	copyrights defined in the Internet Standards process must be
	followed, or as required to translate it into languages other than
	English.
	The limited permissions granted above are perpetual and will not be		This document is subject to the rights, licenses and restrictions
	revoked by the Internet Society or its successors or assigns.		contained in BCP 78, and except as set forth therein, the authors
			retain all their rights.
	This document and the information contained herein is provided on an		This document and the information contained herein are provided on an
	"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
	BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION		ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
	HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF		INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
	MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
			WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	10. Intellectual Property		Intellectual Property
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed to		Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in		pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights		this document or the extent to which any license under such rights
	might or might not be available; nor does it represent that it has		might or might not be available; nor does it represent that it has
	made any independent effort to identify any such rights. Information		made any independent effort to identify any such rights. Information
	on the procedures with respect to rights in RFC documents can be		on the procedures with respect to rights in RFC documents can be
	found in BCP 78 and BCP 79.		found in BCP 78 and BCP 79.
	Copies of IPR disclosures made to the IETF Secretariat and any		Copies of IPR disclosures made to the IETF Secretariat and any
	assurances of licenses to be made available, or the result of an		assurances of licenses to be made available, or the result of an
	attempt made to obtain a general license or permission for the use of		attempt made to obtain a general license or permission for the use of
	such proprietary rights by implementers or users of this		such proprietary rights by implementers or users of this
	specification can be obtained from the IETF on-line IPR repository at		specification can be obtained from the IETF on-line IPR repository at
	http://www.ietf.org/ipr.		http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary		copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to implement		rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at ietf-		this standard. Please address the information to the IETF at
	ipr@ietf.org.		ietf-ipr@ietf.org.
	11. Acknowledgement		Acknowledgement
	Funding for the RFC Editor function is currently provided by the		Funding for the RFC Editor function is provided by the IETF
	Internet Society.		Administrative Support Activity (IASA).
End of changes. 102 change blocks.
	354 lines changed or deleted		287 lines changed or added
This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/