< draft-ietf-msdp-spec-06.txt		draft-ietf-msdp-spec-07.txt >
	Network Working Group Dino Farinacci
	INTERNET DRAFT Procket Networks		Network Working Group David Meyer (Editor)
	Yakov Rekhter		INTERNET DRAFT
	David Meyer
	Cisco Systems
	Peter Lothberg
	Sprint
	Hank Kilmer
	Jeremy Hall
	UUnet
	Category Standards Track		Category Standards Track
	July, 2000		March, 2001
	Multicast Source Discovery Protocol (MSDP)		Multicast Source Discovery Protocol (MSDP)
	<draft-ietf-msdp-spec-06.txt>		<draft-ietf-msdp-spec-07.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		Internet Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that other		Task Force (IETF), its areas, and its working groups. Note that other
	groups may also distribute working documents as Internet-Drafts.		groups may also distribute working documents as Internet-Drafts.
	skipping to change at page 2, line 32 ¶		skipping to change at page 2, line 25 ¶
	o No Third-party resource dependencies on RP		o No Third-party resource dependencies on RP
	PIM-SM domains can rely on their own RPs only.		PIM-SM domains can rely on their own RPs only.
	o Receiver only Domains		o Receiver only Domains
	Domains with only receivers get data without globally		Domains with only receivers get data without globally
	advertising group membership.		advertising group membership.
	o Global Source State
	Global source state is not required, since a router need not
	cache Source Active (SA) messages (see below). MSDP is a
	periodic protocol.
	The keywords MUST, MUST NOT, MAY, OPTIONAL, REQUIRED, RECOMMENDED,		The keywords MUST, MUST NOT, MAY, OPTIONAL, REQUIRED, RECOMMENDED,
	SHALL, SHALL NOT, SHOULD, SHOULD NOT are to be interpreted as defined		SHALL, SHALL NOT, SHOULD, SHOULD NOT are to be interpreted as defined
	in RFC 2119 [RFC2119].		in RFC 2119 [RFC2119].
	5. Overview		5. Overview
	MSDP-speaking routers in a PIM-SM [RFC2362] domain will have a MSDP		MSDP-speaking routers in a PIM-SM [RFC2362] domain will have a MSDP
	peering relationship with MSDP peers in another domain. The peering		peering relationship with MSDP peers in another domain. The peering
	relationship will be made up of a TCP connection in which control		relationship will be made up of a TCP connection in which control
	information is exchanged. Each domain will have one or more		information is exchanged. Each domain will have one or more
	skipping to change at page 4, line 23 ¶		skipping to change at page 3, line 51 ¶
	in the group which the SA message describes. That is, the RP checks		in the group which the SA message describes. That is, the RP checks
	for a (*,G) entry with a non-empty outgoing interface list; this		for a (*,G) entry with a non-empty outgoing interface list; this
	implies that the domain is interested in the group. In this case, the		implies that the domain is interested in the group. In this case, the
	RP triggers a (S,G) join event towards the data source as if a		RP triggers a (S,G) join event towards the data source as if a
	Join/Prune message was received addressed to the RP itself. This sets		Join/Prune message was received addressed to the RP itself. This sets
	up a branch of the source-tree to this domain. Subsequent data		up a branch of the source-tree to this domain. Subsequent data
	packets arrive at the RP which are forwarded down the shared-tree		packets arrive at the RP which are forwarded down the shared-tree
	inside the domain. If leaf routers choose to join the source-tree		inside the domain. If leaf routers choose to join the source-tree
	they have the option to do so according to existing PIM-SM		they have the option to do so according to existing PIM-SM
	conventions. Finally, if an RP in a domain receives a PIM Join		conventions. Finally, if an RP in a domain receives a PIM Join
	message for a new group G, and it is caching SAs, then the RP should		message for a new group G, the RP SHOULD trigger a (S,G) join event
	trigger a (S,G) join event for each SA for that group in its cache.		for each SA for that group in its cache.
	This procedure has been affectionately named flood-and-join because		This procedure has been affectionately named flood-and-join because
	if any RP is not interested in the group, they can ignore the SA		if any RP is not interested in the group, they can ignore the SA
	message. Otherwise, they join a distribution tree.		message. Otherwise, they join a distribution tree.
	7. Controlling State		7. Caching
	While RPs which receive SA messages are not required to keep MSDP		A MSDP speaker MUST cache SA messages. Caching allows pacing of MSDP
	(S,G) state, an RP SHOULD cache SA messages by default. One of the		messages as well as reducing join latency for new receivers of a
	main advantages of caching is that since the RP has MSDP (S,G) state,		group G at an orginating RP which has existing MSDP (S,G) state. In
	join latency is greatly reduced for new receivers of G. In addition,		addition, caching greatly aids in diagnosis and debugging of various
	caching greatly aids in diagnosis and debugging of various problems.		problems.
	8. Timers		8. Timers
	The main timers for MSDP are: SA-Advertisement-Timer, SA-Hold-Down-		The main timers for MSDP are: SA-Advertisement-Timer, SA-Hold-Down-
	Timer, SA Cache Entry timer, KeepAlive timer, and ConnectRetry and		Timer, SA Cache Entry timer, KeepAlive timer, and ConnectRetry and
	Peer Hold Timer. Each is considered below.		Peer Hold Timer. Each is considered below.
	8.1. SA-Advertisement-Timer		8.1. SA-Advertisement-Timer
	RPs which originate SA messages do it periodically as long as there		RPs which originate SA messages do it periodically as long as there
	is data being sent by the source. There is one SA-Advertisement-Timer		is data being sent by the source. There is one SA-Advertisement-Timer
	covering the sources that an RP may advertise. [SA-Advertisement-		covering the sources that an RP may advertise. [SA-Advertisement-
	Period] MUST be 60 seconds. An RP MUST not send more than one		Period] MUST be 60 seconds. An RP MUST not send more than one
	periodic SA message for a given (S,G) within an SA Advertisement		periodic SA message for a given (S,G) within an SA Advertisement
	interval. Originating periodic SA messages is important so that new		interval. Originating periodic SA messages is important so that new
	receivers who join after a source has been active can get data		receivers who join after a source has been active can get data
	quickly via the receiver's own RP when it is not caching SA state.		quickly via the receiver's own RP. Finally, an originating RP SHOULD
	Finally, an originating RP SHOULD trigger the transmission of an SA		trigger the transmission of an SA message as soon as it receives data
	message as soon as it receives data from an internal source for the		from an internal source for the first time.
	first time.
	8.2. SA-Advertisement-Timer Processing		8.2. SA-Advertisement-Timer Processing
	An RP MUST spread the generation of periodic SA messages over its		An RP MUST spread the generation of periodic SA messages over its
	reporting interval (i.e. SA-Advertisement-Period). An RP starts the		reporting interval (i.e. SA-Advertisement-Period). An RP starts the
	SA-Advertisement-Timer when the MSDP process is configured. When the		SA-Advertisement-Timer when the MSDP process is configured. When the
	timer expires, an RP resets the timer to [SA-Advertisement-Period]		timer expires, an RP resets the timer to [SA-Advertisement-Period]
	seconds, and begins the advertisement of its active sources. Active		seconds, and begins the advertisement of its active sources. Active
	sources are advertised in the following manner: An RP packs its		sources are advertised in the following manner: An RP packs its
	active sources into an SA message until the largest MSDP packet that		active sources into an SA message until the largest MSDP packet that
	can be sent is built or there are no more sources, and then sends the		can be sent is built or there are no more sources, and then sends the
	message. This process is repeated periodically within the SA-		message. This process is repeated periodically within the SA-
	Advertisement-Period in such a way that all of the RP's sources are		Advertisement-Period in such a way that all of the RP's sources are
	advertised. Note that the largest MSDP packet that can be sent has		advertised. Note that the largest MSDP packet that can be sent has
	size that is the minimum of MTU of outgoing link minus size of TCP		size that is the minimum of MTU of outgoing link minus size of TCP
	and IP headers, and 1400 (largest MSDP packet). Finally, the timer is		and IP headers, and 1400 (largest MSDP packet). Finally, the timer is
	deleted when the MSDP process is deconfigured. Note that a caching		deleted when the MSDP process is deconfigured.
	implementation may also wish to check the SA-Cache on this timer
	event.
	8.3. SA Cache Timeout (SA-State-Timer)		8.3. SA Cache Timeout (SA-State-Timer)
	Each entry in an SA Cache has an associated SA-State-Timer. A		Each entry in an SA Cache has an associated SA-State-Timer. A
	(S,G)-SA-State-Timer is started when an (S,G)-SA message is initially		(S,G)-SA-State-Timer is started when an (S,G)-SA message is initially
	received by a caching MSDP peer. The timer is reset to [SA-State-		received by a MSDP peer. The timer is reset to [SA-State-Period] if
	Period] if another (S,G)-SA message is received before the (S,G)-SA-		another (S,G)-SA message is received before the (S,G)-SA-State-Timer
	State-Timer expires. [SA-State-Period] MUST NOT be less than 90		expires. [SA-State-Period] MUST NOT be less than 90 seconds.
	seconds.
	8.4. SA-Hold-Down-Timer		8.4. SA-Hold-Down-Timer
	The per-(S,G) timer is set to [SA-Hold-Down-Period] when forwarding		The per-(S,G) timer is set to [SA-Hold-Down-Period] when forwarding
	an SA message, and a SA message MUST only be forwarded when it's		an SA message, and a SA message MUST only be forwarded when it's
	associated timer is not running. [SA-Hold-Down-Period] SHOULD be set		associated timer is not running. [SA-Hold-Down-Period] SHOULD be set
	to 30 seconds. A caching MSDP peer MUST NOT forward a (S,G)-SA		to 30 seconds. A MSDP peer MUST NOT forward a (S,G)-SA message it has
	message it has received in during the previous [SA-Hold-Down-Period]		received in during the previous [SA-Hold-Down-Period] seconds.
	seconds. Finally, the timer is deleted when the SA cache entry is		Finally, the timer is deleted when the SA cache entry is deleted.
	deleted.
	8.5. KeepAlive Timer		8.5. KeepAlive Timer
	The KeepAlive timer contols when to send MSDP KeepAlive messages. In		The KeepAlive timer contols when to send MSDP KeepAlive messages. In
	particular, the KeepAlive timer is used to reset the TCP connection		particular, the KeepAlive timer is used to reset the TCP connection
	when the passive-connect side of the connection goes down. The		when the passive-connect side of the connection goes down. The
	KeepAlive timer is set to [KeepAlive-Period] when the passive-connect		KeepAlive timer is set to [KeepAlive-Period] when the passive-connect
	peer comes up. [KeepAlive-Period] SHOULD NOT be less that 75 seconds.		peer comes up. [KeepAlive-Period] SHOULD NOT be less that 75 seconds.
	The timer is reset to [KeepAlive-Period] upon receipt of an MSDP		The timer is reset to [KeepAlive-Period] upon receipt of an MSDP
	message from peer, and deleted when the timer expires or the		message from peer, and deleted when the timer expires or the
	skipping to change at page 7, line 30 ¶		skipping to change at page 7, line 7 ¶
	Internet (i.e., SA filtering by transit domains can cause undesired		Internet (i.e., SA filtering by transit domains can cause undesired
	lack of connectivity). In general, policy should be expressed using		lack of connectivity). In general, policy should be expressed using
	MBGP [RFC2283]. This will cause MSDP messages to flow in the desired		MBGP [RFC2283]. This will cause MSDP messages to flow in the desired
	direction and peer-RPF fail otherwise. An exception occurs at an		direction and peer-RPF fail otherwise. An exception occurs at an
	administrative scope [RFC2365] boundary. In particular, a SA message		administrative scope [RFC2365] boundary. In particular, a SA message
	for a (S,G) MUST NOT be sent to peers which are on the other side of		for a (S,G) MUST NOT be sent to peers which are on the other side of
	an administrative scope boundary for G.		an administrative scope boundary for G.
	11. SA Requests		11. SA Requests
	If an MSDP peer decides to cache SA state, it MAY accept SA-Requests		A MSDP speaker MAY accept SA-Requests from other MSDP peers. When an
	from other MSDP peers. When an MSDP peer receives an SA-Request for a		MSDP speaker receives an SA-Request for a group range, it will
	group range, it will respond to the peer with a set of SA entries, in		respond to the peer with a set of SA entries, in an SA-Response
	an SA-Response message, for all active sources sending to the group		message, for all active sources sending to the group range requested
	range requested in the SA-Request message. The peer that sends the		in the SA-Request message. The peer that sends the request will not
	request will not flood the responding SA-Response message to other		flood the responding SA-Response message to other peers. See section
	peers. See section 17 for discussion of error handling relating to SA		17 for discussion of error handling relating to SA requests and
	requests and responses.		responses.
	12. Encapsulated Data Packets		12. Encapsulated Data Packets
	For bursty sources, the RP may encapsulate multicast data from the		For bursty sources, the RP may encapsulate multicast data from the
	source. An interested RP may decapsulate the packet, which SHOULD be		source. An interested RP may decapsulate the packet, which SHOULD be
	forwarded as if a PIM register encapsulated packet was received. That		forwarded as if a PIM register encapsulated packet was received. That
	is, if packets are already arriving over the interface toward the		is, if packets are already arriving over the interface toward the
	source, then the packet is dropped. Otherwise, if the outgoing		source, then the packet is dropped. Otherwise, if the outgoing
	interface list is non-null, the packet is forwarded appropriately.		interface list is non-null, the packet is forwarded appropriately.
	Note that when doing data encapsulation, an implementation MUST bound		Note that when doing data encapsulation, an implementation MUST bound
	skipping to change at page 8, line 38 ¶		skipping to change at page 8, line 14 ¶
	14. MSDP Peer-RPF Forwarding		14. MSDP Peer-RPF Forwarding
	The MSDP Peer-RPF Forwarding rules are used for forwarding SA		The MSDP Peer-RPF Forwarding rules are used for forwarding SA
	messages throughout an MSDP enabled internet. Unlike the RPF check		messages throughout an MSDP enabled internet. Unlike the RPF check
	used when forwarding data packets, the Peer-RPF check is against the		used when forwarding data packets, the Peer-RPF check is against the
	RP address carried in the SA message.		RP address carried in the SA message.
	14.1. Peer-RPF Forwarding Rules		14.1. Peer-RPF Forwarding Rules
	An SA message originated by an MSDP originator R and received by a		An SA message originated by R and received by X
	MSDP router from MSDP peer N is accepted if N is the appropriate RPF		from N is accepted if N is the peer-RPF neighbor for R, and is
	neighbor for originator R (the RP in the SA message), and discarded		discarded otherwise.
	otherwise.
	The RPF neighbor is chosen using the first of the following rules		MP(R,N) MP(N,X)
	that matches:		R ---------....-------> N ------------------> X
			SA(S,G,R) SA(S,G,R)
	(i). R is the RPF neighbor if we have an MSDP peering with R,		Where MP(A,B) is an MSDP peering path (one or more
	and R is the next hop towards the prefix covering the RP		MSDP peers) between A and B, and SA(S,G,R) is an
	in the SA message.		SA message for source S on group G orignated by
			an RP R.
	(ii). The external MBGP neighbor towards which we are		The peer-RPF neighbor is chosen deterministically,
	poison-reversing the MBGP route towards R is the RPF neighbor		using the first of the following rules that matches.
	if we have an MSDP peering with it.
	(iii). If we have any MSDP peerings with neighbors in the first		X accepts the SA from R forwarded by N if :
	AS along the AS_PATH (the AS from which we learned this
	route), but no external MBGP peerings with them,
	the neighbor with the highest IP address is the RPF neighbor.
	(iv). The internal MBGP advertiser of the router towards R is		(i). R is the RPF neighbor if we have an MSDP peering
	the RPF neighbor if we have an MSDP peering with it.		with R (e.g. N == R).
	(v). If none of the above match, and we have an MSDP		(ii). N is the RPF neighbor of X if N is a MSDP peer of
	default-peer configured, the MSDP default-peer is		X and N is the next hop toward R.
	the RPF neighbor.
			(iii). N is the RPF neighbor of X if X has an MSDP
			peering(s) with the neighboring AS (the AS
			with that AS, then the MSDP neighbor with the
			highest IP address in the first AS toward R is
			the RPF peer.
			(iv). N is the RPF neighbor of X if (intra-domain case):
			(a). N == R (i.e. N originated the SA), or
			(b). X and N are part of a MSDP Mesh Group. Note that in
			this case every member of mesh group is an peer-RPF
			neighbor of X.
			(v). If none of the above match, and we have an
			MSDP default-peer configured, the MSDP
			default-peer is the RPF neighbor.
	14.2. MSDP default-peer semantics		14.2. MSDP default-peer semantics
	An MSDP default-peer is much like a default route. It is intended to		An MSDP default-peer is much like a default route. It is intended to
	be used in those cases where a stub network isn't running BGP. An		be used in those cases where a stub network isn't running BGP. An
	MSDP peer configured with a default-peer accepts all SA messages from		MSDP peer configured with a default-peer accepts all SA messages from
	the default-peer. Note that a router running BGP SHOULD NOT allow		the default-peer. Note that a router running BGP SHOULD NOT allow
	configuration of default peers, since this allows the possibility for		configuration of default peers, since this allows the possibility for
	SA looping or black-holes to occur.		SA looping or black-holes to occur.
	skipping to change at page 14, line 24 ¶		skipping to change at page 14, line 24 ¶
	Source Address		Source Address
	The IP address of the active source.		The IP address of the active source.
	Multiple SA TLVs MAY appear in the same message and can be batched		Multiple SA TLVs MAY appear in the same message and can be batched
	for efficiency at the expense of data latency. This would typically		for efficiency at the expense of data latency. This would typically
	occur on intermediate forwarding of SA messages.		occur on intermediate forwarding of SA messages.
	16.2.2. IPv4 Source-Active Request TLV		16.2.2. IPv4 Source-Active Request TLV
	The Source-Active Request is used to request SA-state from a caching		The Source-Active Request is used to request SA-state from a MSDP
	MSDP peer. If an RP in a domain receives a PIM Join message for a		peer. If an RP in a domain receives a PIM Join message for a group,
	group, creates (*,G) state and wants to know all active sources for		creates (*,G) state and wants to know all active sources for group G,
	group G, and it has been configured to peer with an SA-state caching		it may send an SA-Request message for the group.
	peer, it may send an SA-Request message for the group.
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| 2 | 8 | Reserved |		| 2 | 8 | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Group Address Prefix |		| Group Address Prefix |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Type		Type
	IPv4 Source-Active Request TLV is type 2.		IPv4 Source-Active Request TLV is type 2.
	skipping to change at page 17, line 9 ¶		skipping to change at page 17, line 9 ¶
	Message Header Error subcodes:		Message Header Error subcodes:
	0 - Unspecific (MC)		0 - Unspecific (MC)
	2 - Bad Message Length (MC)		2 - Bad Message Length (MC)
	3 - Bad Message Type (CC)		3 - Bad Message Type (CC)
	SA-Request Error subcodes:		SA-Request Error subcodes:
	0 - Unspecific (MC)		0 - Unspecific (MC)
	1 - Does not cache SA (MC)		1 - Invalid Group (MC)
	2 - Invalid Group (MC)
	SA-Message/SA-Response Error subcodes		SA-Message/SA-Response Error subcodes
	0 - Unspecific (MC)		0 - Unspecific (MC)
	1 - Invalid Entry Count (CC)		1 - Invalid Entry Count (CC)
	2 - Invalid RP Address (MC)		2 - Invalid RP Address (MC)
	3 - Invalid Group Address (MC)		3 - Invalid Group Address (MC)
	4 - Invalid Source Address (MC)		4 - Invalid Source Address (MC)
	5 - Invalid Sprefix Length (MC)		5 - Invalid Sprefix Length (MC)
	6 - Looping SA (Self is RP) (MC)		6 - Looping SA (Self is RP) (MC)
	skipping to change at page 18, line 39 ¶		skipping to change at page 18, line 39 ¶
	If the Length field of the message header is less than 4 or greater		If the Length field of the message header is less than 4 or greater
	than 1400, or the length of a KeepAlive message is not equal to 3,		than 1400, or the length of a KeepAlive message is not equal to 3,
	then the Error Subcode is set to Bad Message Length.		then the Error Subcode is set to Bad Message Length.
	If the Type field of the message header is not recognized, then the		If the Type field of the message header is not recognized, then the
	Error Subcode is set to Bad Message Type.		Error Subcode is set to Bad Message Type.
	17.2. SA-Request Error Handling		17.2. SA-Request Error Handling
	The SA-Request Error code is used to signal the receipt of a SA		The SA-Request Error code is used to signal the receipt of a SA
	request at a non-caching MSDP peer, or at a caching MSDP peer when an		request at a MSDP peer when an invalid group address requested.
	invalid group address requested.
	When a non-caching MSDP peer receives an SA-Request, it returns the
	following notification:
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| 5 | 16 |O| 2 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| 1 | Reserved | Gprefix Len |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Gprefix |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Group Address |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	If a caching MSDP peer receives a request for an invalid group, it		When a MSDP peer receives a request for an invalid group, it returns
	returns the following notification:		the following notification:
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| 5 | 16 |O| 2 |		| 5 | 16 |O| 2 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| 2 | Reserved | Gprefix Len |		| 2 | Reserved | Gprefix Len |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Gprefix |		| Gprefix |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Invalid Group Address |		| Invalid Group Address |
	skipping to change at page 24, line 42 ¶		skipping to change at page 23, line 42 ¶
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|C| Reserved0 | Ver | [MSDP-GRE-ProtocolType] |\		|C| Reserved0 | Ver | [MSDP-GRE-ProtocolType] |\
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ GRE Header		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ GRE Header
	| Checksum (optional) | Reserved1 |/		| Checksum (optional) | Reserved1 |/
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Originating RP IPv4 Address |\		| Originating RP IPv4 Address |\
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Payload		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Payload
	| (S,G) Data Packet .... /		| (S,G) Data Packet .... /
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	MSDP-GRE-ProtocolType is set to 0x876C, pending IANA approval
	[ETYPES,RFC1700].
	18.2.1. Encapsulation and Path MTU Discovery [RFC1191]		18.2.1. Encapsulation and Path MTU Discovery [RFC1191]
	Existing implementations of GRE, when using IPv4 as the Delivery		Existing implementations of GRE, when using IPv4 as the Delivery
	Header, do not implement Path MTU discovery and do not set the Don't		Header, do not implement Path MTU discovery and do not set the Don't
	Fragment bit in the Delivery Header. This can cause large packets to		Fragment bit in the Delivery Header. This can cause large packets to
	become fragmented within the tunnel and reassembled at the tunnel		become fragmented within the tunnel and reassembled at the tunnel
	exit (independent of whether the payload packet is using PMTU). If a		exit (independent of whether the payload packet is using PMTU). If a
	tunnel entry point were to use Path MTU discovery, however, that		tunnel entry point were to use Path MTU discovery, however, that
	tunnel entry point would also need to relay ICMP unreachable error		tunnel entry point would also need to relay ICMP unreachable error
	messages (in particular the "fragmentation needed and DF set" code)		messages (in particular the "fragmentation needed and DF set" code)
	skipping to change at page 25, line 28 ¶		skipping to change at page 24, line 21 ¶
	the originator sets the don't fragment bit, the packet gets dropped		the originator sets the don't fragment bit, the packet gets dropped
	within the tunnel, but since the originator doesn't receive proper		within the tunnel, but since the originator doesn't receive proper
	feedback, it retransmits with the same PMTU, causing subsequently		feedback, it retransmits with the same PMTU, causing subsequently
	transmitted packets to be dropped.		transmitted packets to be dropped.
	18.3. TCP Data Encapsulation		18.3. TCP Data Encapsulation
	As discussed earlier, encapsulation of data in SA messages MAY be		As discussed earlier, encapsulation of data in SA messages MAY be
	supported for backwards compatibility with legacy MSDP peers.		supported for backwards compatibility with legacy MSDP peers.
	19. Security Considerations		19. IANA Considerations
			The IANA should assigne 0x0009 from the IANA SNAP Protocol IDs [IANA]
			to MSDP-GRE-ProtocolType.
			20. Security Considerations
	An MSDP implementation MAY use IPsec [RFC1825] or keyed MD5 [RFC1828]		An MSDP implementation MAY use IPsec [RFC1825] or keyed MD5 [RFC1828]
	to secure control messages. When encapsulating SA data in GRE,		to secure control messages. When encapsulating SA data in GRE,
	security should be relatively similar to security in a normal IPv4		security should be relatively similar to security in a normal IPv4
	network, as routing using GRE follows the same routing that IPv4 uses		network, as routing using GRE follows the same routing that IPv4 uses
	natively. Route filtering will remain unchanged. However packet		natively. Route filtering will remain unchanged. However packet
	filtering at a firewall requires either that a firewall look inside		filtering at a firewall requires either that a firewall look inside
	the GRE packet or that the filtering is done on the GRE tunnel		the GRE packet or that the filtering is done on the GRE tunnel
	endpoints. In those environments in which this is considered to be a		endpoints. In those environments in which this is considered to be a
	security issue it may be desirable to terminate the tunnel at the		security issue it may be desirable to terminate the tunnel at the
	firewall.		firewall.
	20. Acknowledgments		21. Acknowledgments
	The authors would like to thank Bill Nickless, John Meylor, Liming
	Wei, Manoj Leelanivas, Mark Turner, John Zwiebel, Cristina
	Radulescu-Banu and IJsbrand Wijnands for their design feedback and
	comments. In addition to many other contributions, Tom Pusateri
	helped to clarify the connection state machine, Dave Thaler helped to
	clarify the Notification message types, and Bill Fenner helped to
	clarify the Peer-RPF rules.
	21. Author's Address:
	Dino Farinacci
	Procket Networks
	3850 No. First St., Ste. C
	San Jose, CA 95134
	Email: dino@procket.com
	Yakov Rehkter
	Cisco Systems, Inc.
	170 Tasman Drive
	San Jose, CA, 95134
	Email: yakov@cisco.com
	Peter Lothberg
	Sprint
	VARESA0104
	12502 Sunrise Valley Drive
	Reston VA, 20196
	Email: roll@sprint.net
	Hank Kilmer		The editor would like to thank the original authors, Dino Farinacci,
	Email: hank@rem.com		Yakov Rehkter, Peter Lothberg, Hank Kilmer, and Jermey Hall for their
			orginal contribution to the MSDP specification. In addition, Bill
			Nickless, John Meylor, Liming Wei, Manoj Leelanivas, Mark Turner,
			John Zwiebel, Cristina Radulescu-Banu and IJsbrand Wijnands provided
			useful and productive design feedback and comments. In addition to
			many other contributions, Tom Pusateri helped to clarify the
			connection state machine, Dave Thaler helped to clarify the
			Notification message types, and Bill Fenner helped to clarify the
			Peer-RPF rules.
	Jeremy Hall		22. Editor's Address:
	UUnet Technologies
	3060 Williams Drive
	Fairfax, VA 22031
	Email: jhall@uu.net
	David Meyer		David Meyer
	Cisco Systems, Inc.		Cisco Systems, Inc.
	170 Tasman Drive		170 Tasman Drive
	San Jose, CA, 95134		San Jose, CA, 95134
	Email: dmm@cisco.com		Email: dmm@cisco.com
	22. REFERENCES		23. REFERENCES
	[ETYPES] ftp://ftp.isi.edu/in-notes/iana/assignments/ethernet-numbers		[IANA] ftp://www.iana.org
	[RFC1700] J. Reynolds and J. Postel, "Assigned Numbers", RFC 1700,		[RFC1700] J. Reynolds and J. Postel, "Assigned Numbers", RFC 1700,
	October, 1994.		October, 1994.
	[RFC2784] Farinacci, D., et al., "Generic Routing Encapsulation		[RFC2784] Farinacci, D., et al., "Generic Routing Encapsulation
	(GRE)", RFC 2784, March 2000.		(GRE)", RFC 2784, March 2000.
	[RFC768] Postel, J. "User Datagram Protocol", RFC 768, August,		[RFC768] Postel, J. "User Datagram Protocol", RFC 768, August,
	1980.		1980.
End of changes. 30 change blocks.
	138 lines changed or deleted		94 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/